Subject: Re: [NNTP] Snapshot 5

From: "Clive D.W. Feather" <[email-masked]>
Date: Mon, 3 Jan 2005 10:50:37 +0000

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:  <[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: Ken Murchison <[email-masked]>
Date: Mon, 03 Jan 2005 11:32:58 -0500

Clive D.W. Feather wrote:
> 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.

Section 3.6.2:

Perhaps we should borrow the following from RFC 2449 for the description 
of IMPLEMENTATION:

"(Note that since capability line arguments are separated by whitespace, 
it may be convenient for the IMPLEMENTATION capability argument to not 
contain whitespace, so that it is a single token.)

Issue 2511:

Not sure what we're talking about here.

Section 3.6.3:

I'm also not a fan of the modifiers, especially the comment modifier.

Section 3.6.5:

Do we really want to list AUTHINFO, SASL, STARTTLS and STREAMING in the 
base doc?  I thought that we had agreed to not reference other NNTP 
extension docs if at all possible.  These docs are fully capable (and 
do) add the respective capabilities to the IANA registry.  If we do keep 
these references, please fix the spelling of my last name in the 
NNTP-AUTH and NNTP-STREAM entries.

 >   The CAPABILITIES command (5.2) is therefore much simpler.

Issue 2513:

Perhaps paragraph 4 could be moved, but I don't think its a big deal.

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

I don't see the need for the first paragraph of section 8, especially if 
we don't reference AUTHINFO, STARTTLS and STREAMING.

> * Consequential changes to the formal syntax.

Sections 7.6.2, 8.3.2 and 8.4.2:

Should OVERVIEW.FMT and HEADERS really be listed as LIST arguments? 
Both of these LIST variants are governed by their own capabilities (OVER 
and HDR respectively).  Its seems kind of crufty that a single command 
like LIST HEADERS would have both a separate capability (HDR) and an 
argument to a second capability (LIST) to advertise it.

Section 7.5:

The placement of this seems a little odd (after the commands which use 
it).  Would it be better to move this into section 3?  Perhaps as a new 
3.6 (bumping the current 3.6 to 3.7)?  Or maybe just break it up and put 
the text in the appropriate places: paragraph 2 => 7.1, paragraph 3 => 
7.3 and/or 7.4.

I also was thinking that maybe 8.2 is a little out of place and could 
possibly be a section 3.5.1.

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

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Tue, 4 Jan 2005 12:29:47 +0000

> contain whitespace, so that it is a single token.)

I don't follow the logic of 2449 there; since the entire rest of the line
is the server identification, why arbitrarily limit it to one token?
I'm against doing this.

> I'm also not a fan of the modifiers, especially the comment modifier.

You don't see the benefit in the example?

  [C] CAPABILITIES
  [S] 101 Capability list:
  [S] VERSION 2
  [S] READER
  [S] LIST ACTIVE NEWSGROUPS
  [S] (test-version-2.1) STREAMING
  [S] .

Okay, out it comes.

> extension docs if at all possible.

If you recall, one of the objections at IETF level was the lack of the
authentication and privacy facilities. Though we now mention them in the
text and via Informative References, I thought it better to explicitly
list them in the initial IANA registry as well. We expect all four
documents to be published at the same time, after all.

I accept the argument is weaker for STREAMING.

Russ, views?

> IANA registry.  If we do keep 

Ouch! How the hell did *that* happen. My apologies.

> Perhaps paragraph 4 could be moved, but I don't think its a big deal.

"The server MUST ensure that the capability list accurately reflects ...",
right? That was the one I was particularly thinking of as well. Other
opinions?

> we don't reference AUTHINFO, STARTTLS and STREAMING.

It's likely to disappear in the next rewrite anyway, as these become
optional commands in the base specification. The point was that I use
"standard extension" and "registered extension" in a number of places
(e.g. a standard extension can't use an x9x response or an X command).
I didn't want the use of this section title to cause confusion.

> argument to a second capability (LIST) to advertise it.

Opinion on this matter seems to be split. It's also why I wanted to rename
LIST HEADERS as something else.

> it).

It was deliberate - it was sort of supplemental information related to
these commands.

> Would it be better to move this into section 3?  Perhaps as a new 
> 3.6 (bumping the current 3.6 to 3.7)?

No, I think it's better here (it's more a "usage note" than a fundamental
concept).

> Or maybe just break it up and put 

