[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