Remove param from SCIM types

[t2y]

According to https://datatracker.ietf.org/doc/html/rfc7643#section-10.2.1, there is no param in the type definition.

 type
    The entity type, which is either "schemas" or "api".

[leodido]

Thank you for submitting it @t2y!

Anyway, I'm not sure whether there is a "param" type or not.

Quoting from the RFC 7643 section 10.2.1 at page 96:

Process of Identifier Assignment:

  Identifiers with namespace type "schema" (e.g.,
  "urn:ietf:params:scim:schemas") are assigned after the review of
  the assigned contact via the SCIM public mailing list,
  "scim@ietf.org", as documented in [Section 10.3](https://datatracker.ietf.org/doc/html/rfc7643#section-10.3).

  Namespaces with type "api" (e.g., "urn:ietf:params:scim:api") and
  "param" (e.g., "urn:ietf:params:scim:param") are reserved for
  IETF-approved SCIM specifications.

To my understanding, it's just like the API type: reserved for IETF-approved SCIM specifications. That's why I created it, too.

What do you think?

[t2y]

Oh, I didn't notice that statement. It indicates that param might be added in the future. However, I couldn't find a real URN example including urn:ietf:params:scim:param when I tried to write a test code to parse it.

Either one of these is incorrect, I guess. Should we call for a report to the SCIM WG?

 type
    The entity type, which is either "schemas" or "api".

  Namespaces with type "api" (e.g., "urn:ietf:params:scim:api") and
  "param" (e.g., "urn:ietf:params:scim:param") are reserved for
  IETF-approved SCIM specifications.

Of course, you can reject this PR until the specification is clarified.

[leodido]

Either one of these is incorrect, I guess. Should we call for a report to the SCIM WG?

I guess that would be the best thing to do.

Of course, you can reject this PR until the specification is clarified.

No need to. We can keep it open till more clear info emerges!