ietf-nntp Initial draft FINALLY available
Stan Barber
sob at academ.com
Tue Oct 1 21:37:37 PDT 1996
> 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: 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.
More information about the ietf-nntp
mailing list