[ietf-nntp] AUTHINFO draft 01

[Ken Murchison]

Clive D.W. Feather wrote:

> 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.

Correct, but I think the problem is how does the server know what is 
part of the username/password vs. trailing junk.  Or am I missing 
something obvious here?

As an aside: Do clients really send trailing junk, and why was this 
allowed in the first place?


> 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.

The reason I used the "sasl-" prefix was so that there would be no 
possibly chance of a conflict between future "mechanism" or "challenge" 
NNTP syntax elements.  I have no objection to ditching the "sasl-" prefix.


> 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.

I'll leave this for Russ and/or the rest of the group to decide.


> 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.

OK.  Is this the case even for command-specific responses (as opposed to 
generic responses)?  So an extension can NOT dictate the format of its 
own response?



> 2.2.3 example of abort: I wouldn't use the word "successfully" there;
> perhaps:
> 
>     481 Authentication aborted as requested

Good point.


> 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.)

Actually *() is correct, because there may not be any continuation, for 
instance when using PLAIN or EXTERNAL with an initial response.


> I believe
> this approach will turn out to be more useful.

So you don't think the formal syntax should show that there may be 
multiple exchanges?  AUTHINFO SASL is unique in this sense.  POST/IHAVE 
only have one such exchange, where SASL may have several.


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

My feelings on this probably hinge on the decision on the previous point.


> 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.

OK, I'll go with "=" for consistency.


> 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".

OK.


> 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.

All of the best practice stuff is Jeff's baby and I'll let him comment. 
  This should probably be handled by someone who's more of a Usenet guru 
than I anyways.


> 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.

Are you suggesting removing the reference or moving it to informative?


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

They are moving along.  I can use the existing RFC's rather than the 
updates I-Ds, but hopefully one or more will be completed before this 
document gets to the editor.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp