[NNTP] Capabilities in responses (Was: MODE READER)

[Ken Murchison]

Clive D.W. Feather wrote:

> Mark Crispin said:
> 
>>>The problem is the other way round: a conforming RFC 977 server can already
>>>produce such responses with meaningless contents.
>>
>>It is not, however, particularly likely that an RFC 977 is going to 
>>produce such a response which contains the "NNTPv2" capability.
> 
> 
> It doesn't matter; you can't rely on it. That's building on sand, not
> drawing a line in it :-)

How/why wouldn't it be reliable?  If we use a construct that is fairly 
unique (e.g. "[ ... ]") and pick an extension label for our undated spec 
(e.g. "NNTPv2" or "_NNTP_2") that is unlikely to be used in comment 
text, the likely hood of them being used together in a specific format 
in a response (e.g. "[NNTPv2 STARTTLS ...]" is *very* unlikely. 
Therefore any client which is aware of NNTPv2 and wishes to use this 
facility can easily spot the capability list in the response.  I'd also 
like to point out, that only four of our current responses (200, 201, 
281, 283) would be realistic candidates for this facility (although I 
could be missing one).

If a client is not aware of NNTPv2 or this capability announcement 
facility, it will simply ignore it as comment text.


> There's also the problem that response lines are limited in length and
> there may not be room for the message as well as the existing response.

This isn't a big deal.  Either the server pares down the list as Mark 
suggests, or it simply doesn't include it at all (forcing the client to 
do an explicit LIST EXTENSIONS).  We're doing a similar thing with the 
SASL initial response.  If the initial response would cause the command 
line to be too long, the client must omit it and force the server to 
request it with an empty challenge.


> 
> ====
> 
> I've done some thinking about this and come to some conclusions.
> 
> What you're talking about is a specific use of what I would call
> "asynchronous messages" - messages not in immediate response to a command.
> IIRC, IMAP has these as a general possibility, as does (in a different
> area) the X11 protocol.

Mark has already addressed this as *not* what we're doing.  All we're 
really doing here is anticipating the fact the the client will be doing 
a LIST EXTENSIONS after the current command and merging the responses 
into a single one.

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