Re: [Gen-art] Gen-art last call review of draft-ietf-scim-core-schema-17

[Phil Hunt <[e-mail]>]

Elwyn,

Thanks for this. I think these changes are reasonable and strike a better balance on standardized canonicalization vs. providing allowance for discretion.

I will add to the next update. 

Phil

[e-mail]

> On May 7, 2015, at 10:02 AM, Elwyn Davies <[e-mail]> wrote:
> 
> Hi, Phil.
> 
> In my last email I realized I left in something about a further email I was going to send.  This was due to my thinking the telechat was sooner than it actually is.
> 
> In creating this email, I realized that I wasn't sure whether the set of pre-defined sub-attributes in s2.4 (for the individual values of multi-valued complex-type attributes) should also apply to a single complex valued attribute.
> 
> But the main point was about canonicalization.
> 
> In the previous email, I had:
> 
>>>> s7, canonicalValues:  The wording here
>>>>>         When
>>>>>         applicable service providers MUST specify the canonical types
>>>>>         specified in the core schema specification; e.g., "work",
>>>>>         "home".
>>>> seems to imply that the possible canonicalValues mentioned in the definitions of User, Group etc.
>>>> schemas earlier in the draft are actually normative minimum requirements that could, at least in
> >>> some cases, be extended.  The wording used in the earlier sections is rather less definitive and
>>>> appears to indicate that the suggested values are examples that a service provider might possible
> >>>want to replace if they considered alternative values better suited to their application, e.g.
>>>>>   userType
>>>>>      Used to identify the organization to user relationship. Typical
>>>>>      values used might be "Contractor", "Employee", "Intern", "Temp",
>>>>>      "External", and "Unknown" but any value may be used.
>>>> and
>>>>>   phoneNumbers
>>>>>      Phone numbers for the user.   ...  The "display" sub-attribute
>>>>>      MAY be used to return the canonicalized representation of the
>>>>>      phone number value.  The sub-attribute "type" often has typical
>>>>>      values of "work", "home", "mobile", "fax", "pager", and "other",
>>>>>      and MAY allow more types to be defined by the SCIM clients.
>>>> The wording used in the earlier sections seems to need 'tightening up'to make it clear what minimum set of canonicalValues is required for conformance, if indeed that is what is wanted.
>>> [PH] Agreed. Suggestion:
>>> 
>>> A collection of suggested values for an attribute. For example often used with the “type” attribute to categorize a value such as “home” or “work”.  The service providerMAY choose to ignore values it does not support.
>> This helps.  The wording in s4.1.2 needs a little more work (see other email)....
> [So here it is]
> 
> Is it intended that the various canonical values of the "type" sub-attribute for emails, etc., stated in s4.1.2 are normative requirements?
> 
> It seems possible that there is a subtle difference between the "ims" and "photos" cases and the others:  For the "ims" and "photos" cases a different canonicalization is or might be needed for each possible type values, in which case the values would have to be tied down and be made normative, whereas the others are just a convenience for human users that would not generally be interpreted by machines with the same canonicalization whatever the value of "type".  OTOH, having standardized values helps the internationalization of the user interface in clients.
> 
> If so I would suggest that these are rephrased to make it clear, for example, for emails (and similarly for phoneNumbers and addresses):
> OLD:
>      The "type" sub-attribute of contains values of "work", "home", and
>      "other", and MAY allow more types to be defined by the SCIM
>      clients.
> NEW:
>      The "type" sub-attribute is used to provide a classification
>      meaningful to the (human) user.  The user interface should
>      encourage the use of basic values of "work", "home",
>      and "other", and MAY allow additional type values to be used
>      at the discretion of the SCIM clients.
> 
> For "ims" (and similarly for "photos"):
> OLD:
>      The "type"
>      attribute defines several "canonicalValues" to represent currently
>      popular IM services: "aim", "gtalk", "icq", "xmpp", "msn",
>      "skype", "qq", "yahoo", and "other".
> NEW:
>      The "type" sub-attribute SHOULD take one of the following
>      values: "aim", "gtalk", "icq", "xmpp", "msn", "skype", "qq",
>      "yahoo", and "other", representing currently popular IM services
>      at the time of writing. Service providers MAY add further values
>      if new IM services are introduced and MAY specify more detailed
>      canonicalization rules for each possible value.
> 
> 
> 
> Regards,
> Elwyn