Subject: [scim] Name Internationalization

From: Shelley <[email-masked]>
Date: Fri, 22 Mar 2013 21:59:51 -0500

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

---

From: Marc Blanchet <[email-masked]>
Date: Sun, 24 Mar 2013 18:35:24 -0400

might want to look at vCard  (RFC6350).

Marc.

Le 2013-03-22 à 22:59, Shelley <[email-masked]> 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.
> 
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: Bert Greevenbosch <[email-masked]>
Date: Mon, 25 Mar 2013 05:41:00 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Marc Blanchet
Sent: 2013年3月25日 6:35
To: Shelley
Cc: [email-masked]
Subject: Re: [scim] Name Internationalization

Marc.

Le 2013-03-22 à 22:59, Shelley <[email-masked]<mailto:[email-masked]>> a écrit :

[email-masked]<mailto:[email-masked]>

---

From: Tom Scavo <[email-masked]>
Date: Mon, 25 Mar 2013 06:47:45 -0400

> Indeed in vCard multiple surnames, given names and additional names are

Yes, but perhaps there should be one and only one displayName. Such is
the case in the LDAP inetOrgPerson Object Class
(http://www.ietf.org/rfc/rfc2798.txt).

Tom

---

From: Tatsuo Kudo <[email-masked]>
Date: Tue, 26 Mar 2013 00:45:44 +0900

I think most of attributes currently defined as "Singular Attributes"
in the schema draft should allow multi-valued ones as well for
non-English environment.  For example, businesses in Japan usually
store Kanji and Kana characters (cf.
http://en.wikipedia.org/wiki/Japanese_writing_system) for almost all
attributes from name to department.

I prefer Kelly Grizzle's suggestion in his follow-up to my question last month.

 http://www.ietf.org/mail-archive/web/scim/current/msg00926.html

And would like to apply it other than phonetic representation like:

"displayName": [
    { "value": "<Kana characters>", "locale": "ja-kana-JP" },
    { "value": "<Kanji characters>", "locale": "ja-JP" }
  ]

Thoughts?

Tatsuo.

On Mon, Mar 25, 2013 at 2:41 PM, Bert Greevenbosch
<[email-masked]> wrote:
> 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.
>
> 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.
>
> Likewise, there are many other cases [1,2] that don't quite cleanly fit into
> these singular name components.
>
> contributing sources as well as enable consumers to obtain the discrete name
> components.
>

---

From: Shelley <[email-masked]>
Date: Mon, 25 Mar 2013 14:06:58 -0500

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 <
[email-masked]> 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:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Marc Blanchet
> *Sent:* 2013年3月25日 6:35
> *To:* Shelley
> *Cc:* [email-masked]
> *Subject:* Re: [scim] Name Internationalization****
>
> ** **
>
> might want to look at vCard  (RFC6350).****
>
> ** **
>
> Marc.****
>
> ** **
>
> Le 2013-03-22 à 22:59, Shelley <[email-masked]> a écrit :****
>
>
>
> ****
>
> https://www.ietf.org/mailman/listinfo/scim****
>
> ** **
>

---

From: 関森信之 <[email-masked]>
Date: Tue, 26 Mar 2013 08:11:22 +0900

This discuss is very interesting. I think the current specification of name
attributes is not extensible enough. Shelley has considered multiplicity of
name attributes. I will show another issue of 'Name Internationalization'.

As Tatsuo was saying; Countries using Kanji have various appearances of
name. These countries need to consider logographic scripts and syllabic
scripts, separately. In Japan, we use syllabic scripts 'Kana' for sorting,
do not use logographic  'Kanji' scripts. If any name attributes have only
logographic value, we are not able to sort as well.

For resolving this issue, vCard adopts parameter 'SORT-AS'. I think this is
a nice for SCIM. For example:

"name": {
  "familyName": "logographic".
  "givenName": "logographic",
  "familyName-SORT-AS": "syllabic",
  "givenName-SORT-AS": "syllabic"
}

Thoughts?

2013/3/26 Tatsuo Kudo <[email-masked]>

> > possible.
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Marc
> > Blanchet
> > Sent: 2013年3月25日 6:35
> > To: Shelley
> > Cc: [email-masked]
> for
> singular
> name

---

From: Erik Wahlström <[email-masked]>
Date: Wed, 27 Mar 2013 08:18:33 +0000

Hi,
Would it be possible to roll this into an real scim extension? One that adds the SORT-AS functionality?

A (very rough) example to show possible way forward.

.....
"urn:scim:schemas:extension: nameinternationalization:1.0": {
    "name-SORT-AS": {
        "familyName-SORT-AS": "syllabic",
        "givenName-SORT-AS": "syllabic"
    }
  },
...

/ Erik

On Mar 26, 2013, at 12:11 AM, 関森信之 wrote:

This discuss is very interesting. I think the current specification of name attributes is not extensible enough. Shelley has considered multiplicity of name attributes. I will show another issue of 'Name Internationalization'.

As Tatsuo was saying; Countries using Kanji have various appearances of name. These countries need to consider logographic scripts and syllabic scripts, separately. In Japan, we use syllabic scripts 'Kana' for sorting, do not use logographic  'Kanji' scripts. If any name attributes have only logographic value, we are not able to sort as well.

For resolving this issue, vCard adopts parameter 'SORT-AS'. I think this is a nice for SCIM. For example:

"name": {

Thoughts?

2013/3/26 Tatsuo Kudo <[email-masked]<mailto:[email-masked]>>

"displayName": [

Thoughts?

Tatsuo.

On Mon, Mar 25, 2013 at 2:41 PM, Bert Greevenbosch
<[email-masked]<mailto:[email-masked]>> wrote:
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Marc
> Blanchet
> Sent: 2013年3月25日 6:35
> To: Shelley
> Cc: [email-masked]<mailto:[email-masked]>

---

From: Bert Greevenbosch <[email-masked]>
Date: Wed, 27 Mar 2013 10:41:43 +0000

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:[email-masked]] 
Sent: 2013年3月26日 3:07
To: Bert Greevenbosch
Cc: Marc Blanchet; [email-masked]
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 <[email-masked]> 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/

Best regards,
Bert

 
Marc.

---

From: Kelly Grizzle <[email-masked]>
Date: Wed, 27 Mar 2013 13:10:49 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Bert Greevenbosch
Sent: Wednesday, March 27, 2013 5:42 AM
To: Shelley; [email-masked]; Marc Blanchet
Cc: Peter Saint-Andre
Subject: Re: [scim] Name Internationalization

Hi Shelly, all,

Best regards,
Bert

---

 
 
Best regards,
Bert

 
Marc.

---

From: Nobuyuki Sekimori <[email-masked]>
Date: Thu, 28 Mar 2013 11:46:25 +0900

Sorry, I'd sent mail without my sign and my mail sender's name was with
Kanji. My name is Nobuyuki Sekimori.

Thanks Bert and Kelly, for brushing up my opinion.

-- 
Nobuyuki Sekimori

2013/3/27 Kelly Grizzle <[email-masked]>

> 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:
>
> Bert Greevenbosch
> 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.
>
>         "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
>
>
> ---
> 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"
> Marc Blanchet

---

From: n-sakimura <[email-masked]>
Date: Thu, 28 Mar 2013 15:31:13 +0900

familyName-SORT-AS is nice, but that probably does not bring us very far.

In many cases, a name may have multiple scripts representations.
ja-Kana-JP representation of the name is one such case, which happens to 
be used for sorting.

So, IMHO, Tatsuo's proposal is more general and preferable.

FYI, OpenID Connect and OAuth Registration adopted this approach though 
to comply with "flat schema for basic cases principle", we opted to 
append the language tag after #:

e.g. name#ja-Kana-JP.

One possible variation on Tatsuo's proposal would be to adopt modified 
BCP47 langauge tag (use "_" instead of "-") to make it possible to 
reference it as a part of javascript names. e.g.,

"displayName": {
	"en":"<English alphabet representation>",
	"ja_Kana_JP":"<Katakana Representation>",
	"ja_Jpn_JP":"<Kanji Kana Mixed Representation>"
}

Nat

(2013/03/26 8:11), 関森信之 wrote:
> This discuss is very interesting. I think the current specification of
> name attributes is not extensible enough. Shelley has considered
> multiplicity of name attributes. I will show another issue of 'Name
> Internationalization'.
>
> scripts, separately. In Japan, we use syllabic scripts 'Kana' for
> sorting, do not use logographic 'Kanji' scripts. If any name attributes
> have only logographic value, we are not able to sort as well.
>
> 2013/3/26 Tatsuo Kudo <[email-masked] <mailto:[email-masked]>>
>
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
>     mapping
>      > draft. See section 6.
>      > From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] On
>     Behalf Of Marc
>      > Blanchet
>      > Sent: 2013年3月25日 6:35
>      > To: Shelley
>      > Cc: [email-masked] <mailto:[email-masked]>
>      > Le 2013-03-22 à 22:59, Shelley <[email-masked]
>     <mailto:[email-masked]>> a écrit :
>      >
>      >
>      >
>      > [email-masked] <mailto:[email-masked]>
>      > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

-- 
Nat Sakimura ([email-masked])
Nomura Research Institute, Ltd.
Tel:+81-3-6274-1412 Fax:+81-3-6274-1547

本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信 
することを意図しております。意図された受取人以外の方によるこれらの情報の 
開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メール 
を受信された場合は、申し訳ございませんが、送信者までお知らせいただき、受 
信されたメールを削除していただきますようお願い致します。
PLEASE READ:
The information contained in this e-mail is confidential and intended 
for the named recipient(s) only.
If you are not an intended recipient of this e-mail, you are hereby 
notified that any review, dissemination, distribution or duplication of 
this message is strictly prohibited. If you have received this message 
in error, please notify the sender immediately and delete your copy from 
your system.