Subject: [scim] Localizable group names

From: Phil Hunt <[email-masked]>
Date: Mon, 29 Sep 2014 10:32:41 -0700

Please comment and if possible answer the embedded question below…

<individual hat>
I’ve received a question on how to handle localization of groups names.

The current “displayName” is single valued and thus can only support one localized value.  E.g. you can create a group name in Dutch, but then it can’t be displayed in english (nor can multiple locale names be maintained through scim) unless you create multiple groups (which causes other problems). 

While displayName for Group and User is consistent and is acceptable, groups have the additional problem of needing to be understood in multiple languages at the same time — particularly groups that drive access controls.

We considered doing this with ALH and “displayName” but we are concerned about it causing other issues as many systems may be using displayName as a fixed key (whether this is good is another discussion).

We are now considering using a schema extension (e.g. enterprise Group), but it seems like this would be more usefully done in an inter-operable way as part of Group core schema.

Question: Would the group support a new multi-valued attribute called “globalNames” that can be used to maintain and retrieve multiple localized names for the same group?

Under Multi-valued attributes for Group:

globalNames
   An optional multi-valued attribute containing group names for specific locales. For each localized value, the corresponding “type” sub-attribute is a language tag as defined in [RFC5646].
 
</individual hat>

<editor>
This is a change, but it is an optional addition and seems minor.

Service providers that do not plan to support would have to simply ignore the value (they should be ignoring attributes they don’t understand anyway).
</editor>

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Grahame Grieve <[email-masked]>
Date: Tue, 30 Sep 2014 05:51:15 +1000

If you're really going to consider localization issues with names, a single
displayName for a user is a problem - the question is not which language it
is in, but which script - many systems support recording names in both
Latin and local script, since some users can't read

This would appear to be relevant for group name too

Grahame

On Tuesday, September 30, 2014, Phil Hunt <[email-masked]> wrote:

> The current “displayName” is single valued and thus can only support one
> localized value.  E.g. you can create a group name in Dutch, but then it
> can’t be displayed in english (nor can multiple locale names be maintained
> through scim) unless you create multiple groups (which causes other
> problems).
>
> While displayName for Group and User is consistent and is acceptable,
> groups have the additional problem of needing to be understood in multiple
> languages at the same time — particularly groups that drive access controls.
>
> We considered doing this with ALH and “displayName” but we are concerned
> about it causing other issues as many systems may be using displayName as a
> fixed key (whether this is good is another discussion).
>
> We are now considering using a schema extension (e.g. enterprise Group),
> but it seems like this would be more usefully done in an inter-operable way
> as part of Group core schema.
>
> *Question: Would the group support a new multi-valued attribute called
> “globalNames” that can be used to maintain and retrieve multiple localized
> names for the same group?*
>
>    An optional multi-valued attribute containing group names for specific
> locales. For each localized value, the corresponding “type” sub-attribute
> is a language tag as defined in [RFC5646].
>
> </individual hat>
>
> <editor>
> Service providers that do not plan to support would have to simply ignore
> the value (they should be ignoring attributes they don’t understand anyway).
> </editor>
>
> Phil
>
> @independentid
> www.independentid.com
> [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>
>
>
>

-- 
-----
http://www.healthintersections.com.au / [email-masked]
/ +61 411 867 065

---

From: Kelly Grizzle <[email-masked]>
Date: Mon, 29 Sep 2014 19:54:07 +0000

In the past we have recommended people that are concerned with i18n’d values to use extensions.  This problem likely goes beyond the names of groups and users, so my preference is to let implementers do this in an extension.

From: scim [mailto:[email-masked]] On Behalf Of Grahame Grieve
Sent: Monday, September 29, 2014 2:51 PM
To: Phil Hunt
Cc: SCIM WG
Subject: Re: [scim] Localizable group names

If you're really going to consider localization issues with names, a single displayName for a user is a problem - the question is not which language it is in, but which script - many systems support recording names in both Latin and local script, since some users can't read

Grahame

On Tuesday, September 30, 2014, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:
Please comment and if possible answer the embedded question below…

<individual hat>

globalNames

</individual hat>

<editor>

Phil

@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>

--
-----
http://www.healthintersections.com.au / [email-masked]<mailto:[email-masked]> / +61 411 867 065