Re: ietf-nntp Initial draft FINALLY available

[Stan Barber <[e-mail]>]

> At 02:59 AM 9/30/96 CDT, Stan Barber wrote:
> >I am delighted and relieved to announce that the first draft of the NNTP
> >spec is now available
> 
> Great job Stan!
> 
> Here are some comments:
> 
> >4. Basic Operation.
> >
> >
> >               Every NNTP session MUST involve the following steps,
> >               though possibly not in this order:
> >
> >               CONNECTION
> >               GREETING
> >               CAPABILITIES DISCOVERY
> >               AUTHENTICATION
> >               NEWS TRANSFER
> >               CONCLUSION
> >               DISCONNECTION
> 
> This almost sounds like all these steps are required.  They shouldn't be.

CONNECTION, GREETING, and DISCONNECTION are required, but the others are
optional. I will tighten it up on the next version.

> 
> 
> >               Initially, the server host MUST start the NNTP service by
> >               listening on TCP port 119.
> 
> Port 119 is the default, but it isn't required that the server listen there.

Is it really an NNTP service if it is not on port 119, or is it a service
that supports NNTP? I think it is really NNTP if it is on port 119, otherwise
it is a service that used the NNTP protocol.


> 
> >6. Format for Keyword Descriptions
> >
> >               Each keyword is shown in upper case for clarity, although
> >               case is ignored in the interpretation of commands by the
>                     ^MUST be
> >               NNTP server. 

This will be fixed in the next release.
> 
> 
> >9.1 AUTHINFO
> 
> The AUTHINFO SIMPLE and AUTHINFO GENERIC commands are listed, but not the
> plain (and widely used) AUTHINFO USER|PASS command.  Is this intentional?


Yes.
> 
> >10.4.1 LIST
> >               LIST [ACTIVE [wildmat]]
> 
> How widespread is the ability to specify wildmat patterns in the LIST
> command?  I think it's the right thing to do, but I'm a little leery
> of language that implies that it must be there when a lot of servers
> don't support it.  


There is no language in this section that says that this feature must
be supported. I will clarify that in the next release.


> 
> >            10.4.3 LIST DISTRIBUTIONS
> >               LIST DISTRIBUTIONS
> >
> >               The distributions file is maintained by some news
> >               transport systems to contain information about valid
> >               values for the Distribution: line in a news article
> >               header and about what the values mean.
> 
> This says "some news transport systems" support this.  So is it
> required or not?  Or is it in the SHOULD category?  LIST DISTRIB.PATS
> and LIST NEWSGROUPS have the same language.

I will clarify that in the next release.

> 
> Regarding the OVER command:
> >               The sequence of fields
> >               must be in this order: subject, author, date, message-id,
> >               references, byte count, and line count. Other optional
> >               fields may follow line count. Where no data exists, a
> >               null field must be provided (i.e. the output will have
> >               two tab characters adjacent to each other). Servers
> >               should not output fields for articles that have been
> >               removed since the overview database was created.
> 
> Hmmmm.  A couple of questions.  First, why is this command renamed from 
> XOVER?  I'd like a crack at defining an all new OVER command that doesn't
> suffer from the problems of XOVER.  Second, is the detailed listing
> of the headers and their order as written here correct?  I thought
> that this was controled by the OVERVIEW.FMT file.  But I guess I wouldn't
> argue that the XOVER response should be variable, since so many clients 
> assume exactly the response described here.


As I have see it implemented and read in the only spec I know exists (see
the references), the response to "LIST OVERVIEW.FMT" should include
this default list and  any additions, but the default list is always the
same. 

> 
> 
> >            10.4.10 PAT
> >               PAT header range|<message-id> pat [pat...]
> 
> Same question as with XOVER.  Are we really going to rename these X commands?

X commands are not part of the spec. I am renaming a few that I feel should
be in the base implementation. If others think that none of the X commands
should be renamed into the new basic spec, please express yourself. I was
trying to strike a balance to add some new functionality that was already
present in most servers as a X command.


> 
> >            11.1 QUIT
> 
> >               If a client simply disconnects (or the connection times
> >               out, or some other fault occurs), the server SHALL
> >               gracefully cease its attempts to service the client.
> 
> How about adding: If a client wants to disconnect without sending the QUIT
> command it MUST explicitly terminate the TCP/IP session on its end, it MUST
> NOT simply abandon it.

Sounds good.
> 
> >            12.4 NEWNEWS
> 
> Do we have to keep this?  It really doesn't work in a practical way in some 
> of the widely used NNTP implementations.


Any other opinions about this.
> 
> >               7. the increment by which the extension is increasing the
> >                 maximum length of the any commands over that specified
>                                     ^typo
I will fix in the next release.
> >                 in this document.
> 
> Where are XBATCH and XHDR?  Ah, I mean BATCH and HDR.  :)  I think they're 
> pretty widely used these days.
> 

XHDR is just a subset of XPAT. There is no need for both.

I was thinking that BATCH could be another reference added after the spec
using the new extension mechanism. I don't have a ready reference for it
and there has been some talk that it is not that useful from the folks doing
INN 1.5.


-- 
Stan   | Academ Consulting Services        |internet: [e-mail]
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.