Re: ietf-nntp Initial draft FINALLY available

Evan Champion <evanc@synapse.net> Thu, 03 October 1996 19:29 UTC

Received: from cnri by ietf.org id aa20255; 3 Oct 96 15:29 EDT
Received: from PHEASANT.ACADEM.COM by CNRI.Reston.VA.US id aa19806; 3 Oct 96 15:29 EDT
Received: (from majordom@localhost) by pheasant.ACADEM.COM (8.7.5/8.7.3) id OAA27988 for ietf-nntp-outgoing; Thu, 3 Oct 1996 14:22:58 -0500
X-Authentication-Warning: pheasant.ACADEM.COM: majordom set sender to owner-ietf-nntp using -f
Received: from academ.com (root@ACADEM.COM [198.137.249.2]) by pheasant.ACADEM.COM (8.7.5/8.7.3) with ESMTP id OAA27984 for <ietf-nntp@PHEASANT.ACADEM.COM>; Thu, 3 Oct 1996 14:22:56 -0500
Received: from clarinet.synapse.net (clarinet.synapse.net [199.84.54.19]) by academ.com (8.7.6/8.7.1) with ESMTP id OAA18674 for <ietf-nntp@academ.com>; Thu, 3 Oct 1996 14:22:52 -0500 (CDT)
Received: from cello (cello.synapse.net [199.84.54.34]) by clarinet.synapse.net (8.8.0/8.8.0) with SMTP id PAA20626; Thu, 3 Oct 1996 15:22:45 -0400 (EDT)
Message-ID: <32541235.5C2E@synapse.net>
Date: Thu, 03 Oct 1996 15:21:25 -0400
From: Evan Champion <evanc@synapse.net>
X-Mailer: Mozilla 3.0 (WinNT; I)
MIME-Version: 1.0
To: USENET news manager <newsmaster@ucs.cam.ac.uk>
CC: ietf-nntp@academ.com
Subject: Re: ietf-nntp Initial draft FINALLY available
References: <199610030921.KAA26292@lyra.csx.cam.ac.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-nntp@academ.com
Precedence: bulk

USENET news manager wrote:
> Since port 119/TCP is the standard port, any news software which could not
> run on that port would de facto be useless for most purposes, yet without
> specifying it as SHOULD, an implementation could choose to use a non-standard
> port (for some bizarre reason or other), possibly (especially if no source
> code supplied) with no way for you to change it, and claim they conformed to
> the standard.

And when users went to use it, they would never figure out why it didn't
work, and the company would be bombarded with comments like "what a
piece of garbage"...  I think they would change it rather quickly.

But then, perhaps their product was designed for a very specific purpose
(ie: Kerberised NNTP), and maybe even though it talks standard NNTP it
shouldn't be used with browsers that can't authenticate via Kerberos and
thus it was put on another port to discourage people from trying.  That
doesn't mean that it isn't following the NNTP standard, and they could
very legitimately state that their package is NNTP compliant, because it
talks standard NNTP, with just something added to the login mechanism to
authenticate via Kerberos.  [This exact thing has happened with
Netscape's Secure News Server, which runs SSL connections on port 519,
and yet it is perfectly NNTP compliant.]

There is a fundamental principle here in that a protocol draft has no
business defining transport issues.  It should not be mandating a
particular port any more than it should be mandating that the hosts are
connected via IP over a 10baseT network whose cable length is between 2
and 100 metres.

It can, and in fact should, however, tell the reader what the IANA
assigned port is and that NNTP software SHOULD use this port.

SHOULD is AFAIK the strongest suggestive word in an RFC.  It is
equivalent to "look, if you don't do it without a good reason, someone
is going to whack you over the head."  When presented with choosing the
standard port or being whacked over the head, I trust that the designers
will make the correct choice.

Evan
--
Evan Champion            * Director, Network Operations
mailto:evanc@synapse.net * Directeur, Exploitation du reseau
http://www.synapse.net/  * Synapse Internet