Re: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-urgent-data-00

Joe Touch <touch@ISI.EDU> Sun, 09 November 2008 00:11 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 0868228C18E; Sat, 8 Nov 2008 16:11:27 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0CE3428C18E for <>; Sat, 8 Nov 2008 16:11:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KNBoXp40Cc43 for <>; Sat, 8 Nov 2008 16:11:25 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 3437528C18A for <>; Sat, 8 Nov 2008 16:11:25 -0800 (PST)
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id mA90AvnM001185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 8 Nov 2008 16:11:00 -0800 (PST)
Message-ID: <>
Date: Sat, 08 Nov 2008 16:10:57 -0800
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20080914)
MIME-Version: 1.0
To: Fernando Gont <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.7
X-ISI-4-43-8-MailScanner: Found to be clean
Cc:,, David Borman <>,
Subject: Re: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-urgent-data-00
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hash: SHA1

Fernando Gont wrote:
> At 02:51 p.m. 08/11/2008, Joe Touch wrote:
>> > Again: Do you really expect anybody to change their stacks so that they
>> > become RFC1122-compliant in this respect???
>> I expect that, even if the IETF had a compliance process, the specs are
>> always out of sync with what is deployed, and represent what
>> implementations should try to achieve.
> I understand what you mean, but I believe that there's a difference
> between simply being out of sync (i.e., the specs simply being ahead of
> time), and the specs specifying stuff that the implementations will
> never even try to implement.

>> >> If you want merely to document "what is", that's a fine description
>> for
>> >> a man page, but it doesn't provide utility in a standards body.
>> >
>> > Well, I guess that depends whether you want the specs to be useful for
>> > implementers, or not. I just hope that some of the kernel hackers that
>> > send comments off-list post something in this respect on-list.
>> Implementers should design protocols to specs; they should design
>> applications to specs together with man pages and errata that discuss
>> where the two diverge.
> Man pages? We are talking about what is sent on the wire. We're talking
> about the semantics of the urgent pointer. Why should, e.g. a UNIX man
> page state whether the urgent pointer points to the last byte of urgent
> data vs. the byte following the last byte of urgent data??

The UNIX man page should explain where its implementation differs from
the spec. The BSD source code does, FWIW.

>> IMO, the specs cannot constantly be downgraded to represent what is
>> implemented solely for that reason; downgrading can - and should - occur
>> if we, as a community, decide to change what we *want* the protocol to
>> do.
> Joe, why do you imply that simply updating RFC1122 such that it states
> that the UP points to "the byte following the last byte of urgent data"
> is a downgrade? Could you please elaborate a little bit on why you think
> it would be a downgrade?

I'm trying to have a general discussion about a series of I-Ds that you
have generated along these lines. In this case, we're talking about
downgrading from 1122 (and some earlier RFCs) to allow the ambiguity
from 793.

Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -

tcpm mailing list