> > 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.)
+1 on getting off of 8859-* being a good thing to do (IMHO). Among other items, I'd be concerned about non-ASCII characters being interpreted and rendered in the wrong 8859 charset when the locale uses an 8859 charset other than 8859-1. At a minimum, Unicode doesn't have that problem ;-). Thanks, --David > -----Original Message----- > From: precis [mailto:[email protected]] On Behalf Of Yutaka OIWA > Sent: Sunday, October 26, 2014 12:45 AM > To: Martin J. Dürst > Cc: [email protected] > Subject: Re: [precis] usernames in PRECIS and http-auth > > 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. > > 2014-10-26 12:36 GMT+09:00 "Martin J. Dürst" <[email protected]>: > > Hello Peter, > > > > On 2014/10/23 11:38, Peter Saint-Andre - &yet wrote: > >> > >> [ Old thread alert! ] > >> > >> On 3/25/14, 12:52 AM, Yutaka OIWA wrote: > > > > > >>> My answers to the Peter's questions: > >>> > >>>> "Y u taka O i w a" > >>> > >>> > >>> Current HTTP allows it, and we don't need to reject that mostly. > >> > >> > >> Does the HTTPAUTH WG want to support everything that HTTP currently > >> supports, or is it open to restricting things a bit more? > > > > > > 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*. > > > > Essentially, the server operator will have to mechanically check which user > > names won't work anymore in the new protocol, and then contact these users > > and ask them to change their user name or tell them that their user name was > > modified. Not all users might like that. > > > > > >> Has there been further discussion about this in the HTTPAUTH WG? I'm on > >> that mailing list and I haven't seen much discussion on this topic. > > > > > > Me neither. > > > > > > Regards, Martin. > > _______________________________________________ > precis mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/precis _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
