ietf-nntp New draft available

Paul Overell paulo at turnpike.com
Tue Sep 2 01:56:58 PDT 1997


In article <199709011754.MAA28665 at academ.com>, Stan Barber
<sob at academ.com> writes
>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 extended syntax of NEWNEWS and NEWGROUPS are incompatible in so far
that a client issuing 4 digit years will not work with a server that
conforms to RFC977.  I am not saying that this is a bad thing, just that
it needs specifying.  New RFC977bis clients will need to be aware of
this if they are to interwork with old RFC977 servers. 

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

Nor am I arguing for the retention of the SLAVE command.  But it is
incompatible in that an RFC977 conforming client can expect the SLAVE
command.  Again it needs specifying.


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

This doesn't seem very satisfactory.  All the above commands are
extensions to RFC977, why are some in the IANA registry and not others?

Sorry to labour the point, but are you saying that those commands not in
the registry are mandatory and those in the registry are optional? 

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

I will see what I can do.

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

No problem but it needs saying in the spec.

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

At the very least change the title of 10.2.1 to

10.2.1  ARTICLE, HEAD, BODY and STAT commands.

But I would rather that it were split into individual sections, one for
each command.  Each section giving just the semantics and responses for
that particular command, then referencing a section on the common
semantics of the effect on the current article pointer etc.


-- 
Paul Overell                                        T U R N P I K E  Ltd



More information about the ietf-nntp mailing list