On 10/25/14, 10:44 PM, Yutaka OIWA wrote:
Hello Martin,
I think the main question here would be deployability. The server is under
control of the person who decides what to allow, and clients get eventually
updated. But introducing restrictions like this might mean upgrading *users*.
Yes. However, at the same time, the character set which is currently
officially allowed on HTTP spec is ISO-8859-1 only, the ad-hoc handling of
non-ISO-8859-1 characters on HTTP authentication at this moment
is anyway not guaranteed to be interoperable.
(And because of ad-hoc handling of non-ISO-8859-1 characters,
The latter half of ISO-8859-1 is also not well interoperable in reality.)
The HTTP community is going to adopt use of UTF-8 (with explicit
flag for using that), and it will anyway break backward compatibility
with non-ASCII usernames/passwords. (It will explicitly change
encoding of non-ASCII, ISO-8859-1 characters.)
It means that, at this moment, we CAN define the proper way of
handling for non-ASCII UTF-8 strings (with possible smallest
incompatibility with existing ad-hoc implementations),
and it is the last possible moment to do that
without severely breaking backward compatibility with
spec-conformant implementations.
Of course, it should not break any compatibility with existing
ASCII printable username/passwords.
I think it's probably best to have this discussion on the HTTPAUTH list.
I will start a thread there.
Peter
--
Peter Saint-Andre
https://andyet.com/
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
