--On Friday, November 14, 2014 19:00 -0700 Peter Saint-Andre - &yet <[email protected]> wrote:
> FYI. > > > -------- Original Message -------- > Subject: [http-auth] Allowed Characters in usernames and > passwords > Date: Fri, 14 Nov 2014 15:59:00 -1000 > From: Yoav Nir <[email protected]> > To: IETF HTTP Auth <[email protected]> > > Hi > > An issue that has been discussed on the list has been what > characters are allowed for usernames and passwords in the > Basic and Digest documents (this probably also applies to > other specification, specifically MutualAuth, but that is not > the issue in this message). > > So the precis working group is creating the saslprepbis ([1]) > document that should be published soon (as soon as the end of > this year). That contains a profile for characters that are > and aren't recommended for use in username and passwords. > > So the proposal that reflects the consensus of the people in > today's session is as follows: > > Both the Basic and Digest drafts will mandate that supporting > servers MUST support usernames and passwords that conform to > the saslprepbis specification, and MAY support non-conforming > ones. The rationale is that we have to have a MAY there, > because we can't prohibit stuff that works today. Both > documents will add text with these MUST and MAY. > > The room was unanimous in supporting this direction. If you > disagree, please comment to the list by Monday 24-Nov-2014. > Since we had a strong hum for in the room, we will take > silence as consensus Peter, Yoav, Given my ongoing mini-campaign to reduce the number of profiles and sets of rules to an absolute minimum because users won't be able to keep track of different ones and will only be astonished and confused, this is exceptionally good news. Two comments: (1) While the assertion that you "can't prohibit stuff that works" is probably true, you are not thereby limited to MAY. It would be entirely consistent with IETF practices in the past to say "MUST support ... that conform and SHOULD avoid non-conforming ones except when the latter are justified by compatibility with existing implementations". That still doesn't _prohibit_ the existing practices, but makes the desired compatibility norm somewhat more clear. (2) I assume there are recommendations coming out of WHATWG and/or W3C that might interact with whatever HTTP-AUTH has to say. If that is the case, I expect that the HTTP-AUTH recommendation will either be consistent with them or will identify and explain the differences. It would be reasonable for you to assume that both comments above will, if necessary, be repeated during IETF Last Call. best, john _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
