Re: [tcpm] urgent data draft (draft-gont-tcpm-urgent-data-01.txt)

Joe Touch <touch@ISI.EDU> Wed, 24 June 2009 02:06 UTC

Return-Path: <touch@ISI.EDU>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BB6143A6EFF for <>; Tue, 23 Jun 2009 19:06:05 -0700 (PDT)
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=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id I3gZklHv9+56 for <>; Tue, 23 Jun 2009 19:06:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 502163A6F07 for <>; Tue, 23 Jun 2009 19:06:03 -0700 (PDT)
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id n5O2523K021285; Tue, 23 Jun 2009 19:05:05 -0700 (PDT)
Message-ID: <>
Date: Tue, 23 Jun 2009 19:05:01 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20090302)
MIME-Version: 1.0
To: Fernando Gont <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
Cc:, David Borman <>,
Subject: Re: [tcpm] urgent data draft (draft-gont-tcpm-urgent-data-01.txt)
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: <>, <>
X-List-Received-Date: Wed, 24 Jun 2009 02:06:05 -0000

Hash: SHA1


Fernando Gont wrote:
> Joe Touch wrote:
>>> P.S.: As there is no practical difference between "points to the last
>>> byte of urgent data" vs. "points to the byte following the last byte of
>>> urgent data", and since all implementations do the later, it does make
>>> sense to change the specs. You had agreed with this reasoning at MPLS.
>>> -- I'm now puzzled.
>> I didn't see in Gorry's note anything about saying we were changing the
>> specs. 
> David Borman had sent a note
> (
> clarifying of each of the points draft-ietf-tcpm-urgent-data was making.
> And that of changing the specs to match the implementations was in that
> list.

That email says "2) Change the definition of the Urgent Pointer (defined
in RFC 1122) to match the definition on page 17 of RFC 793, which is
what most implementations use. "

I was clarifying that this would be a standards-track change to the
specs; I didn't recall that language having been used in this discussion.

>> In general, we should always *try* to take a stand when implementations
>> differ from the standard. This looks like a case where that's possible,
>> so I was just noting that we should do so.
> I'm still puzzled, Joe. In Minneapolis you had stated exactly the
> contrary: that in this particular case, considering that the
> implementations differ from the specs, and that there is no real
> difference the UP pointing to the "last byte of urgent data" vs "the
> byte following the last byte of urgent data", it did make sense to
> change the specs to match the implementations.

Implementations differing from requirements yields three options:

	a) document the difference as Informational, and nothing more

	b) document the implementation as non-compliant

	c) document the implementation as preferred as an
	update to the original requirement (standards track)

I was hoping we could engage the WG in having a discussion on these
three options in general.

> It gets so hard to agree (or even argue) with you when you change your
> opinion so frequently, and in such a radical way.

I have been - and remain - opposed to preferring an implementation to a
standard primarily on the basis of implementation. There have to be
other considerations, notably the impact to the protocol, impact to
users, etc. That means I prefer (b) in general, of the above.

In this particular case, I don't really care whether it's (b) or (c). If
I agreed to (c), it was only because I would also agree to (c).

In *general*, I think that (b) or (c) should be preferred to (a), but
also believe that most of the time that means (b). This is a case where
all known implementations differ from the standard AND where neither the
standard nor the known implementation methods have a particular benefit.
That's quite different from other cases you've brought to this WG.

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