Subject: [scim] Addresses Value Attribute

From: Shelley <[email-masked]>
Date: Mon, 11 Feb 2013 11:34:22 -0600

There seems to be a slight ambiguity in the definition of the addresses
attribute as to whether it has a "value" sub-attribute.

The "addresses" attribute defined in the core schema (6.2) indicates that
it is a "multi-valued attribute" and that its "value attribute is a complex
type with the following sub-attributes". As such, it would seem that the
appropriate representation would be something similar to the following:

  "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"
        }
    }
  ],

However, the protocol specification indicates "Attributes that do not have
a value Sub-Attribute; e.g., addresses" (3.3.2), implying that "addresses"
does NOT have a "value" attribute. Further, the examples throughout the
core specification (11.2, 11.3, 11.6) and protocol spec (3.3.2) use the
following representation, which imply that there is no "value" attribute:

  "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"
    }
  ]

Is the latter form the correct representation? If so, the "addresses"
attribute description should probably be updated to remove the reference to
its "value attribute" and perhaps clarify that it has no "value" attribute.

---

From: Erik Wahlström <[email-masked]>
Date: Mon, 18 Feb 2013 10:35:14 +0000

+1

I just created a ticket for that. http://trac.tools.ietf.org/wg/scim/trac/ticket/36

/ Erik

On Feb 11, 2013, at 6:34 PM, Shelley wrote:

There seems to be a slight ambiguity in the definition of the addresses attribute as to whether it has a "value" sub-attribute.

The "addresses" attribute defined in the core schema (6.2) indicates that it is a "multi-valued attribute" and that its "value attribute is a complex type with the following sub-attributes". As such, it would seem that the appropriate representation would be something similar to the following:

  "addresses": [
    {
      "type": "work",
      "primary": true,
      "value":
        {

However, the protocol specification indicates "Attributes that do not have a value Sub-Attribute; e.g., addresses" (3.3.2), implying that "addresses" does NOT have a "value" attribute. Further, the examples throughout the core specification (11.2, 11.3, 11.6) and protocol spec (3.3.2) use the following representation, which imply that there is no "value" attribute:

  "addresses": [
    {
      "type": "work",

Is the latter form the correct representation? If so, the "addresses" attribute description should probably be updated to remove the reference to its "value attribute" and perhaps clarify that it has no "value" attribute. _______________________________________________
scim mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scim