[NNTP] Snapshot 5

[Clive D.W. Feather]

Russ Allbery said:
> 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.

Apart from the comment modifiers bit, the present wording means:
* servers can completely ignore it, but the feature is there if it ever
  becomes useful - servers can be sure that clients won't barf;
* clients just have to do one small thing, but can make use of the
  information if it becomes useful.

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

Only by skipping the first word if it begins with open parenthesis.

At the point I was working on that text, it seemed a good idea to have, but
I'm not wedded to it. If nobody else likes it, I'll take it out.

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

A capability label is a keyword, which is a term defined in 3.1. However,
now you've pointed this out, I realize it's a bit hidden and will move it
to 2 (which is a better place for it).

Incidentally, it's required to begin with a letter.

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

Okay. Note that this means that a client of a transit server will have no
way to check what groups the server supports.

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

and vice-versa

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

We'll need a warning that clients should be prepared to receive 502 in this
circumstance.

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