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
