Hi Peter,
Fair enough. I'll take an action item to read RFC 6365 and review the related
text accordingly.
The main point of my commentary was that the processing of the parsed JSON
would be the same no matter what the original encoding used was.
For what it's worth, I think that the two paragraphs quoted from the recent
OpenID Connect Registration draft use the terminology correctly (but again,
I'll read RFC 6365 in a bit and try to check for myself). If they don't (since
you're volunteering to read , brave man that you are :-) ), suggested
corrections would be appreciated. They're repeated below...
Thanks again,
-- Mike
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.
-----Original Message-----
From: Peter Saint-Andre [mailto:[email protected]]
Sent: Monday, March 25, 2013 6:26 PM
To: Mike Jones
Cc: Justin Richer; Manger, James H; [email protected] WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable
names
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 3/25/13 12:08 PM, Mike Jones wrote:
> 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.
Mike and others, please read RFC 6365 at the very least to get some of the
terminology right here. For example, a Unicode code point is simply a numbered
point in a coded character set, say, U+03C0 (pi).
That code point is the same thing no matter whether it is written on a piece of
paper, mentioned in spoken text, etc. In an electronic representation on the
wire or in a file, the code point MUST be encoded using something like UTF-8
(which we prefer in IETF protocols) or UTF-16 or whatever. So it is incorrect
to say that "UTF-8 is just plain wrong, as once you’re in JSON you’re just
dealing with Unicode strings". It doesn't work that way!
Peter
- --
Peter Saint-Andre
https://stpeter.im/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRUPkaAAoJEOoGpJErxa2pJmUP/i4anZjL5pia4vJUA1RaY0Ht
ec6ItzKGZROEsIPM9jucFvrKyFYnvJARWYHQloWdnv89CCe0XzgX9Kr7LoLJuu+8
AHOosP6NWwxM2TR5PLC0akYKdyPnC6zenEyd94fx2Q12LXGmIBN6g3upveqmjsKW
EIk5VTQLV30tXIegmNbVZ6xbflw7rnXuRLc0HTTervAvQSTN9K4qVboDdFyiv3Si
oahzfxaEIOHo1ErljK2UzEc5YS7pQjwlPevzL2bc84ZJmuf9SwTD6vLUEeps0tAO
6dRb3B5gs2RFryLQGJ3/M0E4RL+aWc4zVd7tbFh5wF72uUA2o2BwEE6vyMdfuKmn
wgYtN9Tkxg9DlOQdfXg6FY5tk4mrWL/i1um1NXgTIy6b7loAZnD7yrliYWjtgBVf
Kns+QZOGgO2mkwnkLPI2KwRHRgX4JnXeDZYS1Kcg9yscq/Pdkb+8BfkNbn40TO8M
eEuq/mvvU3moAI3+TM6CbVJAwZqmVNsPiVv4M3tzA0lhgditq+rOHiQRvnoMwpzP
NLUBu0AJJUs3fnqf+YlG6jCS6lIT9gw/HMCjt1VVzm+hA+ntp5hqRBdXI0xqLyiN
LlYTI8W+BRPbnB9bhMX/KKgnvrKo/5zJZWmn1u/GztSapGP5cOr9w7DS/beYiC9K
5LgFphry8ahkTmR/BnD5
=UGRp
-----END PGP SIGNATURE-----
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
