Spaces in usernames and passwords (was: authinfo-02 changes)

[Russ Allbery]

Ken Murchison <ken at oceana.com> writes:
> Clive D.W. Feather wrote:
>> Ken Murchison said:
>>> Clive D.W. Feather wrote:

>>>>   AUTHINFO_PASS_secret
>>>>   AUTHINFO_PASS_secret_
>>>>   AUTHINFO_PASS__secret
>>>>   AUTHINFO_PASS__secret_

>>>> are all equivalent (the password is "secret") while yours has a
>>>> parsing ambiguity: is the second space after PASS, or the trailing
>>>> space, part of the passwords or not?

>>> I believe each of these should be different.

>> Same issue.  In addition, it makes the whole grammar ambiguous, since
>> there becomes more than one way to parse the same line.

> Anyone else have any opinions?

Hm.  As Jeff noted, we decided not to implement this in INN because it was
too invasive.  I may end up redoing the INN parser in a way that lets one
special-case AUTHINFO more easily later, but I'm guessing that other
parsers would be in the same place as INN's current one.

I'm happy to let servers do the work of supporting arbitrary whitespace in
the AUTHINFO arguments if they really want to, but I don't want to require
it.  In practice, it frequently won't work, and I don't expect people to
put effort into their old AUTHINFO implementations to make it work.

I think Ken's ABNF is cleaner in that it lets one more easily talk about
how some servers will parse the argument as words and some won't, and
Clive's ABNF makes it look like all servers will parse the arguments as
words, so it seems easier to get to both possible behaviors from Ken's
approach than from Clive's.  But I do think we need to make it very clear
that servers may parse the AUTHINFO arguments like any other NNTP command.

As for the parsing ambiguity, my inclination would be to resolve it in
Ken's grammar by having USER or PASS be followed by one and only one
whitespace character, with everything following that being part of the
username or password if an implementation should care to parse it that
way.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>