Re: ietf-nntp Three proposals

Chris Lewis <clewis@nortel.ca> Tue, 17 December 1996 15:55 UTC

Received: from cnri by ietf.org id aa01943; 17 Dec 96 10:55 EST
Received: from ACADEM2.ACADEM.COM by CNRI.Reston.VA.US id aa13408; 17 Dec 96 10:55 EST
Received: (from majordomo@localhost) by academ2.academ.com (8.8.3/8.7.3) id JAA04370 for ietf-nntp-outgoing; Tue, 17 Dec 1996 09:53:23 -0600 (CST)
X-Authentication-Warning: academ2.academ.com: majordomo set sender to owner-ietf-nntp using -f
Received: from academ.com (root@ACADEM.COM [198.137.249.2]) by academ2.academ.com (8.8.3/8.7.3) with ESMTP id JAA04365 for <ietf-nntp@ACADEM2.ACADEM.COM>; Tue, 17 Dec 1996 09:53:20 -0600 (CST)
Received: from bcarsde4.localhost (mailgate.nortel.ca [192.58.194.74]) by academ.com (8.8.3/8.7.1) with ESMTP id JAA15746 for <ietf-nntp@academ.com>; Tue, 17 Dec 1996 09:53:17 -0600 (CST)
Message-Id: <199612171553.JAA15746@academ.com>
Received: from bcarsfba.ott.bnr.ca by bcarsde4.localhost; Tue, 17 Dec 1996 10:34:57 -0500
Received: from bnr.ca by bcarsfba.bnr.ca id <00043-0@bcarsfba.bnr.ca>; Tue, 17 Dec 1996 10:42:19 -0500
Date: 17 Dec 1996 10:30 EST
To: coneill@oneill.net
Cc: bpolk@netscape.com, ietf-nntp@academ.com
From: Chris Lewis <clewis@nortel.ca>
Subject: Re: ietf-nntp Three proposals
Sender: owner-ietf-nntp@academ.com
Precedence: bulk

In message "Re: ietf-nntp Three proposals", 
'coneill@oneill.net' writes:

>On Thu, 12 Dec 1996, Ben Polk wrote:
>> I'm going to make three proposals:

>> 1. The new NNTP spec should not contain any optional features
>> that are not negotiated through the extension mechanism.  

>> I think we agreed to that, right?

>I agree with it,

Me too.

>> 2. Some of the new commands that are not in 977 should be
>> manditory.  Things like DATE, XOVER, XPAT make no sense to
>> have as optional at this point.

>I would tend to agree with this.

Ditto.  I would like to add at least one of the AUTHINFO commands, because
traceability is becoming extremely important these days.

>> 3. We don't rename the X commands.

>I think that if we're not going to formally rename the X-commands then we
>should remove the wording about X-commands at all. I see two interesting
>points here.  One is that I had always understood that the X-commands were
>for experimental use, however, the draft replacement for 977 indicates
>that this is actually for local use only.  I believe that this has more
>merit than for experimental use, but I'm still not totally convinced of
>the utility of the mechanism.  

>The other is that just because we rename the commands the in the new
>document does not mean that we will break all of the existing clients.  It
>would necessary document the existing form of the commands in the current
>practices document.  

That's the same as "not renaming", except that we pollute the namespace
even worse.

Frankly, I think the X-mechanism is of relatively little use.  If any X-verb
becomes standardized, then you have to change _all_ implementations - even
with phased-in cutover.

We have the choice between retaining the verbage around "X-verb", meaning
that everyone has to change when the standard comes out, or removing the
X-stuff, then only the experimental implementations that actually clash in
practise having to change.  It's not as if we'll be recasting NNTP often
enough that protecting the occasional "local" use is worth the world-wide
grief.
--
Chris Lewis, Senior Network Security Analyst, Nortel.
clewis@nortel.ca; Dept 4C16, Ottawa, Canada.  (613) 763-2935.