FYI, the following version of this wording was incorporated into the OpenID
Connect Registration spec. I also found the phrase “internationalized UTF-8
string” ambiguous and so revised it. Also, UTF-8 is just plain wrong, as once
you’re in JSON you’re just dealing with Unicode strings, whether they were
originally encoded in UTF-8, UTF-16, or another encoding before parsing.
Human-readable Client Metadata values and Client Metadata values that reference
human-readable values MAY be represented in multiple languages and scripts. For
example, values such as client_name, tos_uri, policy_uri, logo_uri, and
client_uri might have multiple locale-specific values in some Client
registrations.
…
If such a human-readable field is sent without a language tag, parties using it
MUST NOT make any assumptions about the language, character set, or script of
the string value, and the string value MUST be used as-is wherever it is
presented in a user interface. To facilitate interoperability, it is
RECOMMENDED that any human-readable fields sent without language tags contain
values suitable for display on a wide variety of systems.
Best wishes,
-- Mike
From: [email protected] [mailto:[email protected]] On Behalf Of
Justin Richer
Sent: Monday, March 25, 2013 8:12 AM
To: Manger, James H
Cc: [email protected] WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable
names
"Internationalization is the process of designing a software application so
that it can be adapted to various languages and regions without engineering
changes." (From
http://en.wikipedia.org/wiki/Internationalization_and_localization)
What this means in our case is that you'd want a string that would be usable on
the widest variety of systems that you care about without them having to do
something special to handle it. For some, that's going to mean ASCII. For
others, it's going to mean some common local script.
And yes, the # character is appended to the field name, good catch.
-- Justin
On 03/21/2013 09:43 PM, Manger, James H wrote:
What is an “internationalized UTF-8 string”?
P.S. It would be worth explicitly stating that the # character and RFC5646
language tag are appended *to the field name* (not the value). I assume this is
right.
--
James Manger
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Justin Richer
Sent: Friday, 22 March 2013 5:15 AM
To: [email protected]<mailto:[email protected]> WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable
names
We discussed this issue on the OpenID Connect WG call this morning, in a
conversation that included myself, George Fletcher, Nat Sakimura, Mike Jones,
and John Bradley (among others) as active participants in this thread. After
lots of debate, we propose that the OAuth DynReg adopt the hashtag-based
localization method of OIDC (and it seems, possibly webfinger) and explicitly
declare that neither the client nor the server make any assumptions about the
content of the string and treat it as just a string. I'm proposing this text to
that effect (with the references to OIDC-messages removed and replaced with the
rule description itself in OAuth DynReg):
Fields with human-readable values or references to human-readable values, such
as client_name, tos_uri, policy_uri, and client_uri, MAY be represented in
multiple languages and scripts, specified by appending a # character and the
RFC5646 language tag. If any such human-readable field is sent without a
language tag, the server and the client MUST NOT make any assumptions about the
language, character set, or script of the value string, and the value string
MUST be used as-is wherever it is presented in either the client or server UI.
To facilitate interoperability, it is RECOMMENDED that any fields sent without
language tags contain an internationalized UTF-8 string suitable for display on
a wide variety of systems, and it is RECOMMENDED that clients send fields
without language tags in addition to any more-specifically denominated values.
Plus some examples.
(Anyone whose name I took in vain, please feel free to correct me.)
-- Justin
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
