[NNTP] Snapshot 5

Russ Allbery rra at stanford.edu
Fri Dec 31 10:16:44 PST 2004


Clive D W Feather <clive at demon.net> writes:

> I've finally found the round tuit and done a new snapshot, available at
> the usual places:

> <http://www.davros.org/nntp-texts/draft25.pre-5.txt>
> <http://www.davros.org/nntp-texts/draft25.pre-5.html>

> The major changes are:
> * The capability and generic extension stuff has been significantly
>   rewritten and reorganised. Most of it is now in a new section 3.6.
>   The CAPABILITIES command (5.2) is therefore much simpler.

I like the structural changes.  Reading over the text, I'm still not a fan
of the modifiers.  I guess I'm not going to insist we get rid of it, but
it still strikes me as confusing and weird.  I see why you want it, but
it's just not clear to me that it's really useful given how newsreaders
tend to work.

I dislike the comment modifier even more than the rest because it means
that clients that didn't understand or care about modifiers would still
have to parse the comment modifier to get to a real capability.  Even if
we keep the rest of the concept, I'd like to get rid of that one.  If we
have to keep modifiers, I want clients who don't care about them to be
able to ignore the entire concept and any capabilities beginning with
something other than a letter or a digit and still work correctly.

I may be missing something, but I don't see anywhere other than the formal
syntax where it's said explicitly that a capability label (other than the
modifiers) must begin with a letter or digit.

> * The standard extensions section 8 now only addresses the three
>   extensions itself, not the generic material (which is now 3.6.4-5).

This looks good to me.

> * The LIST command (7.6) has been rewritten as requested by many.

This also looks good to me.  After the additional discussion on this list,
I think LIST ACTIVE should match LIST NEWSGROUPS (mandatory for reader
servers, optional for transit servers).  This should be easy to do since
we have a capability to advertise it (and this argues for listing
everything, including the mandatory ones, in the LIST capability).

> Before I go further, however, I need to bring up one point related to
> this.  Consider a server that doesn't implement IHAVE and doesn't
> implement HDR.  Under the current specification, it MUST return 502 to
> the former command but 500 to the latter, because IHAVE is a core
> command while HDR is an extension command. If we're going to simply make
> them different capabilities, then should we be rationalising this
> (preferably by using 500 in both cases)? Or do we just live with it as
> an anomaly?

Yeah, that's a good question.  I'd be happy to just use 500 in both cases,
since you're right, it's otherwise oddly inconsistent.  This would be a
change in the return code from a transit-only server to reader commands
from what we generally have now, but that's such an edge case that I don't
think it's going to cause significant problems.  But if anyone else
disagrees, please speak up.

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



More information about the ietf-nntp mailing list