Subject: [scim] can a User address be primary

From: David Moebius <[email-masked]>
Date: Tue, 3 Dec 2013 15:51:05 +0100

Hello,

in the document http://tools.ietf.org/html/draft-ietf-scim-core-schema-02
at point

*http://tools.ietf.org/html/draft-ietf-scim-core-schema-02#section-12.2
<http://tools.ietf.org/html/draft-ietf-scim-core-schema-02#section-12.2>*

*you can find an example that a address can be primary*

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

at the point http://tools.ietf.org/html/draft-ietf-scim-core-schema-02#section-12.7

"name":"addresses",
          "type":"complex",
          "multiValued":true,
          "description":"A physical mailing address for this User, as
described in (address Element). Canonical Type Values of work, home,
and other. The value attribute is a complex type with the following
sub-attributes.",

Mortimore, et al.        Expires March 03, 2014                [Page 31]

  <http://tools.ietf.org/html/draft-ietf-scim-core-schema-02#page-32>Internet-Draft
         draft-scim-core-schema-02
<http://tools.ietf.org/html/draft-scim-core-schema-02>
August 2013

          "readOnly":false,
          "required":false,
          "caseExact":false,
          "subAttributes":[
            {
              "name":"formatted"

...

it looks like that address should not have the field primary.

Since it makes sence for me I would think that it is ok if a address
is primary.

Can you conform this?

by David

---

From: Erik Wahlström <[email-masked]>
Date: Tue, 3 Dec 2013 16:42:43 +0000

Hi,
Yes,  it can be primary. Its a multivalue attribute and one of the upsides of that is that you get an primary attribute automatically.
/ Erik
________________________________________
From: scim [[email-masked]] on behalf of David Moebius [[email-masked]]
Sent: Tuesday, December 03, 2013 3:51 PM
To: [email-masked]
Subject: [scim] can a User address be primary

Hello,

http://tools.ietf.org/html/draft-ietf-scim-core-schema-02#section-12.2

you can find an example that a address can be primary

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

"name":"addresses",
          "type":"complex",
          "multiValued":true,
          "description":"A physical mailing address for this User, as described in (address Element). Canonical Type Values of work, home, and other. The value attribute is a complex type with the following sub-attributes.",

 <http://tools.ietf.org/html/draft-ietf-scim-core-schema-02#page-32>
Internet-Draft          draft-scim-core-schema-02<http://tools.ietf.org/html/draft-scim-core-schema-02>            August 2013

          "readOnly":false,
          "required":false,
          "caseExact":false,
          "subAttributes":[
            {
              "name":"formatted"

...

Since it makes sence for me I would think that it is ok if a address is primary.

Can you conform this?

by David

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Wed, 4 Dec 2013 08:46:21 +0000

Interesting, I had not read that text that way, but I agree that currently
that seem to be the correct interpretation. But the question is whether
that is correct or we should fix it.

Speaking as one of the implementers, I don't think it is the right
assumption that all multi-valued attributes will have "type", "primary",
and "display" sub attributes. I certainly agree it makes sense for
"addresses" to have those, but not as a general statement for all
multi-valued attributes.  For example in case of "photos" (or
entitlements, roles, etc.) we may not need/want such sub-attributes.

Cheers,
Morteza

On 12/3/13 8:42 AM, "Erik Wahlström" <[email-masked]> wrote:

>Hi,
>Yes,  it can be primary. Its a multivalue attribute and one of the
>upsides of that is that you get an primary attribute automatically.
>/ Erik
>at the point 
>http://tools.ietf.org/html/draft-ietf-scim-core-schema-02#section-12.7
>
>"name":"addresses",
>          "type":"complex",
>          "multiValued":true,
>described in (address Element). Canonical Type Values of work, home, and
>other. The value attribute is a complex type with the following
>sub-attributes.",
>
>
>
>Internet-Draft    
>draft-scim-core-schema-02<http://tools.ietf.org/html/draft-scim-core-schem
>a-02>            August 2013
>
>
>          "readOnly":false,
>          "required":false,
>          "caseExact":false,
>          "subAttributes":[
>            {
>              "name":"formatted"
>
>...
>
>_______________________________________________
>scim mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/scim

---

From: Erik Wahlström <[email-masked]>
Date: Wed, 4 Dec 2013 14:04:15 +0000

All attributes are "unless otherwise specified are optional” so I guess it’s up to each implementation if they would like to use the attributes primary, type and so on on each multi-valued attribute. Maybe some implementors would like to have a primary picture, like facebooks profile picture, so I don’t think we should define if it’s possible to have it or not on each multi-valued attribute.

/ Erik

---

From: Michael Hammer <[email-masked]>
Date: Wed, 4 Dec 2013 14:44:39 +0000

Ummm...  Ambiguity is not good in a standard.
Having multiple interpretations will affect interoperability.

Mike

-----Original Message-----
From: scim [mailto:[email-masked]] On Behalf Of Morteza Ansari
(moransar)
Sent: Wednesday, December 04, 2013 3:46 AM
To: Erik Wahlström; David Moebius; [email-masked]
Subject: Re: [scim] can a User address be primary

Interesting, I had not read that text that way, but I agree that currently
that seem to be the correct interpretation. But the question is whether that
is correct or we should fix it.

Speaking as one of the implementers, I don't think it is the right
assumption that all multi-valued attributes will have "type", "primary", and
"display" sub attributes. I certainly agree it makes sense for "addresses"
to have those, but not as a general statement for all multi-valued
attributes.  For example in case of "photos" (or entitlements, roles, etc.)
we may not need/want such sub-attributes.

Cheers,
Morteza

On 12/3/13 8:42 AM, "Erik Wahlström" <[email-masked]> wrote:

>in the document 
>http://tools.ietf.org/html/draft-ietf-scim-core-schema-02
>at point
>
>
>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 4 Dec 2013 09:01:08 -0800

I don't think the spec is ambiguous. But the fact that "primary" is an inherited feature of a multi-value type does make it somewhat hidden.

It would be good to include an example of a "primary" address in the draft.

Phil

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

---

From: Michael Hammer <[email-masked]>
Date: Wed, 4 Dec 2013 17:35:13 +0000

When someone says they didn't read it that way.
When someone says there are multiple interpretations.
There is ambiguity.

I just scanned the text for the word "primary".

You have the statement:  
"The primary attribute value 'true' MUST appear no more than once."
This appears to be a global statement.  I have to assume that applies to any
complete description.
Yet, you have examples showing "primary" used multiple times with value =
"true".
I was looking to see where it specifies what values this may be applied to.

There was this restriction:
"referenceTypes  The names of the Resource Types that may be
            referenced; e.g., User.  This is only applicable for
            attributes that are of the "reference" data type.

            The following multi-valued attributes are defined.  There
            are no canonical type values defined and the primary value
            serves no useful purpose."

But, that restriction seems scoped solely to referenceTypes.
Absent any other restrictions, I would assume that any multi-valued
attribute can include the "primary" attribute.
If that is not true...

Also, if you are referring to the "primary" attribute, you should identify
it as a formal attribute and not as casual text.
I can't tell if all uses of the word "primary" in the document always refer
to the attribute or not.

This is underspecified and ambiguous.
Please don't be dismissive.  Fix it.

Mike

-----Original Message-----
From: Phil Hunt [mailto:[email-masked]] 
Sent: Wednesday, December 04, 2013 12:01 PM
To: Michael Hammer
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]

I don't think the spec is ambiguous. But the fact that "primary" is an
inherited feature of a multi-value type does make it somewhat hidden.

Phil

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

On 2013-12-04, at 6:44 AM, Michael Hammer <[email-masked]>
wrote:

> Interesting, I had not read that text that way, but I agree that 
> currently that seem to be the correct interpretation. But the question 
> is whether that is correct or we should fix it.
> 
> assumption that all multi-valued attributes will have "type", 
> "primary", and "display" sub attributes. I certainly agree it makes sense
for "addresses"
> attributes.  For example in case of "photos" (or entitlements, roles, 
> etc.) we may not need/want such sub-attributes.
> 
> 
> 
> Cheers,
> Morteza
> 
>> draft-scim-core-schema-02<http://tools.ietf.org/html/draft-scim-core-
>> sc
>> hem
>> a-02>            August 2013
>> 
>> 
>>         "readOnly":false,
>>         "required":false,
>>         "caseExact":false,
>>         "subAttributes":[
>>           {
>>             "name":"formatted"
>> 
>> ...
>>