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

Stefanos Harhalakis <v13@v13.gr> Sun, 09 November 2008 13:29 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 19E423A6977; Sun, 9 Nov 2008 05:29:33 -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 11C7B3A6977 for <tcpm@core3.amsl.com>; Sun, 9 Nov 2008 05:29:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 5bcIvJ60WLCR for <tcpm@core3.amsl.com>; Sun, 9 Nov 2008 05:29:31 -0800 (PST)
Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.104]) by core3.amsl.com (Postfix) with ESMTP id E7D523A6971 for <tcpm@ietf.org>; Sun, 9 Nov 2008 05:29:30 -0800 (PST)
Received: from mx-av-05.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-01.forthnet.gr (8.14.3/8.14.3) with ESMTP id mA9DTPXU022762; Sun, 9 Nov 2008 15:29:25 +0200
Received: from MX-IN-05.forthnet.gr (mx-in-05.forthnet.gr [193.92.150.30]) by mx-av-05.forthnet.gr (8.14.3/8.14.3) with ESMTP id mA9DTPA8021464; Sun, 9 Nov 2008 15:29:25 +0200
Received: from hell.hell.gr (adsl61-198.lsf.forthnet.gr [79.103.188.198]) by MX-IN-05.forthnet.gr (8.14.3/8.14.3) with ESMTP id mA9DTKeZ010274; Sun, 9 Nov 2008 15:29:22 +0200
Authentication-Results: MX-IN-05.forthnet.gr smtp.mail=v13@v13.gr; spf=neutral
Authentication-Results: MX-IN-05.forthnet.gr header.from=v13@v13.gr; sender-id=neutral
From: Stefanos Harhalakis <v13@v13.gr>
To: tcpm@ietf.org
Date: Sun, 9 Nov 2008 15:29:20 +0200
User-Agent: KMail/1.9.9
References: <200810280000.m9S00h4E029878@venus.xmundo.net> <200811082300.mA8N0FPj001169@venus.xmundo.net> <49162A91.30403@isi.edu>
In-Reply-To: <49162A91.30403@isi.edu>
MIME-Version: 1.0
Content-Disposition: inline
Message-Id: <200811091529.20537.v13@v13.gr>
Cc: ah@tr-sys.de, ayourtch@cisco.com, David Borman <david.borman@windriver.com>, Fernando Gont <fernando@gont.com.ar>, Joe Touch <touch@isi.edu>
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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

On Sunday 09 November 2008, Joe Touch wrote:
> > 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.

What Fernando says (as far as i understand) is that we have a reality here 
where everyone does the X thing (where X may be "wrong"). This is a reality 
and we have to accept it.

After accepting that this actually happens, we must either (a) persuade 
everyone to change their implementation or (b) update the RFC.

It seems that (a) isn't possible since it will introduce a backward 
incompatibility and practically invalidate the urgent pointer as a whole.

Since everyone does the X thing we can easily update the RFC without 
practically changing the actual meaning (or interpretation since everyone 
does it already the other way) of UP.

RFCs MUST be at sync with the real world. Having RFCs that don't represent 
reality makes RFCs as a whole (or at least TCP related) less valuable and 
less respectable. This will also save time and pain from all current and 
future TCP implementors.
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm