Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names

[Mike Jones]

The value of the explicit locale field is that it provides locale information 
to servers that want to use it without having to use any explicit language tags 
in the single-locale case.  I guess I don’t see the complication here.  With 
this solution, in the single-locale case, all fields would be passed without 
language tags (simple for both client and server), and a locale would be 
provided by the client (simple).  The server would store the locale but 
otherwise could ignore it if it knew that it was in a single-locale deployment.

I just don’t see it as being very hard for a registration request to include 
“default_registration_locale”:“en” and for the server to store it and return 
that value, but otherwise ignore it, if that reflects the realities of your 
particular deployment. :)

   -- 
Mike

From: Justin Richer [mailto:jric...@mitre.org]
Sent: Wednesday, March 20, 2013 12:11 PM
To: Mike Jones
Cc: George Fletcher; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable 
names

I agree that I'm seeing things from the single-language and single-encoding 
perspective here, and that's the use case I'm currently solving for with my 
development. I want to see this one remain simple, and I think we can do that 
without breaking other use cases.

I would argue that multi-script languages (such as Chinese, Japanese, and 
others) are all cases where you're going to assume multiple languages, and the 
tags would be necessary for real use. So client and AS would both need to know 
how to deal with the multiple different tags, and smart ones would be able to 
effectively ignore the default field. The default, scriptless field could be 
for any one of the supported languages at the AS or Client, and it'd 
effectively be a backup, internationalized version, the one that you use when 
there's nothing else more specific to use.

I guess what's getting me stuck on the explicit locale field is that I'm not 
seeing much value in requiring it over George's proposal of always using 
language tags on everything (which I also don't like, but for different 
reasons). Having the information doesn't mean that you can do anything 
intelligent with it, either, but I can see the argument that it makes doing 
something smart possible. But on the other hand, we already have a mechanism 
for doing something smart: using the explicit language tags directly.

Also, note that the AS doesn't need to render any characters for tos_uri, 
policy_uri, and other _uri options, just for client_name. That's why I was 
making the distinction in my explanation below. You might want to give the user 
the right option, sure, but a served webpage has a much better chance of 
getting the locale right dynamically than an included string would have 
(approaches like user preferences, browser settings, etc. -- everything that's 
used today on web pages, in other words). This is why I think that the _uri 
claims are in a different category and we're talking almost exclusively about 
client_name here.

I think, ultimately, that I need to think about this more.

  -- Justin
On 03/20/2013 02:30 PM, Mike Jones wrote:
I suspect you only feel that leaving the locale information out is OK because 
you (and I) live in a culture where it’s not needed to adequately render 
characters.  I’d actually defer on this decision to Nat and others from Japan 
and China (and I think Korea?) where I believe that this information is 
essential.

For what it’s worth, it’s more than just client_name.  It’s also tos_uri and 
policy_uri and potentially client_uri.

Also, having thought about it for a few days, I’d change the proposed field 
name from registration_locale to default_registration_locale, so the meaning is 
clearer.

Nat and others from Eastern cultures, what is your opinion on this?

Thanks,
-- Mike

From: Justin Richer [mailto:jric...@mitre.org]
Sent: Wednesday, March 20, 2013 10:43 AM
To: Mike Jones
Cc: George Fletcher; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable 
names

I would say that claims without a language parameter, which I would make 
REQUIRED in the presence of other claims, would be treated as UTF8 strings with 
no guarantee of what language, script, or other locale-specific information 
would be in there. It's a default string, and it's the best the client can give 
if nothing more specific is useful. And servers would have to accept this 
default string and do their best with it. A service provider can publish their 
expected default locale information in either discovery or service 
documentation, and clients that want to tweak things for specific service 
providers can do that.

The server can display it (because it's a string that'll always b

Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names

[Mike Jones]

I suspect you only feel that leaving the locale information out is OK because 
you (and I) live in a culture where it’s not needed to adequately render 
characters.  I’d actually defer on this decision to Nat and others from Japan 
and China (and I think Korea?) where I believe that this information is 
essential.

For what it’s worth, it’s more than just client_name.  It’s also tos_uri and 
policy_uri and potentially client_uri.

Also, having thought about it for a few days, I’d change the proposed field 
name from registration_locale to default_registration_locale, so the meaning is 
clearer.

Nat and others from Eastern cultures, what is your opinion on this?

Thanks,
-- Mike

From: Justin Richer [mailto:jric...@mitre.org]
Sent: Wednesday, March 20, 2013 10:43 AM
To: Mike Jones
Cc: George Fletcher; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable 
names

I would say that claims without a language parameter, which I would make 
REQUIRED in the presence of other claims, would be treated as UTF8 strings with 
no guarantee of what language, script, or other locale-specific information 
would be in there. It's a default string, and it's the best the client can give 
if nothing more specific is useful. And servers would have to accept this 
default string and do their best with it. A service provider can publish their 
expected default locale information in either discovery or service 
documentation, and clients that want to tweak things for specific service 
providers can do that.

The server can display it (because it's a string that'll always be there, if 
any version is there), but a server that doesn't do internationalized strings 
very well might not get its display correct. Since displayable text this is 
likely to be dumped into the middle of a webpage that has its own character 
encoding and other considerations anyway, so it's not guaranteed that 
specifying a locale will always help here anyway. This is just for the 
displayable text, which right now is only the client_name field in OAuth and 
OIDC: for URLs (the other "human-readable" field), it's a moot point, because 
the server's just going to spit out the URL itself into an href of some flavor. 
The server doesn't have to deal with any kind of encoding or text/script issues 
here.

As a server developer, it's just another thing that I *have* to track and deal 
with on the client model, even if I don't want to support the rest of the 
multi-language tags in my service. As a client developer, it's one more thing 
that I *have* to specify when I send things to the server. I don't see how 
requiring its specification is going to really help interoperability, and I can 
almost guarantee that implementations will just leave it off even if marked 
REQUIRED (like how many, many documents in the wild that are supposed to have a 
character-encoding field of some type just leave it off).

I think that it's a lot of work on both sides for just client_name.

 -- Justin

On 03/20/2013 01:27 PM, Mike Jones wrote:
How would you do this instead then?

From: Justin Richer
Sent: 3/20/2013 10:25 AM
To: Mike Jones
Cc: George Fletcher; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable 
names
Personally, I think that this level of specificity is overkill.

 -- Justin

On 03/14/2013 11:42 AM, Mike Jones wrote:
I agree that having unadorned values likely simplifies things in many cases, 
but if we do this, we should let the Client say what language/script it’s using 
when providing human-readable strings or references to them as registration 
parameters.  For this purpose, I’d propose that we have a parameter something 
like this one:

registration_locale
OPTIONAL or REQURED. Language and script used for human-readable values or 
references to human-readable values that are supplied without language/script 
tags, represented as a BCP47[RFC5646] language tag value.  This parameter is 
REQUIRED if any human-readable values or references to human-readable are 
provided without language/script tags.

-- Mike

From: oauth-boun...@ietf.org 
[mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer
Sent: Thursday, March 14, 2013 8:02 AM
To: George Fletcher
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable 
names

On the surface this does simplify things, but the issue I forsee with it is 
that I want to be able to call "client.getClientName()" and always get 
*something* out of it if there are *any* client_name fields at all. So in this 
world if I take a client library that assumes en-us and it talks to a server 
that only looks for es-cl, there's a ve

Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names

[Justin Richer]

I would say that claims without a language parameter, which I would make
REQUIRED in the presence of other claims, would be treated as UTF8
strings with no guarantee of what language, script, or other
locale-specific information would be in there. It's a default string,
and it's the best the client can give if nothing more specific is
useful. And servers would have to accept this default string and do
their best with it. A service provider can publish their expected
default locale information in either discovery or service documentation,
and clients that want to tweak things for specific service providers can
do that.

The server can display it (because it's a string that'll always be
there, if any version is there), but a server that doesn't do
internationalized strings very well might not get its display correct.
Since displayable text this is likely to be dumped into the middle of a
webpage that has its own character encoding and other considerations
anyway, so it's not guaranteed that specifying a locale will always help
here anyway. This is just for the displayable text, which right now is
only the client_name field in OAuth and OIDC: for URLs (the other
"human-readable" field), it's a moot point, because the server's just
going to spit out the URL itself into an href of some flavor. The server
doesn't have to deal with any kind of encoding or text/script issues here.

As a server developer, it's just another thing that I *have* to track
and deal with on the client model, even if I don't want to support the
rest of the multi-language tags in my service. As a client developer,
it's one more thing that I *have* to specify when I send things to the
server. I don't see how requiring its specification is going to really
help interoperability, and I can almost guarantee that implementations
will just leave it off even if marked REQUIRED (like how many, many
documents in the wild that are supposed to have a character-encoding
field of some type just leave it off).

I think that it's a lot of work on both sides for just client_name.

-- Justin


On 03/20/2013 01:27 PM, Mike Jones wrote:
> How would you do this instead then?
>
> 
> From: Justin Richer
> Sent: 3/20/2013 10:25 AM
> To: Mike Jones
> Cc: George Fletcher; oauth@ietf.org WG
> Subject: Re: [OAUTH-WG] Registration: Internationalization of
> Human-Readable names
>
> Personally, I think that this level of specificity is overkill.
>
> -- Justin
>
>
> On 03/14/2013 11:42 AM, Mike Jones wrote:
>>
>> I agree that having unadorned values likely simplifies things in many
>> cases, but if we do this, we should let the Client say what
>> language/script it’s using when providing human-readable strings or
>> references to them as registration parameters. For this purpose, I’d
>> propose that we have a parameter something like this one:
>>
>> registration_locale
>>
>> OPTIONAL or REQURED. Language and script used for human-readable
>> values or references to human-readable values that are supplied
>> without language/script tags, represented as a BCP47[RFC5646]
>> language tag value. This parameter is REQUIRED if any human-readable
>> values or references to human-readable are provided without
>> language/script tags.
>>
>> -- Mike
>>
>> *From:*oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On
>> Behalf Of *Justin Richer
>> *Sent:* Thursday, March 14, 2013 8:02 AM
>> *To:* George Fletcher
>> *Cc:* oauth@ietf.org WG
>> *Subject:* Re: [OAUTH-WG] Registration: Internationalization of
>> Human-Readable names
>>
>> On the surface this does simplify things, but the issue I forsee with
>> it is that I want to be able to call "client.getClientName()" and
>> always get *something* out of it if there are *any* client_name
>> fields at all. So in this world if I take a client library that
>> assumes en-us and it talks to a server that only looks for es-cl,
>> there's a very real chance of the client name not getting set at all.
>> I think that's a problem.
>>
>> This is why I think the default field name (without the language tag)
>> really should be required and should be left undefined as to what
>> language and script it is. Essentially, "It's a UTF8 String, hope for
>> the best". If you want something more specific and smart about
>> localization, then you can support the language tags. If you just
>> want to have a string to store and throw at the user, then you can
>> just use the bare field name.
>>
>> In other words, we take what we have now (which works for a
>> non-internationalized case where everyone just assumes a common
>> language/script), and we augment it with features that let it be
>> smarter if you want it to be smarter. Make the simple case simple,
>> make the complicated case possible.
>>
>> -- Justin
>>
>> On 03/14/2013 10:47 AM, George Fletcher wrote:
>>
>> As a simplifying option... why not just require human-readable
>> fields to require a "script-tag". This wa

Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names

[Mike Jones]

How would you do this instead then?


From: Justin Richer
Sent: 3/20/2013 10:25 AM
To: Mike Jones
Cc: George Fletcher; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable 
names

Personally, I think that this level of specificity is overkill.

 -- Justin


On 03/14/2013 11:42 AM, Mike Jones wrote:
I agree that having unadorned values likely simplifies things in many cases, 
but if we do this, we should let the Client say what language/script it’s using 
when providing human-readable strings or references to them as registration 
parameters.  For this purpose, I’d propose that we have a parameter something 
like this one:

registration_locale
OPTIONAL or REQURED. Language and script used for human-readable values or 
references to human-readable values that are supplied without language/script 
tags, represented as a BCP47[RFC5646] language tag value.  This parameter is 
REQUIRED if any human-readable values or references to human-readable are 
provided without language/script tags.

-- Mike

From: oauth-boun...@ietf.org 
[mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer
Sent: Thursday, March 14, 2013 8:02 AM
To: George Fletcher
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable 
names

On the surface this does simplify things, but the issue I forsee with it is 
that I want to be able to call "client.getClientName()" and always get 
*something* out of it if there are *any* client_name fields at all. So in this 
world if I take a client library that assumes en-us and it talks to a server 
that only looks for es-cl, there's a very real chance of the client name not 
getting set at all. I think that's a problem.

This is why I think the default field name (without the language tag) really 
should be required and should be left undefined as to what language and script 
it is. Essentially, "It's a UTF8 String, hope for the best". If you want 
something more specific and smart about localization, then you can support the 
language tags. If you just want to have a string to store and throw at the 
user, then you can just use the bare field name.

In other words, we take what we have now (which works for a 
non-internationalized case where everyone just assumes a common 
language/script), and we augment it with features that let it be smarter if you 
want it to be smarter. Make the simple case simple, make the complicated case 
possible.

 -- Justin


On 03/14/2013 10:47 AM, George Fletcher wrote:
As a simplifying option... why not just require human-readable fields to 
require a "script-tag". This way it is always explicit what language/locale the 
text is for. It then becomes the responsibility of the AS to return an 
appropriate response if there is not a direct match between a request and the 
data stored at the AS (and out of scope of the spec).

Thanks,
George
On 3/13/13 10:22 AM, Justin Richer wrote:
So with what little feedback I've gotten, I'm proposing to add text from the 
proposed webfinger and OIDC drafts for the hash-based localization of strings, 
with the following properties:

* All localized versions of fields are fully optional on both client and server
* If a localized version of a field is included, its bare-value (perhaps 
internationalized) field MUST be included
* All human-readable fields are eligible for this mechanism (including any 
uri's for user-facing web pages, which can be used to point to 
language-specific pages)
* Clients and servers can decide to use whatever language/script they want to 
for the bare-value field, and no assumptions can be made on either side about 
what that is

I think that with these constraints, we can add functionality to address 
Stephen's concerns without getting too complicated or putting too much burden 
of support.

 -- Justin
On 03/11/2013 06:52 PM, Nat Sakimura wrote:
Similar work is in progress at Webfinger.

See: http://www.ietf.org/mail-archive/web/webfinger/current/msg00530.html

Paul is proposing the same syntax as Connect.
2013/3/12 Richer, Justin P. mailto:jric...@mitre.org>>
It does presume a definition of "claim", which I suppose we could turn to 
"metadata field" for DynReg and its extensions to be appropriately limiting. 
But we also need a good definition of what a language-tag-less field means, and 
whether or not it's required if the other fields are present or not (which is 
something that Connect is trying to fix at the moment, as I recall from last 
week).

So it turns into about a paragraph worth of text. Is that worth it? I'm not 
entirely convinced that it is, but I'm interested to hear what others think, 
particularly those who *aren't* tied into the OpenID Connect protocol so much. 
(I don't want to pick a solution just because it's familiar, if we need a 
solution at all.)

 -- Justin

Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names

[Justin Richer]

Personally, I think that this level of specificity is overkill.

-- Justin


On 03/14/2013 11:42 AM, Mike Jones wrote:
>
> I agree that having unadorned values likely simplifies things in many
> cases, but if we do this, we should let the Client say what
> language/script it’s using when providing human-readable strings or
> references to them as registration parameters. For this purpose, I’d
> propose that we have a parameter something like this one:
>
> registration_locale
>
> OPTIONAL or REQURED. Language and script used for human-readable
> values or references to human-readable values that are supplied
> without language/script tags, represented as a BCP47[RFC5646] language
> tag value. This parameter is REQUIRED if any human-readable values or
> references to human-readable are provided without language/script tags.
>
> -- Mike
>
> *From:*oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On
> Behalf Of *Justin Richer
> *Sent:* Thursday, March 14, 2013 8:02 AM
> *To:* George Fletcher
> *Cc:* oauth@ietf.org WG
> *Subject:* Re: [OAUTH-WG] Registration: Internationalization of
> Human-Readable names
>
> On the surface this does simplify things, but the issue I forsee with
> it is that I want to be able to call "client.getClientName()" and
> always get *something* out of it if there are *any* client_name fields
> at all. So in this world if I take a client library that assumes en-us
> and it talks to a server that only looks for es-cl, there's a very
> real chance of the client name not getting set at all. I think that's
> a problem.
>
> This is why I think the default field name (without the language tag)
> really should be required and should be left undefined as to what
> language and script it is. Essentially, "It's a UTF8 String, hope for
> the best". If you want something more specific and smart about
> localization, then you can support the language tags. If you just want
> to have a string to store and throw at the user, then you can just use
> the bare field name.
>
> In other words, we take what we have now (which works for a
> non-internationalized case where everyone just assumes a common
> language/script), and we augment it with features that let it be
> smarter if you want it to be smarter. Make the simple case simple,
> make the complicated case possible.
>
> -- Justin
>
> On 03/14/2013 10:47 AM, George Fletcher wrote:
>
> As a simplifying option... why not just require human-readable
> fields to require a "script-tag". This way it is always explicit
> what language/locale the text is for. It then becomes the
> responsibility of the AS to return an appropriate response if
> there is not a direct match between a request and the data stored
> at the AS (and out of scope of the spec).
>
> Thanks,
> George
>
> On 3/13/13 10:22 AM, Justin Richer wrote:
>
> So with what little feedback I've gotten, I'm proposing to add
> text from the proposed webfinger and OIDC drafts for the
> hash-based localization of strings, with the following properties:
>
> * All localized versions of fields are fully optional on both
> client and server
> * If a localized version of a field is included, its
> bare-value (perhaps internationalized) field MUST be included
> * All human-readable fields are eligible for this mechanism
> (including any uri's for user-facing web pages, which can be
> used to point to language-specific pages)
> * Clients and servers can decide to use whatever
> language/script they want to for the bare-value field, and no
> assumptions can be made on either side about what that is
>
> I think that with these constraints, we can add functionality
> to address Stephen's concerns without getting too complicated
> or putting too much burden of support.
>
> -- Justin
>
> On 03/11/2013 06:52 PM, Nat Sakimura wrote:
>
> Similar work is in progress at Webfinger.
>
> See:
> 
> http://www.ietf.org/mail-archive/web/webfinger/current/msg00530.html
>
> Paul is proposing the same syntax as Connect.
>
> 2013/3/12 Richer, Justin P.  >
>
> It does presume a definition of "claim", which I suppose
> we could turn to "metadata field" for DynReg and its
> extensions to be appropriately limiting. But we also need
> a good definition of what a language-tag-less field means,
> and whether or not it's required if the other fields are
> present or not (which is something that Connect is trying
> to fix at the moment, as I recall from last week).
>
> So it turns into about a paragraph worth of text. Is that
> worth it? I'm not entirely convinced that it is, but I'm
> interested to hear what others think, particularly those