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

Fernando Gont <> Wed, 12 November 2008 23:11 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id AD0C93A6988; Wed, 12 Nov 2008 15:11:55 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6551B3A6988 for <>; Wed, 12 Nov 2008 15:11:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.013
X-Spam-Status: No, score=-1.013 tagged_above=-999 required=5 tests=[AWL=0.424, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Fg1wJFJGWNbo for <>; Wed, 12 Nov 2008 15:11:53 -0800 (PST)
Received: from (unknown []) by (Postfix) with ESMTP id 377BE3A63D2 for <>; Wed, 12 Nov 2008 15:11:52 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id AC9B06B673B; Wed, 12 Nov 2008 20:11:56 -0300 (ART)
Received: from ( []) (authenticated bits=0) by (8.14.1/8.13.8) with ESMTP id mACNBaPj028065; Wed, 12 Nov 2008 21:11:40 -0200
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Wed, 12 Nov 2008 19:06:15 -0300
To: Joe Touch <touch@ISI.EDU>,
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 ( []); Wed, 12 Nov 2008 20:11:56 -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"

At 01:38 p.m. 12/11/2008, Joe Touch wrote:

> > After reading the set of what I could find - the only conclusion
> > regarding TCP Urgent that I could come to if I was designing an
> > application - "Don't use it. At all."
>I'm wondering what the current uses are;

As far as I have been able to check (not that much), "urgent data" is 
used in what you'd call legacy applications (telnet, login, ftp) and 
some databases (I had been told MS SQL used it).

>if they misuse urgent, then
>fixing the specs won't help.

FWIW, one could argue that they do misuses urgent.

Basically, there are two things every app does wrt "urgent data"

1) They interpret the semantics of the UP incorrectly. (they 
interpret the UP as pointing to the byte following the last byte of 
urgent data, rather than pointing to the last byte of urgent data).
2) They read urgent data OOB.

#1 can be easily "accommodated" by updating RFC1122. It's not that I 
"really love the idea", but I'm being pragmatic: it doesn't hurt, 
doesn't break anything, and keeps the specs relevant.

While one could argue that #2 is simply broken, after all the 
end-result is the same: you discard everything up to the urgent mark. 
Also, as there are not that many applications using urgent data, it 
would not be crazy to expect/pretend that they get fixed (by having 
hem set SO_OOBINLINE).

>Maybe we should instead deprecate the function altogether?

Honestly speaking, this is what Andrew and me really and in mind, but 
we thought the proposal would sound controversial to many. :-) So we 
decided to trigger discussion on these issues, and propose (in the 
very first version of the draft) just to "fix" (for some meaning of 
"fix) urgent data, rather than deprecating it.

I'll be putting on-line a rev of the urgent data soon, that better 
reflects the options we have on the table, the feedback we have got 
so far, etc., and probably even some survey of the apps that use 
urgent data. I guess that might help to decide which specific path to pursue.

How does this sound?

> > 2) Would we want to more effectively utilise these 16 bits in the TCP
> > header (assuming the URG flag rests at "0"), rather than transmitting
> > two zero bytes for 99.99% of the cases ?
>If we can't get the community to implement Urgent as per spec, we
>probably can't reassign those bits either.

I guess we could find some backwards-compatible approach to reassign 
the URG bits and the UP.....


Kind regards,

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

tcpm mailing list