ietf-nntp "Common NNTP Extensions" document updated
jon at oaktree.co.uk
Mon Dec 1 08:28:03 PST 1997
Vincent Archer <Vincent.Archer at hsc.fr> wrote:
> I'm not advocating the removal of the command, just the part that mandate
> the existence of this command in the protocol.
These two are the same thing. If the command is not a MUST part of the
protocol, then client software cannot rely on its existence. This isn't
just some optimisation, where the client can "fall back" to some other
method if NEWNEWS isn't available. Clients are written right from the
start on the NEWNEWS model or the article-numbers model.
> What I'm saying (and no more) is that, if the spec require a server to
> implement NEWNEWS to conform, then we'll have lots of non-compliant
> servers, and people will still refuse to have NEWNEWS enabled on their
> I ask again: Do we want the RFC to reflect actual use, or an ideal net?
And I say again: NEWNEWS exists and is in widespread use today. Fixing
INN so that it implements NEWNEWS properly isn't difficult, and is
a far better solution than deciding to break existing, working client
I really can't see how anyone can seriously propose that parts of such
a protocol can be removed with no warning. How on earth are people supposed
to write RFC-compliant software if tomorrow someone might suddenly change
the RFC so that their software is no longer compliant?
\ // Jon Ribbens // 100MB virtual-hosted // www.oaktree.co.uk
\// jon at oaktree.co.uk // web space for 99UKP //
More information about the ietf-nntp