[ietf-nntp] authinfo-02 changes

[Clive D. W. Feather]

-----BEGIN PGP SIGNED MESSAGE-----

In message <410538C4.3090508 at oceana.com>, Ken Murchison <ken at oceana.com>
writes
>>>+username = 1*(P-CHAR / SP / TAB)
>>>+password = 1*(P-CHAR / SP / TAB)
>>>+initial-response = base64-opt
>>   This syntax isn't compatible with the general command syntax.
>>Instead,
>> you want:
>>     username = user-pass-word *(WS user-pass-word)
>>    password = user-pass-word *(WS user-pass-word)
>>    user-pass-word = 1*P-CHAR
>>  This makes it clearer that the username/password can be treated as a
>>string
>> of words and that no special parsing is needed.
>
>I'm not sure that I understand/appreciate the difference here, but I'll
>make the change if nobody else objects.

It's a fairly subtle point, but basically what my syntax says is:
- - the command line is made up of words separated by white space, and
- - the username is made up of those words after "USER";
while your syntax says:
- - the username is those characters after "USER".

Suppose I use _ to represent space. Then your syntax implies that:
    AUTHINFO_USER_fred_flintstone
    AUTHINFO_USER_fred__flintstone
are different and must be distinguished, whereas mine doesn't - it
implies the user name is "fred" followed by "flintstone". Secondly, my
syntax makes it clear that:
    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?

>Yes, you are correct.  The SASL WG had a discussion about this and
>decided that empty success data really had no meaning and/or use, so it
>will be forbidden in RFC 2222bis.

Fine - that agrees with your latest syntax.

>>   I'm bothered about this restriction to uppercase. The ABNF syntax
>>says that
>> "USER" and "SASL" are case-insensitive, and our only other example ("MSGID"
>> argument to "OVER") is also case-insensitive. The rest of NNTP (e.g. command
>> names) is also case-insensitive.
>>  Consistency with other extensions says that you should add LOWER to
>>this
>> list, or even move to A-CHAR, and be case-insensitive.
>This is mandated by RFC 2222(bis):

Hmm. So:

    aUtHiNfO sAsL PLAIN weeble

is fine but

    authinfo sasl plain weeble

isn't.

You could allow it to be case insensitive (thus requiring the server to
uppercase the method internally). But it's not a major point; I'll leave
it up to you to decide where to go with this.

- -- 
Clive D.W. Feather     | Internet Expert | Work: <clive at demon.net>
Tel: +44 20 8495 6138  | Demon Internet  | Home: <clive at davros.org>
Fax: +44 870 051 9937  | Thus plc        | Web:  <http://www.davros.org>
Please reply to the Reply-To address, which is:  <clive at demon.net>

-----BEGIN PGP SIGNATURE-----
Version: PGP SDK 3.0.2

iQEVAwUBQQdrUiNAHP3TFZrhAQELkwf/UOT1hFSpCjsVET+IOqISN5b367iKO2oV
mBGRltyt0Tm10ADlgv3qDj2Rg6RY5zN34RNHwrYaKd/bCOnrXI6QvAv4++NYckaD
IK/q0jo6QpiyQPHzUBf8NcRJlH9xvkNXnW5jl5jslOnN/UqfjRvLUUnV5zO44bB/
hbUFuyAISRQdZXkhLG4xChmic6ZoEYY1RlbjdTeRkqom256u5eYqxIq5NiV8FhPW
H7terYa2OEcC4AOq8/oMP9qfUZnb+NNOCwoNLiLWjj4DNO/d35cHUjRxUEi1TwQP
qKLjuJ+Ldgyd6Rfhj6llIAy9VQ3uCEMZR8euuD5l0ybN/hy2Zl7CEA==
=3kwg
-----END PGP SIGNATURE-----