Subject: [scim] Ticket 36 - Proper JSON representation of Complex Multi-valued Attrs (Addresses, Groups, eMails)

From: Phil Hunt <[email-masked]>
Date: Wed, 16 Apr 2014 09:43:36 -0700

Erik has raised an interesting issue with regards to how Addresses is represented in Ticket 36. 

Please consider the following below and indicate your preference for A (current) or B (revised).  Commentary is welcome. Depending on A or B we should apply the format to any multi-valued complex attribute representation.  

Regardless of the decision, I think some updates to the core schema documents are required.

Thanks… Phil

Discussion:

Address is supposed to be a multi-valued attribute. That means it is supposed to have 3 sub-attributes:  primary, type, and value.  However, Address is also a complex attribute. 

When this happens there are two JSON representations that appear legit (well it is debatable at least), we need to pick one:

A. Current Compact representation: 
"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"

}

]

B. Proposed corrected representation:
"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"

}

}

],

Notice that this second representation appears to be more correct because the “value” is the complex attribute portion.

One problem with “B" is that “value” can’t be can’t be compared. My thought is we should stick with “A” and stipulate the “value” should represent the default or primary attribute. Other impacted schema items include:  mail, groups, etc.

Phil

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

---

From: Kelly Grizzle <[email-masked]>
Date: Wed, 16 Apr 2014 16:55:09 +0000

+1 for A.

The spec makes it clear that value is an optional sub-attribute for complex multi-valued attributes.

I agree that this should be removed from the "addresses" description: "The value attribute is a complex type with the following sub-attributes."

--Kelly

