ietf-nntp Three proposals

[Ian King]

I also recall the following from the conversation (as it was something I
said): 

If X-verb is to mean experimental, then let's have 977bis include the
"blessed" interpretation of those X-verbs that have infiltrated
themselves into the standard.  For instance, for XOVER, we state in the
standard that there is a verb OVER which is defined as [the best and/or
most commonly used version of XOVER], which serves as guidance to the
author of new implementations.  In terms of changing existing software,
it will continue to be used and to support XOVER as is, until there is a
sufficient customer base to require a change -- by which time, most
software is updated anyway, to fix other problems.  :-)

Yes, this raises issues, but it's a lot less confusing than saying that
one X-verb is standard and another is experimental.  

Ian King, QA Lead <iking at microsoft.com>
Normandy Information Retrieval		WARNING: Dates on calendar are
Internet Services Business Unit		       closer than they appear.


>-----Original Message-----
>From:	Chris Lewis [SMTP:clewis at nortel.ca]
>Sent:	Tuesday, December 17, 1996 7:30 AM
>To:	coneill at oneill.net
>Cc:	bpolk at netscape.com; ietf-nntp at academ.com
>Subject:	Re: ietf-nntp Three proposals
>
>In message "Re: ietf-nntp Three proposals", 
>'coneill at 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 at nortel.ca; Dept 4C16, Ottawa, Canada.  (613) 763-2935.
>