[NNTP] Snapshot 5

Ken Murchison ken at oceana.com
Mon Jan 3 08:32:58 PST 2005


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.


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



More information about the ietf-nntp mailing list