Subject: [scim] Value of schemas when returned

From: Phil Hunt <[email-masked]>
Date: Wed, 3 Sep 2014 09:25:26 -0700

I have had some question on what the value of schemas should be in response requests.  Should it change according to the attributes returned or should it always be the same?  E.g. if there are no extension attributes, then should schemas still include any extension schema values?

My feeling is that changing schemas to reflect the attributes that are present makes schemas behave in a special way compared to other attributes and would be inconsistent. 

“schemas” should reflect the state that is on the server and not the state of the attributes in the json structure being returned.

Thus “schemas” should always be the same.

Unless I hear some disagreement, I will make the following change...

OLD TEXT:
4.2.  "schemas" Attribute

   The "schemas" attribute is a REQUIRED attribute and is an array of
   Strings containing URIs which are used to indicate the namespace of
   SCIM schema as well as any schema extensions that together defines
   the attributes in a resource.  Each String value must be a unique
   URI.  All representations of SCIM schema MUST include a non-zero
   value array with value(s) of the URIs supported by that
   representation.  The schemas attribute for a resource MUST only
   contain values defined as "schema" and "schemaExtensions" for the
   resource's "resourceType".  Duplicate values MUST NOT be included.
   Value order is not specified and MUST not impact behavior.

NEW TEXT:
4.2.  "schemas" Attribute

   The "schemas" attribute is a REQUIRED attribute and is an array of
   Strings containing URIs which are used to indicate the namespace of
   SCIM schema as well as any schema extensions that together defines
   the attributes in a resource.  Each String value must be a unique
   URI.  All representations of SCIM schema MUST include a non-zero
   value array with value(s) of the URIs supported by that
   representation.  The schemas attribute for a resource MUST only
   contain values defined as "schema" and "schemaExtensions" for the
   resource's "resourceType".  Duplicate values MUST NOT be included.
   Value order is not specified and MUST not impact behavior.

   When displayed as part of a server response, “schemas” SHOULD reflect
   the state of the resource on the SCIM Service Provider and SHOULD NOT 
   change to reflect the attributes present in the JSON response.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Kelly Grizzle <[email-masked]>
Date: Wed, 3 Sep 2014 18:25:50 +0000

IIRC the schemas attribute was initially introduced as something synonymous with the xmlns construct in the XML representation. To me, this is just a matter of data representation ... not actually server state.  When the client POSTs/PUTs data, it must include each of the schemas that is used.  When the server returns results, it must include each of the schemas that is used.  Each of these would be limited to only include the schemas that are actually being used in the representation.

My two cents...

--Kelly

From: scim [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Wednesday, September 03, 2014 11:25 AM
To: SCIM WG
Subject: [scim] Value of schemas when returned

"schemas" should reflect the state that is on the server and not the state of the attributes in the json structure being returned.

Thus "schemas" should always be the same.

OLD TEXT:
4.2<https://tools.ietf.org/html/draft-ietf-scim-core-schema-09#section-4.2>.  "schemas" Attribute

NEW TEXT:
4.2<https://tools.ietf.org/html/draft-ietf-scim-core-schema-09#section-4.2>.  "schemas" Attribute

   When displayed as part of a server response, "schemas" SHOULD reflect

Phil

@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 3 Sep 2014 12:14:41 -0700

Thanks Kelly,

I agree. Keeping schemas as representative of state generates other complications in the protocol such as is schemas mutable?

I will propose new text that suggests it always reflects the current message content.

Phil

@independentid
www.independentid.com
[email-masked]

On Sep 3, 2014, at 11:25 AM, Kelly Grizzle <[email-masked]> wrote:

> IIRC the schemas attribute was initially introduced as something synonymous with the xmlns construct in the XML representation. To me, this is just a matter of data representation … not actually server state.  When the client POSTs/PUTs data, it must include each of the schemas that is used.  When the server returns results, it must include each of the schemas that is used.  Each of these would be limited to only include the schemas that are actually being used in the representation.
>  
> My two cents…
>  
> --Kelly
>  
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: Thomas Krille <[email-masked]>
Date: Fri, 5 Sep 2014 18:08:00 +0200

+1 for reflection of current message content only

Thomas Krille
Softwareentwicklung
tarent solutions GmbH

Telefon +49 (0) 30 138803-128
Telefax +49 (0) 228 54881-235
[email-masked]

Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-0 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander
Steeg

2014-09-03 21:14 GMT+02:00 Phil Hunt <[email-masked]>:

> Thanks Kelly,
>
> I agree. Keeping schemas as representative of state generates other
> complications in the protocol such as is schemas mutable?
>
>  IIRC the schemas attribute was initially introduced as something
> synonymous with the xmlns construct in the XML representation. To me, this
> is just a matter of data representation … not actually server state.  When
> the client POSTs/PUTs data, it must include each of the schemas that is
> used.  When the server returns results, it must include each of the schemas
> that is used.  Each of these would be limited to only include the schemas
> that are actually being used in the representation.
>
>
>
> My two cents…
>
>
>
> --Kelly
>
>
>
> *From:* scim [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Phil Hunt
> *Sent:* Wednesday, September 03, 2014 11:25 AM
> *To:* SCIM WG
> *Subject:* [scim] Value of schemas when returned
>
>
>
> I have had some question on what the value of schemas should be in
> response requests.  Should it change according to the attributes returned
> or should it always be the same?  E.g. if there are no extension
> attributes, then should schemas still include any extension schema values?
>
>
>
> My feeling is that changing schemas to reflect the attributes that are
> present makes schemas behave in a special way compared to other attributes
> and would be inconsistent.
>
>
>
> “schemas” should reflect the state that is on the server and not the state
> of the attributes in the json structure being returned.
>
>
>
>  4.2
> <https://tools.ietf.org/html/draft-ietf-scim-core-schema-09#section-4.2>.
> "schemas" Attribute
>
>
>
>
>
>  4.2
> <https://tools.ietf.org/html/draft-ietf-scim-core-schema-09#section-4.2>.
> "schemas" Attribute
>
>
>
>
>