Re: [tcpm] draft-ietf-tcpm-urgent-data-06

[Joe Touch <[e-mail]>]

Hi, Dave,

On 10/12/2010 7:58 AM, David Borman wrote:

> As you said, we don't have applications breaking all over the place.
> Also, the goal of this document isn't to change all the current Urgent
> pointer implementations, but to match the spec to the majority of
> implementations.
>
> The WG did not put forth this document to deprecate the Urgent
> pointer, but to clarify it and warn of the interoperability issues.
>
> So perhaps the "SHOULD NOT" should be changed to a "MAY", meaning
> you can still use it, but be aware of the issues and make sure you
> design around them.

It's sufficient to delete Sec 5 then. It's already a "MAY" for users in 
RFC793 (though 2119 language isn't used, the intent is there). We 
definitely should not restate requirements already sufficiently stated.

> It is entirely possible to reliably make use of
> the urgent pointer in an application, even with different OS
> definitions. The application can the test urgent pointer at the
> beginning of the connection by sending a known piece of data and
> observing how it gets delivered to the receiver, the application can
> then adjust accordingly and use it reliably.

That's not in the doc anywhere. No current app I've ever heard of does 
this, and it doesn't seem practical for most apps (esp. since it's not 
backward compatible; the test data would appear in the data stream). I'm 
not sure this is a useful consideration for this discussion at all.

> Perhaps combine section 5& 6 into a single section like:
> 5.  Advice on using and implementing the TCP urgent mechanism
>
>    As a result of the issues discussed in Section 3.2 and Section 3.4,
>    using the TCP urgent mechanism has the potential to be unreliable.
>    New applications MAY use the TCP urgent mechanism, but should be
>    robust against these issues.

The above simply isn't required; it's already part of RFC793.

>    In addition, applications MUST set
>    the SO_OOBINLINE socket option, such that "urgent data" is delivered
>    inline, as intended by the IETF specifications.

SO_OOBINLINE and its behavior isn't defined in RFC793.

The fact that urgent data is inline needs to be defined and explained. 
Then the requirement stated that urgent pointer data is inline, as is 
all TCP data.

It may be useful to note that the way to do this in some implementations 
is to set this socket option, and that this particular option should 
default to ON (and note that it isn't, so apps should set it), but 2119 
language isn't appropriate. The discussion shouldn't use 2119 language 
in reference to an implementation of the API that isn't required.

>    TCP implementations MUST include support for the urgent mechanism
>    such that existing applications can still use it.

That's not necessary either; it's in 793, and it's already required 
therein. Again, I don't think this doc should restate existing requirements.

Joe