[ietf-nntp] AUTHINFO draft 01

Clive D.W. Feather clive at demon.net
Wed Jun 23 12:19:35 PDT 2004


I've finally got round to reading this. I think it's mostly fine, but have
a few points.

2.1.2 last para: if you change the syntax to
    AUTHINFO USER username...
    AUTHINFO PASS password...

then the white-space problem mostly goes away, because:

    AUTHINFO USER fred flintstone
    AUTHINFO PASS very secret

becomes legal.

2.2.1 et al: I would use "mechanism", "challenge", and "init-response"
rather than "sasl-mech-name", "sasl-server-chal", and "sasl-init-resp". The
context is SASL, so I don't think the "sasl-" bit adds anything and it
makes it harder to read.

2.2.1: we discussed briefly a separate response code meaning "invalid
base64 string". The logical code for this is 504 (it belongs in the 50x
space and this is the next unused code). There's still time to put that in
[NNTP], incidentally.

2.2.2 para 4: this implies that no trailing text may occur, as in:

    383 = nothing to say

whereas [NNTP] requires it to be allowed. You may want to adjust the
wording.

2.2.3 example of abort: I wouldn't use the word "successfully" there;
perhaps:

    481 Authentication aborted as requested

3.2: I intended that "command-continuation" should represent one step in the
to-and-fro between client and server. This means removing the *() from the
definition of authinfo-sasl-continuation. (In any case, it should have
been 1*(), since you require at least one continuation line.) I believe
this approach will turn out to be more useful.

3.2: I still think you should eliminate "sasl-client-response", putting it
straight into the value of authinfo-sasl-continuation.

3.2: I think you should have "=" as the empty client response rather than
just a newline. That would be more consistent with the server responses.
Note that 2.2.2 doesn't mention the possibility of an empty client response
but 3.2 does; the former should be corrected.

3.5: in sasl-mech-char, use UPPER rather than %x41.5A, since it is defined
in [NNTP]. I also think the grammar would benefit from a non-terminal:

    base64-opt = "=" / base64

factoring out the concept "base64 string that could be empty".

Ken wrote:
> I'm trying to keep the grammar as close to that used in RFC 1734bis and
> RFC 2554bis, so I'd rather keep it as base64.
but I'm not proposing changing that.

5: I don't believe that it's appropriate to say that an identity looks like
an email address, particularly since the concept isn't used anywhere in
this document. At most you need just the last paragraph, but the rest
better belongs in [USEFOR].

8/9: the current "best practice" appears to be for these to be 8.1 and 8.2.

8: I don't believe [UTF-8] is normative for your document (though it is for
[NNTP]). In any case, the correct referent is RFC 3629.

8: The three SASL references won't be acceptable to move this to RFC
status. What stage are these documents at?

-- 
Clive D.W. Feather  | Work:  <clive at demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive at davros.org>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |



More information about the ietf-nntp mailing list