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

[Elwyn Davies <[e-mail]>]

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