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

[Joe Touch <[e-mail]>]

Hi, Dave,

One additional point (while I wait to see if Ron agrees with your 
summary); the current discussion of in-line data still needs to be 
revised to avoid relying primarily on the definition of a particular 
interface (SO_OOBINLINE).

As to your point, IMO *every* aspect of a protocol is SHOULD NOT by your 
definition, i.e., every capability should not be used unless its 
implications, side-effects, and nuances are understood.

To me, SHOULD NOT on an existing, required protocol capability 
effectively relegates it to "deprecated", i.e., there to support legacy 
apps. There's no point in a MUST NOT on such a capability - MUST NOT 
would mistakenly suggest that the capability need not be implemented 
anymore.

Joe

On 10/19/2010 7:18 PM, David Borman wrote:
>
> On Oct 19, 2010, at 5:10 PM, Joe Touch wrote:
>
>>
>>
>> On 10/15/2010 3:00 PM, Jari Arkko wrote:
>>> Joe,
>>>
>>> Just a quick response on one point:
>>>
>>>> - based on the note from Jari, I can't tell whether the
>>>> doc is recommending SHOULD NOT for new apps or not
>>>
>>> My text did not change that aspect in any way. The new text is in the
>>> introduction and has no keywords. The formal requirement is later in the
>>> document. IIRC the current text there says SHOULD NOT for new apps.
>>
>> Correct. In that case, the note was not responsive to the thread I raised discussing the point that this is a new and substantial change, one that I feel suggests that the title, abstract, and overall structure should be inverted to focus on SHOULD NOT as the key point.
>>
>> It's hard to understand a doc that basically focuses on a change to the spec, and includes the SHOULD NOT almost parenthetically.
>
> We're not trying to deprecate the URGENT pointer.  The goal is to first align the spec with the implementations, and then point out issues with the URGENT pointer, which is how the doc is currently structured.  I don't want the "SHOULD NOT" to be the main point of this document, it is a secondary point due to the issues listed.  The SHOULD NOT applies to new applications, and it means "If you really want to make use of the URGENT pointer, make sure you understand and have addressed all the issues pointed out in this document."
>
> The SHOULD NOT for application writers using the URGENT pointer, not for the URGENT pointer support in the TCP implementations.  I have no objections to the additional highlighting of this, but that doesn't make it the key point of the document.  I say leave the document as it is.
>
> 			-David Borman
>
>>
>> Joe
>