Subject: Re: [scim] Use of value for complex multi-valued attributes

From: Shelley <[email-masked]>
Date: Tue, 14 May 2013 14:41:21 -0500

> Maybe we should indicate that "value" is NOT to be used with complex
> attributes?

+1.

Also note that there was some initial discussion on this topic [1] and a
corresponding ticket [2].

[1] http://www.ietf.org/mail-archive/web/scim/current/msg00928.html
[2] http://trac.tools.ietf.org/wg/scim/trac/ticket/36

On Tue, May 14, 2013 at 2:01 PM, <[email-masked]> wrote:

> ---------- Forwarded message ----------
> From: Phil Hunt <[email-masked]>
> To: scim WG <[email-masked]>
> Cc:
> Date: Tue, 14 May 2013 08:34:15 -0700
> Subject: [scim] Use of value for complex multi-valued attributes
> The current draft implies that value should be used for the significant
> attribute in a multi-valued attribute. It also says you can have
> multi-valued complex attributes.
>
> 3.2 <http://tools.ietf.org/html/draft-ietf-scim-core-schema-01#section-3.2>.  Multi-valued Attributes
>
>    Multi-valued attributes are unordered lists of attributes.  Each
>    attribute MAY contain Sub-Attributes and therefore multi-valued
>    attributes may contain Complex Attributes.  The below Sub-Attributes
>    are considered normative and when specified SHOULD be used as
>    defined.
>
>    type  A label indicating the attribute's function; e.g., "work" or
>       "home".
>
>    primary  A Boolean value indicating the 'primary' or preferred
>       attribute value for this attribute, e.g. the preferred mailing
>       address or primary e-mail address.  The primary attribute value
>       'true' MUST appear no more than once.
>
>    display  A human readable name, primarily used for display purposes.
>       READ-ONLY.
>
>
>
>
>
> Mortimore, et al.       Expires October 17, 2013                [Page 7]
>
>   <http://tools.ietf.org/html/draft-ietf-scim-core-schema-01#page-8>Internet-Draft          draft-scim-core-schema-01 <http://tools.ietf.org/html/draft-scim-core-schema-01>             April 2013
>
>
>    operation  The operation to perform on the multi-valued attribute
>       during a PATCH request.  The only valid value is "delete", which
>       signifies that this instance should be removed from the Resource.
>
>    value  The attribute's significant value; e.g., the e-mail address,
>       phone number, etc.  Attributes that define a "value" sub-attribute
>       MAY be alternately represented as a collection of primitive types.
>       For example:
>
>
> What is the intent of value for example with the addresses attribute?  I
> can think of three representations that are valid according to the current
> draft:
>
> *From example (no value used):*
> "addresses": [
>   {
>     "type": "work",
>     "streetAddress": "100 Universal City Plaza",
>     "locality": "Hollywood",
>     "region": "CA",
>     "postalCode": "91608",
>     "country": "USA",
>     "formatted": "100 Universal City Plaza\nHollywood, CA 91608 USA",
>     "primary": true
>   },
>   {
>     "type": "home",
>     "streetAddress": "456 Hollywood Blvd",
>     "locality": "Hollywood",
>     "region": "CA",
>     "postalCode": "91608",
>     "country": "USA",
>     "formatted": "456 Hollywood Blvd\nHollywood, CA 91608 USA"
>   }
> ]
>
> *What is probably the wrong approach:*
> "addresses": [
>   {
>      "type": "work",
>      "primary": true,
>      *"value": {*
>          "streetAddress": "100 Universal City Plaza",
>          "locality": "Hollywood",
>          "region": "CA",
>          "postalCode": "91608",
>          "country": "USA",
>          "formatted": "100 Universal City Plaza\nHollywood, CA 91608 USA"
>      }
>    },
>    {
>      "type": "home",
>      "value": {
>          "streetAddress": "456 Hollywood Blvd",
>          "locality": "Hollywood",
>          "region": "CA",
>          "postalCode": "91608",
>          "country": "USA",
>          "formatted": "456 Hollywood Blvd\nHollywood, CA 91608 USA"
>      }
>   }
> ]
>
> *Another approach would be to turn most significant sub-attribute into
> value:*
> "addresses": [
>   {
>     "type": "work",
>     "streetAddress": "100 Universal City Plaza",
>     "locality": "Hollywood",
>     "region": "CA",
>     "postalCode": "91608",
>     "country": "USA",
>     "value": "100 Universal City Plaza\nHollywood, CA 91608 USA",
>     "primary": true
>   },
>   {
>     "type": "home",
>     "streetAddress": "456 Hollywood Blvd",
>     "locality": "Hollywood",
>     "region": "CA",
>     "postalCode": "91608",
>     "country": "USA",
>     "value": "456 Hollywood Blvd\nHollywood, CA 91608 USA"
>   }
> ]
>
> Maybe we should indicate that "value" is NOT to be used with complex
> attributes?  Otherwise, I could see a lot of inter-op issues as people
> decide whih combinations or specific attribute is the significant attribute
> when it comes to complex attributes.
>
> Phil
>
> @independentid
> www.independentid.com
> [email-masked]
>
>
>
>
>
>
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim
>
>

---

From: Phil Hunt <[email-masked]>
Date: Tue, 14 May 2013 13:00:43 -0700

Shelly,

Thanks for pointing that out. The ticket already captures the issue.  

We should try to work to close it for the 02 draft as this seems like an easy issue.  :-)

Phil

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

On 2013-05-14, at 12:41 PM, Shelley wrote:

> 
> Maybe we should indicate that "value" is NOT to be used with complex attributes?
> 
> +1.
> 
> Also note that there was some initial discussion on this topic [1] and a corresponding ticket [2].
> 
> The current draft implies that value should be used for the significant attribute in a multi-valued attribute. It also says you can have multi-valued complex attributes.
> 
>> 
>> 3.2.  Multi-valued Attributes
>> 
>> Internet-Draft          draft-scim-core-schema-01             April 2013
>> 
>> 
> What is the intent of value for example with the addresses attribute?  I can think of three representations that are valid according to the current draft:
> 
> From example (no value used):
> "addresses": [
>   {
>     "type": "work",
> What is probably the wrong approach:
> "addresses": [
>   {
>      "type": "work",
>      "primary": true,
>      "value": {
> Another approach would be to turn most significant sub-attribute into value:
> "addresses": [
>   {
>     "type": "work",
> Maybe we should indicate that "value" is NOT to be used with complex attributes?  Otherwise, I could see a lot of inter-op issues as people decide whih combinations or specific attribute is the significant attribute when it comes to complex attributes.
> 
> Phil
> 
> @independentid
> www.independentid.com
> [email-masked]
> 
> 
> 
> 
> 
>