That might work. However, paragraph 3 - and the examples - would either
need duplication or would require a pointer. I don't think there are
enough benefits. Moving the second paragraph into DATE is a better idea
and I think I'll do it.

> possibly be a section 3.5.1.

Perhaps, though I'm concerned that section 3 is getting awfully long. I'll
look when I do the rewrite.

---

From: Ken Murchison <[email-masked]>
Date: Tue, 04 Jan 2005 10:01:59 -0500

> is the server identification, why arbitrarily limit it to one token?

I'm assuming that the fear was that a client would parse the arguments 
into individual tokens rather than just treating everything following 
"IMPLEMENTATION" as a single string.  As long as the client doesn't 
rearrange the tokens or try to infer any meaning based on the order, I 
suppose its not a big deal.

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 4 Jan 2005 11:50:29 GMT

>I'm also not a fan of the modifiers, especially the comment modifier.

Granted they are ugly, they do serve a useful purpose. Would they be less
conspicuous if they appeared at the end of the line of output rather than
at the beginning. People who did not care for them could then ignore them,
and there would be less parsing hassle.

>argument to a second capability (LIST) to advertise it.

No, I think it is OK as it stands. If you want to know whether the
extension is implemented, you look for a HDR capability. If you want to
know what LIST commands are available (as provided by a whole bunch of
options and extensions), you look at the LIST capability.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

---

From: Russ Allbery <[email-masked]>
Date: Tue, 04 Jan 2005 09:57:47 -0800

> Russ, views?

If we're going to publish them all at the same time anyway, I think it
makes sense to go ahead and cross-reference them since the readers are
going to need to know about all of them.  But I'll double-check with our
AD on that.

>> Both of these LIST variants are governed by their own capabilities
>> (OVER and HDR respectively).  Its seems kind of crufty that a single
>> command like LIST HEADERS would have both a separate capability (HDR)
>> and an argument to a second capability (LIST) to advertise it.

> Opinion on this matter seems to be split. It's also why I wanted to
> rename LIST HEADERS as something else.

I'm inclined to leave it alone; it's a little odd, but it doesn't seem to
hurt anything.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Wed, 5 Jan 2005 11:24:31 +0000

> and there would be less parsing hassle.

Actually there would be more hassle, because now we'd be restricting the
form of capability line arguments. At present the parsing is:

    * Split line into tokens on white space.
  #if understand-modifiers
    * While (first token begins with non-alphanumeric)
      - First token is a modifier;
      - if known, process it and remove from list of tokens
        else ignore entire line
  #else
    * If (first token begins with non-alphanumeric)
      - ignore entire line
  #endif
    * If (first token begins with digit)
      - error
    * First token is capability label. Process it and remove from the list.
    * While (tokens remain)
      - process token as argument to label.

As for "less conspicuous", this is a machine protocol we're talking about.
You shouldn't be trying to hide things!

---

From: Russ Allbery <[email-masked]>
Date: Wed, 05 Jan 2005 12:13:28 -0800

>       - process token as argument to label.

Exactly... this was why I didn't like comments -- it inserted an
additional step of peeling the comment off the front that had to be done
even for clients that didn't understand or care about modifiers.

---

From: Russ Allbery <[email-masked]>
Date: Thu, 06 Jan 2005 15:36:04 -0800

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

Right.  That is the case today in practice.  At some point, we're going to
need to develop some sort of feed information extension to communicate all
of the details that one really wants to communicate to peers, but that's a
separate discussion to take up after we finish with what we're working on
now.

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

Yes.

---

From: Russ Allbery <[email-masked]>
Date: Thu, 06 Jan 2005 15:38:48 -0800

> Okay, out it comes.

What bothers me about this example is that the first time I read it, I
thought "oh, that means that the server is sort of supporting the
STREAMING extension but hiding it from any client so that a client won't
try it yet, since it's experimental."  It was only after reading the text
that I realized that it was supposed to be treated as equivalent to
advertising STREAMING, which I found really counter-intuitive.

I just don't think there's enough use in this to have it be worth it.

> rename LIST HEADERS as something else.

I'm not sure what to do about this.  We can't rename LIST OVERVIEW.FMT, so
the problem is going to exist no matter what we do.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 7 Jan 2005 13:49:06 +0000

> advertising STREAMING, which I found really counter-intuitive.

Oh, I see what you're getting at.

> I just don't think there's enough use in this to have it be worth it.

Okay. It's gone.

> the problem is going to exist no matter what we do.

Indeed.