Re: [scim] Name Internationalization

[Erik Wahlström <[e-mail]>]

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": {
  "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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/scim