Subject: [NNTP] Snapshot 5

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 30 Dec 2004 17:00:37 +0000

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.
* The standard extensions section 8 now only addresses the three
  extensions itself, not the generic material (which is now 3.6.4-5).
* The LIST command (7.6) has been rewritten as requested by many.
* Consequential changes to the formal syntax.
* Section 9 (deprecated commands) is now a placeholder; depending on the
  final MODE READER decision, it might disappear.

I have *not* done anything about re-presenting the transit/reader split,
or the three standard extensions, as packages of capabilities. I think it's
a good idea, but I thought it was best to do a snapshot first.

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?

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |

---

From: Russ Allbery <[email-masked]>
Date: Fri, 31 Dec 2004 10:16:44 -0800

Clive D W Feather <[email-masked]> writes:

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

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

>   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 ([email-masked])             <http://www.eyrie.org/~eagle/>