[NNTP] Snapshot 4

Russ Allbery rra at stanford.edu
Wed Dec 1 11:36:16 PST 2004


Ken Murchison <ken at oceana.com> writes:
> Russ Allbery wrote:

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

Hm, that's an interesting thought.  There is something to be said for
this, and I wouldn't mind if that initial line looked exactly like the
current VERSION line if people really want to keep the number separate
from the word.  In other words, something like:

    101 VERSION 2
    READER
    TRANSIT
    STARTTLS
    AUTHINFO SASL:DIGEST-MD5
    .

After all, the version information *is* special and different than the
rest of the capabilities and could conceivably be required in order to
understand the rest of the list.

I'd defend this deviation from other protocols (and claim I'm still being
somewhat consistent) on the grounds that other protocols don't use the
initial response and then multiline response method in the protocol and
therefore don't have that initial line to worry about.

On the other hand, doing this (and keeping the 101 response code instead
of using the regular LIST code) makes it a lot harder to use the same code
as other LIST commands if we go back to LIST CAPABILITIES.

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

Is the SERVER response not also freeform text?  And surely we would also
prohibit deriving any meaning from it as well, from a protocol standpoint?

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

But surely this wouldn't be done on an automated basis, and a human could
look at the initial greeting as well.  Yes, a server could not advertise
its implementation in the greeting, but in that case it probably wouldn't
provide a SERVER capability either.

It just feels to me like if we put this into CAPABILITIES, no matter what
the standard might say we're just begging a client to make protocol
decisions based on what's there, since the client would do that for
everything else in the CAPABILITIES output.

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

This does make me feel better about the idea, although it makes me wonder
why IMAP went the route of a different command.  Maybe because in IMAP
capabilities can't take arguments?

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>



More information about the ietf-nntp mailing list