ietf-nntp Three proposals

[coneill at oneill.net]

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, and I didn't hear anyone really speak up against it.  I'd
also suggest that perhaps some 977 commands should be listed as
extenstions.  I think it would be useful be able to indicate that my
server doesn't support NEWNEWS.

> 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.  These manditory commands
> can either grouped into some uber NNTPV2 extension response
> that all servers must return, or are simply implied by the 
> support for the extension mechanism itself.  The former
> seems simpler, but either would work.

I would tend to agree with this.

> 3. We don't rename the X commands.  While I think some people
> thought this was the consensus of the people at the BOF, I'm 
> really not sure this is true.  There were certainly a number
> of people that voiced this opinion, but we sort of wandered
> from the general discussion of whether to rename them to the
> specifics of the XHDR/XPAT command, and I never felt like the
> larger issue was really decided.  I would have hummed very loudly
> indeed in oposition to this renaming.  

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.  

I'm not very tied to renaming the or not renaming them.  I do believe that
if we are not going to rename them then we should not contradict ourselves
in the same document.  

> I did not speak up more strongly because there had been much 
> more opinion the other way in the list in the past (see the
> quotes below), and did not realize that people had drifted 
> into believing this had been decided.
> 
> I don't think we will gain anything of value by changing the 
> name to counter the high cost of changing dozens of implementations.
> The command XOVER is in essense for all time not available
> for private use.  But so what?  Use XXOVER or XXXOVER or XFLEEM.
> Out of this effort should come a list of X commands that are removed
> from the namespace for use as private commands.  That cost is
> not measurable as opposed to the concrete pain and effort trying
> to change this will cause.
> 
> In addition, our mandate from the area directors is to limit our
> effort to documenting current practise.  The current practise is
> XOVER, not OVER.

As I stated before, the only value I see in it is that the document is
more self-consisant with the commands as OVER instead of XOVER.  If we
decide that the entire X command mechanism is of of little utility then
lets chunk that and keep the X-commands.