ietf-nntp Three proposals

[Ofer Inbar]

There are good arguments on both sides of the "X-" issue, and a strong
case can be made for either side.  However, the time to make that case,
IMO, is the time a protocol is first designed.  If a protocol has been
around for years with the X convention in the documentation, then we
should drop the argument and stick to it.

If we "rename" XOVER to OVER, nothing will break.  Because the RFC
will definitely document the fact that XOVER is currently used, and
following the example of FTP, will state that servers should accept
the XOVER command as a synonym for the new OVER command.  Similarly,
XPAT and XHDR can be accepted as synonyms for the new HDR command
(which would only break if a client really depends on giving invalid
syntax and getting an error :).

The current situation is that implementations are supporting, and
depending, on commands that aren't even documented in any RFC.  And
yet it all seems to work anyway.  Surely we won't break all of this
cooperation if we release an RFC that actually documents them, even if
it does push for a gradual renaming.

I hope to see the "standard" X commands die off within 5 years.

If this were a brand new protocol, I might lean toward the
anti-X-convention arguments.  But it's not a brand new protocol.

  --  Cos (Ofer Inbar)         -- cos at leftbank.com cos at cs.brandeis.edu
  --  The Left Bank Operation  -- lbo at leftbank.com http://www.leftbank.com/
  "Good literature is about Love and War."
  "Junk fiction is about Sex and Violence."