ietf-nntp Three proposals

[Ben Polk]

Here are some thoughts coming out of todays NNTP BOF.  Overall
it seemed to go well, and it was great to get a chance to meet
some of the people that I've seen in this list over the last
few months.

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?

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 think this might be a bit controversial.  And certainly
there will need to be some interesting discussions on which
commands are manditory.

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 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.

I know this is controversial, and I'll leave off with the following
quotes from this list over the past months on this issue:

John Myers in http://www.academ.com/academ/nntp/ietf/msg00151.html:
The XOVER command is in widespread use.  Changing the name of the
command will cause disruption with no technical benefit.  The command
should be standardized with its current name.

Rich Salz in: http://www.academ.com/academ/nntp/ietf/msg00140.html
I think it is a bad idea to follow some false sense of purity and
render all millions of client/server pairs nonconforming.
I had this discussion with Stan once before.  I stll agree with Ben.

John Line, objecting to removal of XHDR:
http://www.academ.com/academ/nntp/ietf/msg00160.html

Brain Kantor wrote in
http://www.academ.com/academ/nntp/ietf/msg00110.html:
I think it is a mistake to omit any common practice from the document.
It could be deprecated there, but it should be documented if it is in
use.
Otherwise the document is incomplete, untrue, and will have to be
supplemented
by another RFC describing what is really going on.

Keith Moore in: http://www.academ.com/academ/nntp/ietf/msg00166.html
Yes, this is what we discussed at the Montreal BOF:
1. Document existing practice
2. Define an extension negotiation mechanism
3. After (and only after) the above two are done, the group can 
   review suggested extensions that people want to submit.