[NNTP] Snapshot 5

[Clive D.W. Feather]

Ken Murchison said:
> 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.)

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.

> Issue 2511:
> 
> Not sure what we're talking about here.

We're talking about your own question:

> Should OVERVIEW.FMT and HEADERS really be listed as LIST arguments? 

> Section 3.6.3:
> 
> 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.

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

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 
> these references, please fix the spelling of my last name in the 
> NNTP-AUTH and NNTP-STREAM entries.

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

> Issue 2513:
> 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?

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

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.

>> * The LIST command (7.6) has been rewritten as requested by many.
> 
> 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.

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

> Section 7.5:
> 
> The placement of this seems a little odd (after the commands which use 
> 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 
> the text in the appropriate places: paragraph 2 => 7.1, paragraph 3 => 
> 7.3 and/or 7.4.

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.

> I also was thinking that maybe 8.2 is a little out of place and could 
> 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.

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