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

Fernando Gont <> Mon, 03 November 2008 01:49 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 751F83A6BED; Sun, 2 Nov 2008 17:49:26 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9A7C63A6BED for <>; Sun, 2 Nov 2008 17:49:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.063
X-Spam-Status: No, score=-1.063 tagged_above=-999 required=5 tests=[AWL=-0.434, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1, SARE_RECV_SPEEDY_AR=0.808]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id U-H8iSKZTbej for <>; Sun, 2 Nov 2008 17:49:24 -0800 (PST)
Received: from (unknown []) by (Postfix) with ESMTP id 79F993A6B57 for <>; Sun, 2 Nov 2008 17:49:23 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2DF786B65A7; Sun, 2 Nov 2008 22:49:26 -0300 (ART)
Received: from ( [] (may be forged)) (authenticated bits=0) by (8.14.1/8.13.8) with ESMTP id mA31n6fe020648; Sun, 2 Nov 2008 23:49:07 -0200
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Sun, 02 Nov 2008 22:43:32 -0300
To: Joe Touch <touch@ISI.EDU>, Fernando Gont <>
From: Fernando Gont <>
In-Reply-To: <>
References: <> <> <> <> <> <>
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 ( []); Sun, 02 Nov 2008 22:49:24 -0300 (ART)
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"

Hello, Joe,

Comments in-line....

> > So we have to issues:
> >
> > * Deprecate recv(2)/MSG_OOB and encourage SO_OOBINLINE. (with which you
> > seem to agree)
>That sounds like a Unix man page update, not an RFC.

RFC 793 specifies a minimalistic/generic API for TCP. Most (if not 
all) systems have misunderstood that API. And that's what I think 
should be clarified. recv(2)/MSG_OOB is simply an example of how the 
TCP API was misunderstood.

> > * Update RFC 793/RFC1122 wrt where the UP points to, to reflect what
> > everybody does and has been doing. (with which I don't know whether you
> > agree or not).
>Either this is an implementation error or it updates our definition of PUSH.

Push? Why Push?

And, well, you may take it as an "implementation error". But 
everybody has been ding this for... how long?... twenty years? If you 
were to push TCP implementations to implement the RFC1122-mandated 
semantics of the urgent pointer, that would simply break existing 
applciations, as that change is not backwards-compatible.

After twenty years of doing so, and with every stack doing it, it's 
completely unrealistic to expect any real system to move to the 
RFC1122 semantics of the Urgent Pointer (i.e., "the UP points to the 
last byte of urgent data" instead of "the urgent pointer points to 
the byte following the last byte of urgent data).

Keeping things "as they are" simply means that anybody trying to 
analyze real traffic and interpret it according to the existing 
specs, will be puzzled.

(FWIW, the same day I posted the announcement of our I-D, a TCP 
implementor of one of the major free OSes sent me an off-list note 
mentioning that he found our draft just in time, as he was in trouble 
trying to figure out what everybody was doing wrt TCP urgent data)

>If the former, it can be noted in the next version of the TCP
>implementation errors doc. If the latter, it would update 1122 - NOT
>793. As Dave noted, 1122 supercedes 793 on this issue.

Agreed. It would update RFC1122.

>I don't like the idea of continuing to document implementations that do
>not comply with current specs without either stating
>         a) this is BAD and should be fixed
>         b) this is GOOD and we're changing our spec

We are aiming at "b", if you want. It's not really that it is "good". 
It simply is. It's the real world. Ignoring the real world simply 
helps to have the specs become irrelevant.

>FWIW, so far, this looks to me like an implementation error, not a
>reason to change the spec.

At some point, the specs (RFC 793) were ambiguous. So implementations 
simply picked one of the possible intrepretations. The IETF later 
mandated the other possible interpretation. But nobody changed their 
stacks. And nobody will. At some point it may have been an 
implementation error. Nowadays... who cares? it's the de-facto standard.

What do others think about all this?


Kind regards,

Fernando Gont
e-mail: ||
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

tcpm mailing list