ietf-nntp New draft available

[Stan Barber]

You write:
> I think you need to list any particular incompatibilities with RFC977, in particular
> 4 digit years in the NEWGROUPS and NEWNEWS command; and the removal of the SLAVE
> command.  

The NEWGROUPS and NEWNEWS commands are not incompatible with RFC977. They
extend the syntax, but the old syntax works just fine.

The SLAVE command did nothing in RFC 977, so I removed it. Please tell me how 
you use the SLAVE command. If lots of people use, we can put it back in. If
no one uses it, what's the point of having it in there?

> This whole section concerning MUST and SHOULD etc could be replaced with a reference
> to RFC2119.

Good idea.

> 
> [snip]
> 
> >          10.2.1    ARTICLE
> 
> [snip]
> 
> >          10.2.1.1  Responses
> >
> >                 220 n <a> article retrieved - head and body follow (n =
> >                    article number, <a> = message-id)
> >                 221 n <a> article retrieved - head follows
> >                 222 n <a> article retrieved - body follows
> >                 223 n <a> article retrieved - request text separately
> >                 412 no news group has been selected
> >                 420 no current article has been selected
> >                 423 no such article number in this group
> >                 430 no such article found
> 
> When an ARTICLE is requested by message-id what is the article number, n, given in
> the response? for which newsgroup? perhaps that from the last GROUP command but what
> if no GROUP command has been given?  Implementations I have used give 0 as the
> article number in this case.  This needs to be specified.

Okey.

> 
> [snip]
> >          12.2 DATE
> >
> [snip]
> 
> >            This command returns a one-line response code of 111 followed
> >            by the GMT date and time on the server in the form
>                     ^^^
>                     UTC
I will handle this differently in the next release of the document.
> 
> >          12.4 NEWGROUPS
> 
> [snip]
> >            with HH being hours on the 24-hour clock, MM minutes 00-59,
> >            and SS seconds 00-59.  The time is assumed to be in the
> >            server's timezone unless the token "GMT" appears in which case
> >            both time and date are evaluated at the 0 meridian.
> 
> Reword this as
> 
>         With HH being hours in the 24-hour clock 00-23, MM minutes 00-59, and SS
>         seconds 00-60, which allows for leap seconds.  The token "GMT" specifies
>         that the date and time are given in UTC.  If the token "GMT" is omitted then
>         the date and time are specified in the server's local timezone.  Note that
>         there is no way within this specification of NNTP to establish the server's
>         local timezone.

I will consider your suggestion in the next release of this document.

> 
> [snip]
> 
> >          13.1 Initial IANA Registry
> 
> >            The IANA's initial registry of NNTP service extensions
> >            consists of these entries:
> 
> [snip]
> >          Identification and    AUTHINFO              Defined in this
> >          Authentication        AUTHINFO SIMPLE       document
> 
> AUTHINFO SIMPLE is *not* defined in this document.

True. This is an error and should be replaced with AUTHINFO GENERIC.

> General Comments.
> ----------------
> 
> 1.      Needs a contents page, difficult to find commands otherwise.

This is planned for a future release of the document. When I add the examples,
I will add the table of contents.

> 
> 2.      Page 30 is missing, or rather page numbering has gone wrong.

Probably the latter. It was paginated automatically by a word processor.

> 
> 3.      I am not clear on the status of the non-RFC977 commands.  Are they optional
>         extensions or a mandatory part of the standard?  Does the LIST EXTENSION
>         list the extensions to RFC977 or to this draft, RFC977bis?  I.e. would any
>         of these be returned by LIST EXTENSIONS? 
> 
>         MODE READER
>         AUTHINFO USER
>         AUTHINFO PASS
>         AUTHINFO GENERIC
>         LIST EXTENSIONS
>         LIST ACTIVE
>         LIST ACTIVE.TIMES
>         LIST DISTRIBUTIONS
>         LIST DISTRIB.PATS
>         LIST NEWSGROUPS
>         LIST OVERVIEW.FMT
>         LIST SUBSCRIPTIONS
>         LISTGROUP
>         OVER
>         PAT
>         CHARSET
>         DATE

All commands listed in this document other than those in the IANA registry 
table are considered part of the base and would not be returned by
LIST EXTENSIONS.

> 
> 4.      Part of the vagueness in RFC977 was its lack of a precise, complete, formal
>         syntax of both command and replies.  Please can we have one? preferably
>         using ABNF (draft-ietf-drums-abnf-03.txt, vested interest declared).


Please write up one and send it along.

> 
> 5.      The SLAVE command has been removed.  This in an incompatible change so
>         should either be noted as such or recommend that servers implement it as a
>         NOP and always return 202.


Yes, it was removed because it did nothing. 

> 
> 6.      I agree with Jonathan Grobe that the STAT, BODY, and HEADER command deserve
>         a section each, otherwise they get lost within the text about ARTICLE.
> 


Okey. Both you and Jonathan find this confusing or believe it confuses others.
Please suggest new text that addresses this concern.
-- 
Stan   | Academ Consulting Services        |internet: sob at academ.com
Olan   | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob
Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.