Re: ietf-nntp Thoughts on renaming X commands

USENET news manager <newsmaster@ucs.cam.ac.uk> Thu, 03 October 1996 21:05 UTC

Received: from cnri by ietf.org id aa23297; 3 Oct 96 17:05 EDT
Received: from PHEASANT.ACADEM.COM by CNRI.Reston.VA.US id aa22724; 3 Oct 96 17:05 EDT
Received: (from majordom@localhost) by pheasant.ACADEM.COM (8.7.5/8.7.3) id QAA28685 for ietf-nntp-outgoing; Thu, 3 Oct 1996 16:02:28 -0500
X-Authentication-Warning: pheasant.ACADEM.COM: majordom set sender to owner-ietf-nntp using -f
Received: from academ.com (root@ACADEM.COM [198.137.249.2]) by pheasant.ACADEM.COM (8.7.5/8.7.3) with ESMTP id QAA28681 for <ietf-nntp@PHEASANT.ACADEM.COM>; Thu, 3 Oct 1996 16:02:26 -0500
Received: from lyra.csx.cam.ac.uk (news@lyra.csx.cam.ac.uk [131.111.8.36]) by academ.com (8.7.6/8.7.1) with SMTP id QAA20803 for <ietf-nntp@academ.com>; Thu, 3 Oct 1996 16:02:22 -0500 (CDT)
Received: by lyra.csx.cam.ac.uk (SMI-8.6/MDTG-V1.1.8@lyra.csx.cam.ac.uk) id WAA24041; Thu, 3 Oct 1996 22:01:53 +0100
Message-Id: <199610032101.WAA24041@lyra.csx.cam.ac.uk>
Subject: Re: ietf-nntp Thoughts on renaming X commands
To: Ben Polk <bpolk@netscape.com>
Date: Thu, 3 Oct 1996 22:01:53 +0100 (BST)
Cc: ietf-nntp@academ.com
In-Reply-To: <19961003191126.AAA12839@bpolk.mcom.com> from "Ben Polk" at Oct 3, 96 12:11:26 pm
From: USENET news manager <newsmaster@ucs.cam.ac.uk>
X-Mailer: ELM [version 2.4 PL22]
Content-Type: text
Sender: owner-ietf-nntp@academ.com
Precedence: bulk

>What do other people think about renaming XOVER->OVER in
>the spec?  
>
>I'd prefer to document it as XOVER.  There are millions of
>installed programs that use this, and no technical reason I 
>can see to change it.
>
>Same for XPAT.

As others have noted, the X-commands should be available for anyone to use 
experimentally, and should not be pre-empted by standardised commands. 
However, the reality is that they are de facto extremely widely used -
they "should" have been switched to non-X names long ago, before becoming
de facto standards, but it's too late to change that now.

There is a precedent for dealing with this - though it's seven years old, so 
maybe prevailing views would favour some other solution. I'm thinking of FTP,
where the same issue arose and had to be fixed up in the Host Requirements
RFC (1123):

"        4.1.3.1  Non-standard Command Verbs

            FTP allows "experimental" commands, whose names begin with
            "X".  If these commands are subsequently adopted as
            standards, there may still be existing implementations using
            the "X" form.  At present, this is true for the directory
            commands:

                RFC-959   "Experimental"

                  MKD        XMKD
                  RMD        XRMD
                  PWD        XPWD
                  CDUP       XCUP
                  CWD        XCWD

            All FTP implementations SHOULD recognize both forms of these
            commands, by simply equating them with extra entries in the
            command lookup table.

            IMPLEMENTATION:
                 A User-FTP can access a server that supports only the
                 "X" forms by implementing a mode switch, or
                 automatically using the following procedure: if the
                 RFC-959 form of one of the above commands is rejected
                 with a 500 or 502 response code, then try the
                 experimental form; any other response would be passed
                 to the user."

I.e. regardless of the "X means experimental" convention, widespread usage
was deemed to mean that the X versions have to be supported indefinitely 
while favouring non-X names.

Whatever we decide, I think XOVER and XPAT are so widely used that we must
document them in some form, even if only to note that they are historical
equivalents of OVER and PAT, and therefore SHOULD not be used to mean
something different. Going farther and requiring both servers and clients
to allow for X- and non-X variants of the names should allow a much smoother
(multi-year!) transition, though no doubt contentious. 

[The other comments I've seen to date seem to have considered the server
allowing XOVER and XPAT as synonyms, but not considered the case of a new
client with an old server, which the FTP example tackles by requiring
conforming clients to try the old name if the new one is not recognised.]

                                John Line
-- 
Cambridge University Computing Service - USENET news manager. Usually John Line
newsmaster@ucs.cam.ac.uk    (alias {newsmaster,news,usenet}@news.cam.ac.uk)