[NNTP] Snapshot 4

[Ken Murchison]

Russ Allbery wrote:
> Clive D W Feather <clive at demon.net> writes:
> 
> 
>>Okay, a fourth snapshot is in the usual place:
>>    <http://www.davros.org/nntp-texts/draft25.pre-4.txt>
>>    <http://www.davros.org/nntp-texts/draft25.pre-4.html>
> 
> 
> Some more general comments on this:
> 
> I really dislike the leading underscores on _VERSION, _TRANSIT, and
> _READER.  Since we have an IANA registry for extensions, there is no
> concern about namespace conflict; unlike with C or POSIX, we have a
> central body that can administer the namespace.  I would really prefer all
> of the extension labels to look the same, the way that other protocols do.

Not to be redundantly redundant, but I (still) agree.


> I would still rather see something like NNTPv2 rather than VERSION 2, but
> I don't feel strongly enough about it to really debate it if no one else
> agrees with me.  This won't hurt anything.

I have, and will continue to agree with this (mostly since I suggested 
the NNTPv2 token).  I also think that it *might* be worth putting this 
token in the initial line of the CAPABILITIES response, e.g.:

[C] CAPABILITIES
[S] 101 NNTPv2 Capabilties follow:
[S] READER
[S] TRANSIT
[S] STARTTLS
[S] AUTHINFO SASL:DIGEST-MD5
[S] .

By doing this the client knows what the protocol version is immediately, 
before it parses the multi-line response, and therefore we don't have to 
specify a particular order for the capabilities list.


> I don't see any point in the _SERVER line.  Traditionally, this
> information is returned in the initial greeting.

But since the info in the initial greeting is free-form text, it would 
be unwise for a client to attribute any meaning to it, regardless of the 
fact that most servers put version info there.  I think most other 
protocols also discourage deriving meaning from any initial greeting 
text (except for SMTP's <domain> param and ad-hoc ESMTP token).


 > It isn't really a
> capability and clients should be actively *discouraged* from attributing
> any meaning to it or using it to guess capabilities, so I think putting it
> into CAPABILITIES is sending the wrong message.

I agree that clients MUST NOT attribute any meaning to this, but this 
info can be useful.  If the server returns this "capability" the client 
can be fairly certain that its accurate and use it for reporting 
bugs/problems against.  Although the same *might* be true about the 
initial greeting text, its also possible that the greeting text just 
says "good morning".

FWIW, POP3 has a similar capability named "IMPLEMENTATION" (which I 
prefer to "SERVER") and IMAP4 has an extension named "ID" (which the 
client can use to present implementation info to the server and the 
server can present implementation info back to the client).

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