Re: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-urgent-data-00
Fernando Gont <fernando@gont.com.ar> Wed, 12 November 2008 23:11 UTC
Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD0C93A6988; Wed, 12 Nov 2008 15:11:55 -0800 (PST)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6551B3A6988 for <tcpm@core3.amsl.com>; Wed, 12 Nov 2008 15:11:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.013
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fg1wJFJGWNbo for <tcpm@core3.amsl.com>; Wed, 12 Nov 2008 15:11:53 -0800 (PST)
Received: from smtp1.xmundo.net (unknown [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 377BE3A63D2 for <tcpm@ietf.org>; Wed, 12 Nov 2008 15:11:52 -0800 (PST)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id AC9B06B673B; Wed, 12 Nov 2008 20:11:56 -0300 (ART)
Received: from notebook.gont.com.ar (host21.190-139-184.telecom.net.ar [190.139.184.21]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.13.8) with ESMTP id mACNBaPj028065; Wed, 12 Nov 2008 21:11:40 -0200
Message-Id: <200811122311.mACNBaPj028065@venus.xmundo.net>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 12 Nov 2008 19:06:15 -0300
To: Joe Touch <touch@ISI.EDU>, ayourtch@cisco.com
From: Fernando Gont <fernando@gont.com.ar>
In-Reply-To: <491B0688.5000401@isi.edu>
References: <200810280000.m9S00h4E029878@venus.xmundo.net> <A56C813C-B46D-4A02-A905-DD6B7E163156@windriver.com> <200810280203.m9S23foZ023071@venus.xmundo.net> <523175BF-A76B-4A4C-B726-AE4274BE9A44@windriver.com> <200810290227.m9T2RAHQ001594@venus.xmundo.net> <49088156.6020305@isi.edu> <200811030149.mA31n6fe020648@venus.xmundo.net> <4914B521.3090509@isi.edu> <200811080140.mA81eqGx025906@venus.xmundo.net> <4914EFC9.7060906@isi.edu> <200811080157.mA81vYQA032096@venus.xmundo.net> <4915D19A.4070404@isi.edu> <Pine.LNX.4.64.0811092134370.16978@zippy.stdio.be> <491B0688.5000401@isi.edu>
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Wed, 12 Nov 2008 20:11:56 -0300 (ART)
Cc: ah@tr-sys.de, tcpm@ietf.org, David Borman <david.borman@windriver.com>
Subject: Re: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-urgent-data-00
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org
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..... Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm
- Re: [tcpm] Fwd: New Version Notification for draf… David Borman
- [tcpm] Fwd: New Version Notification for draft-go… Fernando Gont
- Re: [tcpm] Fwd: New Version Notification for draf… Fernando Gont
- Re: [tcpm] Fwd: New Version Notification for draf… Andrew Yourtchenko
- Re: [tcpm] Fwd: New Version Notification for draf… David Borman
- Re: [tcpm] Fwd: New Version Notification for draf… Fernando Gont
- Re: [tcpm] Fwd: New Version Notification for draf… Joe Touch
- Re: [tcpm] Fwd: New Version Notification for draf… Fernando Gont
- Re: [tcpm] Fwd: New Version Notification for draf… Joe Touch
- Re: [tcpm] Fwd: New Version Notification for draf… Fernando Gont
- Re: [tcpm] Fwd: New Version Notification for draf… Joe Touch
- Re: [tcpm] Fwd: New Version Notification for draf… Fernando Gont
- Re: [tcpm] Fwd: New Version Notification for draf… Joe Touch
- Re: [tcpm] Fwd: New Version Notification for draf… Fernando Gont
- Re: [tcpm] Fwd: New Version Notification for draf… Joe Touch
- Re: [tcpm] Fwd: New Version Notification for draf… Fernando Gont
- Re: [tcpm] Fwd: New Version Notification for draf… Stefanos Harhalakis
- Re: [tcpm] Fwd: New Version Notification for draf… Fernando Gont
- Re: [tcpm] Fwd: New Version Notification for draf… Andrew Yourtchenko
- Re: [tcpm] Fwd: New Version Notification fordraft… Anantha Ramaiah (ananth)
- Re: [tcpm] Fwd: New Version Notification fordraft… Eddy, Wesley M. (GRC-RCN0)[VZ]
- Re: [tcpm] Fwd: New Version Notification fordraft… Fernando Gont
- Re: [tcpm] Fwd: New Version Notification fordraft… Andrew Yourtchenko
- Re: [tcpm] Fwd: New Version Notification for draf… Joe Touch
- Re: [tcpm] Fwd: New Version Notification for draf… Fernando Gont
- Re: [tcpm] Fwd: New Version Notification for draf… Joe Touch