[ietf-nntp] AUTHINFO draft 01

[Clive D.W. Feather]

Ken Murchison said:
>> 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?

Not a problem, and yes.

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

Clients *don't* send trailing junk - if there are too many arguments, the
server MUST respond with 501.

*Servers* send trailing junk; the idea is to allow human-readable
explanations on the end of the response.

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

Hmm. It shouldn't matter, because anything like that will be in a different
document, but I do see your point.

In that case, "sasl-mechanism" and "sasl-challenge" are more readable, I
think. It's minor, though.

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

Okay.

Russ et al: it will only take 5 minutes or so for me to do and I think it's
a good use of standardisation. In section 3.2.1, after the third paragraph,
add:

    As a special case, if an argument is required to be a [BASE64] encoded
    string (there are no such in this specification, but there may be in
    extensions) and is not a valid encoding, the response code 504 MUST be
    returned.

plus an example and a change to relevant boilerplates.

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

Yes.

> So an extension can NOT dictate the format of its 
> own response?

No, because the idea is to allow standardised parsers in clients.

You can decide how many arguments the response has, and whether it is
multi-line or not, but that's all. See [NNTP] 3.2; the two paragraphs
following the definition of x9x. Arguments are separated by single spaces,
numeric arguments are decimal, string arguments may not be empty,
multi-line uses dot-stuffing, etc.

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

In which case you aren't invoking "command-continuation" at all.

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

No. However, I do think I should add text explaining what's going on here
in the syntax. Here's what I'm planning:

   The non-terminals "command-line", "command-continuation", and
   "response" between them specify the text that flows between client
   and server.  For each command, the sequence is:
   o  the client sends an instance of "command-line";
   o  the server sends an instance of "response";
   o  while the latest response is one that indicates more is required
      (in general, a 3xx response):
      *  the client sends an instance of "command-continuation";
      *  the server sends an instance of "response".

This reminds me. The meaning of 3xx response codes has traditionally (SMTP,
POST, IHAVE) been "you now need to send me more material as part of this
command". For AUTHINFO USER, 382 is being used to mean "you need to invoke
another command now". I don't think this meets the letter of:

      3xx - Command OK so far; send the rest of it.

and I'm sure it doesn't meet the spirit. I can see two fixes:
(1) Replace the 382 response with a 2xx code.
(2) Define AUTHINFO PASS as being continuation text to AUTHINFO USER,
rather than as a separate command.

> AUTHINFO SASL is unique in this sense.  POST/IHAVE 
> only have one such exchange, where SASL may have several.

Yes, but that's something that goes in the command description. The syntax
can't show *when* you send another line, for example, and I think that's
going a step too far.

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

Well, I'm going to claim editorial privilege unless Russ overrides me.

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

Sorry, you misunderstood my second point: the current approach in RFCs
seems to be for Normative and Informative to be sub-sections of a
References section. Look at the latest [NNTP] drafts, where they're 13.1
and 13.2 respectively.

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

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.

Okay. It's something for us to keep an eye on.

Russ: I can't recall; does the base document require text pointing at the
AUTHINFO and TLSSTART documents?

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