Re: ietf-nntp Three proposals

Ofer Inbar <cos@leftbank.com> Wed, 18 December 1996 17:33 UTC

Received: from cnri by ietf.org id aa28469; 18 Dec 96 12:33 EST
Received: from ACADEM2.ACADEM.COM by CNRI.Reston.VA.US id aa18686; 18 Dec 96 12:33 EST
Received: (from majordomo@localhost) by academ2.academ.com (8.8.3/8.7.3) id KAA09427 for ietf-nntp-outgoing; Wed, 18 Dec 1996 10:48:16 -0600 (CST)
X-Authentication-Warning: academ2.academ.com: majordomo set sender to owner-ietf-nntp using -f
Received: from academ.com (root@ACADEM.COM [198.137.249.2]) by academ2.academ.com (8.8.3/8.7.3) with ESMTP id KAA09422 for <ietf-nntp@ACADEM2.ACADEM.COM>; Wed, 18 Dec 1996 10:48:14 -0600 (CST)
Received: from grinch.leftbank.com ([139.167.128.2]) by academ.com (8.8.3/8.7.1) with SMTP id KAA29046 for <ietf-nntp@academ.com>; Wed, 18 Dec 1996 10:48:12 -0600 (CST)
Received: from zax.leftbank.com by grinch.leftbank.com via smtpd (for academ.com [198.137.249.2]) with SMTP; 18 Dec 1996 16:48:11 UT
Received: (from cos@localhost) by zax.leftbank.com (8.7.5/8.7.3/LeftBank-1.1/http://www.leftbank.com/) id LAA21964 for ietf-nntp@academ.com; Wed, 18 Dec 1996 11:48:23 -0500 (EST)
From: Ofer Inbar <cos@leftbank.com>
Message-Id: <199612181648.LAA21964@zax.leftbank.com>
Subject: Re: ietf-nntp Three proposals
To: ietf-nntp@academ.com
Date: Wed, 18 Dec 1996 11:48:23 -0500 (EST)
In-Reply-To: <19961217224144.AAA19119@bpolk> from "Ben Polk" at Dec 17, 96 02:41:44 pm
Organization: The Left Bank Operation - http://www.leftbank.com/
Reply-To: cos@leftbank.com
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-nntp@academ.com
Precedence: bulk

bpolk@netscape.com (Ben Polk) writes:
> I think this is what the "Remove the X" group is proposing:
> 
> Today:     XOVER defacto manditory
> Tomorrow:  OVER manditory, XOVER manditory but depricated
> Day after: OVER manditory, XOVER optional but depricated
> Future:    OVER manditory, XOVER prohibited

I see it a little differently:

1. Today
  XOVER not documented in the standard, but de-facto mandatory for
servers and optional for clients.

2. Next year
  XOVER documented in the standard, mandatory for servers but
deprecated for clients.  OVER introduced, mandatory for servers.
XOVER is just an alias for OVER.

3. A few years later
  XOVER alias no longer used by many clients, becomes de-facto
optional for servers (but still widely implemented).  OVER used in
most clients and servers.

4. Sometime after that
  A new version of the standard document deprecates XOVER for servers
and prohibits it for clients.

So what we're proposing now is the step from 1 to 2, and no breakage
is possible there.  The breakage would come in stepping over from 2 to
4, if we don't wait for 3 to happen first.  If 3 never happens, well
then we can't ever move to 4.  But I think 3 will happen if we wait a
few years for it.

Besides, how many newsreading clients are there out there which can't
deal with the absence of the current X commands (XHDR, XOVER)?  Those
commands aren't in the standard, so clients which have no fallback to
deal with the absence of those commands are violating the standard.

Can we come up with a good list of these clients and how they fail?

Hmm, this .sig is strangely appropriate :)

  --  Cos (Ofer Inbar)  --  cos@leftbank.com  cos@cs.brandeis.edu
  --  WBRS (100.1 FM)   --  WBRS@brandeis.edu http://www.wbrs.org/
  "If I never had existed, would you still remember me?"
  "Would you think I was a burden on the state economy?"
     -- Austin Lounge Lizards, "1984 Blues"