Re: [scim] Name Internationalization

[Kelly Grizzle <[e-mail]>]

I agree with Erik that this might best be handled through an extension (perhaps a standard extension).  It feels like the common case is still a single name and that i18n names/multiple names may be more of the exception than the rule.  I may be wrong, though.

> I guess this means in the JSON case, that you can put new elements anywhere you want, as long as you create a new URI and put it in the "schemas" attribute?

This is something the design team is discussing in issue #38.  It is not clearly spelled out in the spec currently, but extensions must be represented within a JSON sub-attribute named by the schema.  For example, the non-normative enterprise user example in the schema doc has this:

  "urn:scim:schemas:extension:enterprise:1.0": {
    "employeeNumber": "701984",
    "costCenter": "4130",
    ....
  },

I think this would preclude you from mixing extension attributes in with the core attributes, like this:

  "name": {
    "formatted": "Kelly Grizzle",
    "urn:scim:extendedUser.alsoKnownAs": [ ... ]
    ...
}

--Kelly

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Bert Greevenbosch
Sent: Wednesday, March 27, 2013 5:42 AM
To: Shelley; [e-mail]; Marc Blanchet
Cc: Peter Saint-Andre
Subject: Re: [scim] Name Internationalization

Hi Shelly, all,

In vCard, all name info is put into a single N element. The different names of the same type are comma-separated, whereas the different types are semicolon-separated.

For addresses, the SCIM schema defines an "addresses" element that contains multiple "address" elements. However, there is no "names" element, but that wouldn't help anyway. The given name is e.g. stored in "name/givenName", so with the "singular in plural element mechanism" you would need something like "name/givenNames/givenName" if you want to store multiple given names. I am not sure if this is desirable.

Maybe multiple names could be resolved by just allowing spaces within the field and treating it as an opaque string.

For adding new name fields, I found the following text in section 4:

	"Unlike LDAP there is no inheritance model; all extensions are additive (similar to LDAP Auxiliary Object Classes [3]). ... Each schema extension must identify a URI used to identify the extension. XML MUST use XML namespaces and JSON formats MUST use the "schemas" attribute (Section 5.2) to distinguish extended resources and attributes. "

I guess this means in the JSON case, that you can put new elements anywhere you want, as long as you create a new URI and put it in the "schemas" attribute?

(As JCARDCAL co-chair:) We are having a very similar discussion in JCARDCAL, about multivalue fields, and structured fields. As discussed in Orlando, it would be good for SCIM to keep acquainted with the JCARDCAL work.

Best regards,
Bert


---
From: Shelley [mailto:[e-mail]] 
Sent: 2013年3月26日 3:07
To: Bert Greevenbosch
Cc: Marc Blanchet; [e-mail]
Subject: Re: [scim] Name Internationalization

Thanks, Bert. So to clarify, in the SCIM/vCard mapping proposal, multiple name components will be comma-separated in the corresponding SCIM singular attribute? In our case, we are initially considering space-delimiting the components such that this would effectively serve as a "formatted" familyName/givenName/etc. and could potentially accommodate contributing systems that only store single-valued name attributes as well.

With a comma-delimited value, all SCIM consumers must be aware of this special format when dealing with the attribute. With a space-delimited value, consumers may not be able to retrieve the individual values, but can handle the name consistently without attempting to parse and regardless of the origin of the data (i.e. whether it came from a system that only stores a single value or multiple values).

I also noticed that the SCIM/vCard draft includes this as an open issue, proposing that it may be more appropriate to update the SCIM schema to handle multiple values. Is this a topic that's currently being discussed?

We are currently adopting the SCIM 1.1 specification, but are trying to consider potential changes for SCIM 2.0 in our implementation.

On Mon, Mar 25, 2013 at 12:41 AM, Bert Greevenbosch <[e-mail]> wrote:
I stumbled across the same issue when doing v02 of the SCIM/vCard mapping draft. See section 6.
http://datatracker.ietf.org/doc/draft-greevenbosch-scim-vcard-mapping/
 
Indeed in vCard multiple surnames, given names and additional names are possible.
 
Best regards,
Bert
 
From: [e-mail] [mailto:[e-mail]] On Behalf Of Marc Blanchet
Sent: 2013年3月25日 6:35
To: Shelley
Cc: [e-mail]
Subject: Re: [scim] Name Internationalization
 
might want to look at vCard  (RFC6350).
 
Marc.
 
Le 2013-03-22 à 22:59, Shelley <[e-mail]> a écrit :

As a SCIM service provider, we are trying to determine the best approach for accepting and managing names that may be federated from global consumers.

Were there any considerations made in the SCIM core schema for using multi-valued attributes for the individual name components? The use of the "familyName" and "givenName" as opposed to "firstName"/"lastName" helps minimize a western/US-centric approach, but using three individual, singular attributes for these name components still hints at a particular name format that may not be global.

For example, in many countries, individuals have a given name and two last names (rather than first name, middle name, last name). Does SCIM provide any recommendations for how to represent this using the existing name components? For example, are consumers expected to consolidate all last names into the single familyName attribute to accommodate this scenario? Likewise, there are many other cases [1,2] that don't quite cleanly fit into these singular name components.

The "formattedName", "displayName", and "nickName" attributes help to mitigate some concerns around formatting names and addressing users, but we're still trying to iron out how to accept identity data from varying contributing sources as well as enable consumers to obtain the discrete name components.

[1] http://www.w3.org/International/questions/qa-personal-names
[2] http://en.wikipedia.org/wiki/Personal_name
_______________________________________________
scim mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/scim
 

_______________________________________________
scim mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/scim