"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:*oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On
Behalf Of *Justin Richer
*Sent:* Friday, 22 March 2013 5:15 AM
*To:* oauth@ietf.org 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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
