[scim] Registering new schema (was Re: Question on the use of attributes from schema extensions)

[Phil Hunt <[e-mail]>]

Yes.  Wide open.  My understanding of the WG and the IESG intent is the only intent of review is to eliminate spammy registrations. 

Some thoughts...

Before you register, the only caution is that the WG has not really discussed (at length) how to handle versioning of schema (as opposed to versioning of the protocol). 

For example, if you were to submit a first draft of the “edu" schema, what should you do when you want to revise it?  Simply revise the current document registration, OR, register a new schema URN with version n.1?   The problem that arises is does a new “version” of a schema represent a different schema “bag” because it is technically a different URN.  Or is it a replacement?

I’m not sure it matters that much to the WG. But we might be able to collectively come up with some best practices. Something to think about.  Curious as to your thoughts.

Given the edu schema that’s been used in other protocols is actually very mature, I wouldn’t be afraid to register it sooner than later.  One item to consider is whether to make use of SCIM’s complex attributes if you are porting from the LDAP eduschema.  There’s a certain advantage in SCIM to be able to “type” multi-valued attributes (such as we have with emails and addresses).

Phil

@independentid
www.independentid.com
[e-mail]

> On Aug 14, 2015, at 11:31 AM, Keith Hazelton <[e-mail]> wrote:
> 
> Understood about the server-side support. Would you say the IANA registry process defined in Core Schema Section 10 is intended to be relatively open to outside contributions (such as higher ed) for new schema or schema extensions?    —Keith 
> -- 
> email & jabber: [e-mail] <mailto:[e-mail]>
> calendar: http://go.wisc.edu/i6zxx0 <http://go.wisc.edu/i6zxx0>
> 
> From: Phil Hunt
> Date: Friday, August 14, 2015 at 12:11 
> To: Keith Hazelton
> Cc: SCIM WG
> Subject: Re: [scim] Question on the use of attributes from schema extensions
> 
> From a protocol perspective it does not matter.
> 
> However we set aside that namespace in the IANA registry for those that want to use it to signal a schema is an “extension”.
> 
> In practice a server will only pay attention to those schemas that it lists under the /Schemas endpoint and will ignore the rest.  Wether a schema defines an object or an extension to an object is defined under /ResourceTypes.
> 
> Cheers,
> 
> Phil
> 
> @independentid
> www.independentid.com <http://www.independentid.com/>[e-mail] <mailto:[e-mail]>
>> On Aug 14, 2015, at 9:53 AM, Keith Hazelton <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Quick followup question: For custom extensions, does the unique schema value URI have to be under urn:ietf:params:scim:schemas:extension  or could it be under any valid uri?     —Keith
>> -- 
>> email & jabber: [e-mail] <mailto:[e-mail]>
>> calendar: http://go.wisc.edu/i6zxx0 <http://go.wisc.edu/i6zxx0>
>> 
>> From: Phil Hunt
>> Date: Friday, August 14, 2015 at 11:43 
>> To: Phil Hunt
>> Cc: Kelly Grizzle, Keith Hazelton, SCIM WG
>> Subject: Re: [scim] Question on the use of attributes from schema extensions
>> 
>> Ooops…  in my “good” example below, I forgot to make the schemas value "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User" consistent with the schema bag "urn:enterprise:2.0:User"
>> 
>> apologies for any confusion.
>> 
>> Phil
>> 
>> @independentid
>> www.independentid.com <http://www.independentid.com/>[e-mail] <mailto:[e-mail]>
>>> On Aug 14, 2015, at 9:41 AM, Phil Hunt <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> Keith,
>>> 
>>> Sorry for the late response.  Just got back from my off-the-grid holiday.  :-)
>>> 
>>> The example below (from Kelly) would likely not parse reliably as some parsers might only return the last or first instance.  The idea is to place all extension attributes together in a JSON “bag” which is a JSON attribute holding the name of the schema extension URI (as per the examples).
>>> 
>>> BAD:
>>>> "userName": "[e-mail] <mailto:[e-mail]>",
>>>> "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": {"employeeNumber": "701984" },
>>>> "displayName": "Babs Jensen",
>>>> "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": {"department": "Tour Operations" },
>>> 
>>> Good:
>>> {
>>>   "schemas":
>>>     [ "urn:ietf:params:scim:schemas:core:2.0:User",
>>>       "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"],
>>>   "id": "2819c223-7f76-453a-919d-413861904646",
>>>   "externalId": "701984",
>>>   "userName": "[e-mail] <mailto:[e-mail]>",
>>>   "name": {
>>>     "formatted": "Ms. Barbara J Jensen III",
>>>     "familyName": "Jensen",
>>>     "givenName": "Barbara",
>>>     "middleName": "Jane",
>>>     "honorificPrefix": "Ms.",
>>>     "honorificSuffix": "III"
>>>   },
>>>   "displayName": "Babs Jensen",
>>>   "nickName": "Babs",
>>> 
>>>   “urn:enterprise:2.0:User”: {
>>>      "employeeNumber": "701984",
>>>      “costCenter": "4130",
>>>      "organization": "Universal Studios",
>>>      "division": "Theme Park",
>>>     "department": "Tour Operations",
>>>     "manager": {
>>>        "value": "26118915-6090-4610-87e4-49d8ca9f808d",
>>>        "$ref": "../Users/26118915-6090-4610-87e4-49d8ca9f808d",
>>>        "displayName": "John Smith"
>>>      }
>>>   }
>>> ...
>>> }
>>> 
>>> “urn:enterprise:2.0:User” could be any extension URN you define.  Thus if you define attributes of same name as urn:ietf:params:scim:schemas:extension:enterprise:2.0:User”, then there is no collision.
>>> 
>>> In this sense, every attribute is prefixed with its own schema.  We do not have to worry about attribute name collisions since the base object and each extension have their own position in the json structure.
>>> 
>>> You will also notice that when referring to those attributes, you use the schema uri plus the attribute extension name together.  Eg.
>>> 
>>> filter=urn:enterprise:2.0:User:organization eq “Universal Studio"
>>> 
>>> At the time we wrote this specification, there was still a tremendous pushback in the JSON community on having any schema at all.  As a result, we adopted a very “loose” model that focuses on letting a parser know what attributes may be present in a JSON object that also avoids naming conflicts.
>>> 
>>> Hopefully this helps.
>>> 
>>> Thanks for the comments!
>>> 
>>> Phil
>>> 
>>> @independentid
>>> www.independentid.com <http://www.independentid.com/>[e-mail] <mailto:[e-mail]>
>>>> On Aug 11, 2015, at 10:14 AM, Kelly Grizzle <[e-mail] <mailto:[e-mail]>> wrote:
>>>> 
>>>> Hmmm … I don’t think the docs are quite so clear on that one.  In JSON, ordering does not matter, so it doesn’t matter if it is interleaved with other attributes or not.  However, JSON also does not allow multiple keys with the same name.  In other words, this will not work:
>>>>  
>>>> "userName": "[e-mail] <mailto:[e-mail]>",
>>>> "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": {"employeeNumber": "701984" },
>>>> "displayName": "Babs Jensen",
>>>> "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": {"department": "Tour Operations" },
>>>> ...
>>>>  
>>>>  
>>>> From: scim [mailto:[e-mail] <mailto:[e-mail]>] On Behalf Of Keith Hazelton
>>>> Sent: Tuesday, August 11, 2015 12:07 PM
>>>> To: SCIM WG
>>>> Subject: Re: [scim] Question on the use of attributes from schema extensions
>>>>  
>>>> Kelly,
>>>>  
>>>> Thanks for your quick response.
>>>>  
>>>> So does 'the sub-attribute must be named using the schema extension URI” mean that all the enterprise user attributes have to appear together in a uri-container as indicated in draft-22, Figure 5: Example Enterprise User JSON Representation:
>>>>  
>>>> …
>>>>  "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": {
>>>>     "employeeNumber": "701984",
>>>>     "costCenter": "4130",
>>>>     "organization": "Universal Studios",
>>>>     "division": "Theme Park",
>>>>     "department": "Tour Operations",
>>>>     "manager": {
>>>>       "value": "26118915-6090-4610-87e4-49d8ca9f808d",
>>>>       "$ref": "../Users/26118915-6090-4610-87e4-49d8ca9f808d",
>>>>       "displayName": "John Smith"
>>>>     }
>>>>   },
>>>> …
>>>> 
>>>>  Or could the extended attributes be interleaved with the User schema attributes by putting each one in that form, e.g.,
>>>> 
>>>>  …
>>>> "userName": "[e-mail] <mailto:[e-mail]>",
>>>> "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": {"employeeNumber": "701984",},
>>>> "displayName": "Babs Jensen",
>>>> …
>>>> -- 
>>>> email & jabber: [e-mail] <mailto:[e-mail]>
>>>> calendar: http://go.wisc.edu/i6zxx0 <http://go.wisc.edu/i6zxx0>
>>>>  
>>>> From: Kelly Grizzle
>>>> Date: Tuesday, August 11, 2015 at 11:48 
>>>> To: Keith Hazelton, SCIM WG
>>>> Subject: RE: Question on the use of attributes from schema extensions
>>>>  
>>>> named using th
>>>> _______________________________________________
>>>> scim mailing list
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/scim <https://www.ietf.org/mailman/listinfo/scim>
>>> 
>> 
>> _______________________________________________
>> scim mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/scim <https://www.ietf.org/mailman/listinfo/scim>
> 
> _______________________________________________
> scim mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/scim