Re: [scim] Name Internationalization

[n-sakimura <[e-mail]>]

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


-- 
Nat Sakimura ([e-mail])
Nomura Research Institute, Ltd.
Tel:[phone] Fax:[phone]

本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信 
することを意図しております。意図された受取人以外の方によるこれらの情報の 
開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メール 
を受信された場合は、申し訳ございませんが、送信者までお知らせいただき、受 
信されたメールを削除していただきますようお願い致します。
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.