Handle objects without schemas

[azmeuk]

RFC7644 §3.4.3 detail partial responses (with the use of attributes/excludedAttributes) that do not contain a schemas.

   {
     "schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
     "totalResults":100,
     "itemsPerPage":10,
     "startIndex":1,
     "Resources":[
       {
         "id":"2819c223-7f76-413861904646",
         "userName":"jsmith",
         "displayName":"Smith, James"
       },
       {
         "id":"c8596b90-7539-4f20968d1908",
         "displayName":"Smith Family"
       }
     ]
   }

We should make sure those objects are treated as generic Resource where the id field can be read, so client applications can make new requests for having details if needed.

[azmeuk]

In the same time RFC7643 §3 indicates that:

      The "schemas" attribute is a REQUIRED attribute and is an array of
      Strings containing URIs that are used to indicate the namespaces
      of the SCIM schemas that define the attributes present in the
      current JSON structure. [...]
      All representations of SCIM schemas MUST include a
      non-empty array with value(s) of the URIs supported by that
      representation.

So, maybe RFC7644 §3.4.3 needs an errata?

[azmeuk]

Reported Errata 8084. If accepted, the same kind of errata should be reported for 3.4.2.

[azmeuk]

Phil Hunt rejects the errata but gives a few explanations:

As far as “schemas” being required, the example response is valid because it has the schemas attribute indicated as:

"schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"

[...]
I think the confusion here is that “schemas” is required for the application/scim+json format, but the spec is silent on whether it is require for the “Resources” attribute of the ListResponse JSON structure.

So the OP example is valid.