[NNTP] LIST EXTENSIONS (again)

Ken Murchison ken at oceana.com
Fri Nov 5 07:51:29 PST 2004


Russ Allbery wrote:

I agree with all of Russ' points.  No surprise, since he has agreed with 
most of my opinions on this topic  ;)


> I see what Clive is getting at by making the extension label "NNTP 2" or
> the like instead of "NNTPv2", but I think it's better to go the route that
> lets us advertise compatibility with multiple NNTP versions rather than
> going the route that lets clients compare numbers.  Again, I'd rather
> follow IMAP here.  I don't see a need for minor protocol revisions
> indicating backward-compatible changes; I think that is subsumed by the
> ability to advertise compatibility with multiple revisions (listing both
> NNTPv2 and NNTPv3 extension labels, for instance).

Just to clarify the way that I envision that this would work (and the 
way it currently works in IMAP).  If NNTPv3 adds to NNTPv2 and retains 
NNTPv2 functionality, then only NNTPv3 would have to be advertised by 
the server (although there would be no harm in also advertising NNTPv2). 
  If NNTPv3 removes functionality from NNTPv2, but the server retains 
this functionality, then both NNTPv3 and NNTPv2 would have to be advertised.


 > At the least, we need
> to advertise whether MODE READER is required.  I think there are four
> possible states the server can be in:  all commands supported; reader
> commands not supported until after MODE READER; transit commands not
> supported at all; and reader commands not supported at all.  I think the
> best way to indicate those states would be with two extensions:
> 
>     NOREADER [MODE-READER]
>     NOTRANSIT
> 
> (those may not be the best names).  NOTRANSIT is a negative extension
> saying that IHAVE is not supported, which saves a client the need to try
> it and get 502.  NOREADER is a negative extension saying that reader
> commands (ARTICLE, BODY, POST, GROUP, LAST, NEXT, NEWGROUPS, and NEWNEWS)
> are not available.  If the optional MODE-READER parameter is given, it
> indicates that they will be available (possibly still requiring STARTTLS
> and authentication) after issuing MODE READER.  Note that this label
> doesn't need to imply anything about extensions, since that can be done
> with the presence or absence of the extension labels themselves.

Works for me.  The only question that I have is whether these 
capabilities are advertised as arguments to NNTPv2 or as standalone 
extension labels?  The only alternative names that I have for the 
capabilities would be something like "READINGDISABLED" and 
"TRANSPORTDISABLED"


> After Mark's messages, I've been convinced that we should mandate the
> order of the state change commands.  The correct order as near as I can
> tell would be:
> 
>     MODE READER
>     STARTTLS
>     AUTHINFO

If we do this, then I can add the same language to STARTTLS and AUTHINFO 
that I proposed for yesterday for OVER, etc.


> (where you can skip the initial MODE READER if your initial LIST
> EXTENSIONS doesn't have the NOREADER extension listed).  That still means
> that a connection with TLS and authentication requires seven commands to
> initiate in the worst case, though, which is rather obscene:
> 
>     LIST EXTENSIONS
>     MODE READER
>     LIST EXTENSIONS
>     STARTTLS
>     LIST EXTENSIONS
>     AUTHINFO SASL
>     LIST EXTENSIONS
> 
> Of course, nearly all servers won't require MODE READER, which cuts out
> the second and third commands.
> 
> One could cut this down by one more command by adding some sort of initial
> extension advertisement to the greeting, but this worries me for the
> reasons stated by Clive and Andrew, just in a cleanliness sense.  It's
> worth considering, though.

I understand that most folks find this proposal somewhat "distasteful" 
(for lack of a better term), but does anyone have any *technical* 
reasons why this can't work?


> One can also gain a round trip with a different idea, namely having
> successful successful AUTHINFO SASL (which is a new commands, so we can do
> whatever we want with it) include LIST EXTENSIONS output in its response.
> I'm not sure what I think of that; I'm guessing it's a bad idea since no
> one else does it.

I don't think IMAP disallows it.  Mark, does your server do this?

I don't see any technical reasons why we can't.  The only issue would be 
that if a SASL security layer is negotiated, any extensions returned in 
the response would probably be ignored by the client anyways, since the 
response is sent in the clear.  Only subsequent commands (e.g. LIST 
EXTENSION) are protected by the SASL security layer.

So, assuming capabilities are advertised in 200, 201, 281 and 283, this 
would look like:

	[MODE READER]
	STARTTLS
	LIST EXTENSIONS
	AUTHINFO
	[LIST EXTENSIONS]

MODE READER would only be used if required by the server and the second 
LIST EXTENSIONS would only be used if a SASL security layer was negotiated.


> and the LIST
> EXTENSIONS after AUTHINFO is required if authenticating changes anything
> about what you can do.  (Although I'm wondering how often authenticating
> is really going to change anything other than noting that you can no
> longer run STARTTLS or AUTHINFO again, and if clients would really need to
> check there.)

I'm probably not qualified to answer this, but might there be a case 
where "lightweight" reading is offered for free (w/o authentication), 
but more "expensive" commands such as NEWNEWS or OVER or some future 
XSEARCH are only allowed to (paying) customers that authenticate?


> Do we want to get into advertising whether commands are permitted for a
> particular client?  (POST and NEWNEWS are the ones most frequently not
> permitted.)

Doesn't the 201 response signal that POST is disabled, or I'm I 
completely clueless?  NEWNEWS can probably just spit back 503, correct?

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



More information about the ietf-nntp mailing list