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

[Joe Touch <[e-mail]>]

PS - to summarize my suggestions to wrap this up:

- delete section 5

- revise section 6 to explain what inline vs. out-of-band data is, and 
remind users that urgent is NOT an out-of-band signal -- that the data 
indicated by the urgent pointer MUST NOT be extricated from the data 
byte stream presented to the user via means indicated in RFC793 (e.g., 
read calls). This would also note that in some implementations this is 
requires overriding the default, and setting SO_OOBINLINE=1.

Joe

On 10/12/2010 9:12 AM, Joe Touch wrote:
> 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