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 [email protected] > On May 7, 2015, at 10:02 AM, Elwyn Davies <[email protected]> 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 _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