From: scim [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Wednesday, April 16, 2014 11:44 AM
To: [email-masked] WG
Subject: [scim] Ticket 36 - Proper JSON representation of Complex Multi-valued Attrs (Addresses, Groups, eMails)

Thanks... Phil

Discussion:

"addresses": [

{

"type": "work",

},
{

"type": "home",

}

]

"addresses": [

{

"type": "work",
"primary": true,
"value":

{

}

},
{

"type": "home",
"value":

{

}

}

],
Notice that this second representation appears to be more correct because the "value" is the complex attribute portion.

One problem with "B" is that "value" can't be can't be compared. My thought is we should stick with "A" and stipulate the "value" should represent the default or primary attribute. Other impacted schema items include:  mail, groups, etc.

Phil

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

---

From: "Natale, Bob" <[email-masked]>
Date: Wed, 16 Apr 2014 17:51:24 +0000

+1 for A.

Avanti,
BobN

From: scim [mailto:[email-masked]] On Behalf Of Kelly Grizzle
Sent: Wednesday, April 16, 2014 12:55 PM
To: Phil Hunt; [email-masked] WG
Subject: Re: [scim] Ticket 36 - Proper JSON representation of Complex Multi-valued Attrs (Addresses, Groups, eMails)

+1 for A.

--Kelly

From: scim [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Wednesday, April 16, 2014 11:44 AM
To: [email-masked]<mailto:[email-masked]> WG
Subject: [scim] Ticket 36 - Proper JSON representation of Complex Multi-valued Attrs (Addresses, Groups, eMails)

Thanks... Phil

Discussion:

"addresses": [

{

"type": "work",

},
{

"type": "home",

}

]

"addresses": [

{

"type": "work",
"primary": true,
"value":

{

}

},
{

"type": "home",
"value":

{

}

}

],

Phil

@independentid

---

From: David Möbius <[email-masked]>
Date: Thu, 17 Apr 2014 09:02:40 +0200

+1 for A

by David

Am 16.04.2014 19:51, schrieb Natale, Bob:
> +1 for A.
> 
>  
> 
> Avanti,
> 
> BobN
> 
>  
> 
> *From:*scim [mailto:[email-masked]] *On Behalf Of *Kelly Grizzle
> *Sent:* Wednesday, April 16, 2014 12:55 PM
> *To:* Phil Hunt; [email-masked] WG
> *Subject:* Re: [scim] Ticket 36 - Proper JSON representation of Complex
> Multi-valued Attrs (Addresses, Groups, eMails)
> 
>  
> 
> +1 for A.
> 
>  
> 
> I agree that this should be removed from the “addresses” description: “The value attribute is a complex type with the following sub-attributes.”
> 
>  
> 
> --Kelly
> 
>  
> 
> *From:*scim [mailto:[email-masked]] *On Behalf Of *Phil Hunt
> *Sent:* Wednesday, April 16, 2014 11:44 AM
> *To:* [email-masked] <mailto:[email-masked]> WG
> *Subject:* [scim] Ticket 36 - Proper JSON representation of Complex
> Multi-valued Attrs (Addresses, Groups, eMails)
> 
>  
> 
> *_Please consider the following below and indicate your preference for A
> (current) or B (revised). _* Commentary is welcome. Depending on A or B
> we should apply the format to any multi-valued complex attribute
> representation.  
> 
>  
> 
> Address is supposed to be a multi-valued attribute. That means it is
> supposed to have 3 sub-attributes:  primary, type, and value.  However,
> Address is also a complex attribute. 
> 
>  
> 
> When this happens there are two JSON representations that appear legit
> (well it is debatable at least), we need to pick one:
> 
>  
> 
> *A. Current Compact representation: *
> 
>     "addresses": [
> 
>         {
> 
>             "type": "work",
> *B. Proposed corrected representation:*
> 
> "addresses": [
> 
>     {
> 
>         "type": "work",
>         "primary": true,
>         "value": 
> 
>             {
> 
> Notice that this second representation appears to be more correct
> because the “value” is the complex attribute portion.
> 
>  
> 
> One problem with “B" is that “value” can’t be can’t be compared. My
> thought is we should stick with “A” and stipulate the “value” should
> represent the default or primary attribute. Other impacted schema items
> include:  mail, groups, etc.
> 
>  
> 
> Phil
> 
>  
> 
> @independentid
> 
> www.independentid.com <http://www.independentid.com>
> 
> [email-masked] <mailto:[email-masked]>
> 
>  
> 
>  
> 
>  
> 
> 
> 
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim
>

---

From: David Crome <[email-masked]>
Date: Thu, 17 Apr 2014 16:07:04 +0200

+1 for A

Greetz,
David Crome

Am 17.04.14 09:02, schrieb David Möbius:
>> *From:*scim [mailto:[email-masked]] *On Behalf Of *Kelly
>> Grizzle *Sent:* Wednesday, April 16, 2014 12:55 PM *To:* Phil
>> Hunt; [email-masked] WG *Subject:* Re: [scim] Ticket 36 - Proper
>> JSON representation of Complex Multi-valued Attrs (Addresses,
>> Groups, eMails)
>> 
>> 
>> 
>> +1 for A.
>> 
>> 
>> 
>> I agree that this should be removed from the “addresses”
>> description: “The value attribute is a complex type with the
>> following sub-attributes.”
>> 
>> 
>> 
>> --Kelly
>> 
>> 
>> 
>> *From:*scim [mailto:[email-masked]] *On Behalf Of *Phil
>> Hunt *Sent:* Wednesday, April 16, 2014 11:44 AM *To:*
>> [email-masked] <mailto:[email-masked]> WG *Subject:* [scim] Ticket
>> 36 - Proper JSON representation of Complex Multi-valued Attrs
>> (Addresses, Groups, eMails)
>> 
>> 
>> 
>> *_Please consider the following below and indicate your
>> preference for A (current) or B (revised). _* Commentary is
>> welcome. Depending on A or B we should apply the format to any
>> multi-valued complex attribute representation.
>> 
>> 
>> 
>> Address is supposed to be a multi-valued attribute. That means it
>> is supposed to have 3 sub-attributes:  primary, type, and value.
>> However, Address is also a complex attribute.
>> 
>> 
>> 
>> When this happens there are two JSON representations that appear
>> legit (well it is debatable at least), we need to pick one:
>> 
>> 
>> 
>> "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"
>> 
>> }
>> 
>> ]
>> 
>> 
>> 
>> "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", 
>> Notice that this second representation appears to be more
>> correct because the “value” is the complex attribute portion.
>> 
>> 
>> 
>> One problem with “B" is that “value” can’t be can’t be compared.
>> My thought is we should stick with “A” and stipulate the “value”
>> should represent the default or primary attribute. Other impacted
>> schema items include:  mail, groups, etc.
>> 
>> 
>> 
>> Phil
>> 
>> 
>> 
>> @independentid
>> 
>> _______________________________________________ scim mailing
>> list [email-masked] https://www.ietf.org/mailman/listinfo/scim
>> 
> 
> _______________________________________________ scim mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/scim
> 

- -- 
David Crome
Softwareentwicklung
tarent solutions GmbH

Telefon +49 (0) 30 138803-132
Telefax +49 (0) 30 56829495
[email-masked]

tarent solutions GmbH  Niederlassung Berlin
Voltastraße 5, D-13355 Berlin • http://www.tarent.de/
Tel: +49 30 138803-0 • Fax: +49 30 56829495

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: Boris Esser, Sebastian Mancke

---

From: Melvin Laguren <[email-masked]>
Date: Thu, 17 Apr 2014 09:15:20 -0700

Vote for A

On Thu, Apr 17, 2014 at 7:07 AM, David Crome <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> +1 for A
>
> Greetz,
> David Crome
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
> Comment: GPGTools - https://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQGcBAEBCgAGBQJTT+AIAAoJEGggHv7AIBKqDTgL/0YviKd1Jv7Q1ZONAurXevUx
> bOsBaqpn7YKE/CbbL4f20fUcgV/4H4t+mFuC02Z0VjQgJV1O1f8dv12uXEvWL2H8
> RRIzdjxf6/7INxVGocZ3pcxZLqgF28WiQv2w92HPlnNKjscvCEkcy3jSY71EzbOc
> htT/plFQWpJSU1ZzzoUKoqPyc3+Kf0Q5jFDr4mY3JOTluS6j5q0DUO+mtJSHIZrP
> uqu8N5v7kbTqjb1txK+0JeesDn+3/AmnTMJoBsHcRF6Gq6w3OVMcixzQpjVu07WU
> g9NGKij/slikazvnUGy9Uu47eUoCrxinslcz076QCgdbYbf5L6xbYvnOUnMOA/CL
> /Mqz1Pmg+2m4HGyUw/h6vZleL3JNa2ngZdr7AVN1Ar4l/zAbbvz9EFMggaWSSoqv
> ZpB3+GL+Xgd+be5yUsfZ4cnUBJs8tUbEjW3XTw4UFAcVKaZc6Hk0817nrm79m5Vw
> USqUwvFZxt5DQPJhhEkam3Ew8p+WfvZGNU9siCbi1w==
> =2oMz
> -----END PGP SIGNATURE-----
>