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

On Sat, 8 Nov 2008, Joe Touch wrote:

> I expect that, even if the IETF had a compliance process, the specs are
> always out of sync with what is deployed, and represent what
> implementations should try to achieve.

I think you did not mention one step before that - that the creation of 
the specs in the first place is to ensure the interoperability, not just 
for the sake of the specs themselves.

If the interoperability is already achieved by other means ("the running 
code" deployed everywhere), the specs become irrelevant. If then complying 
to the specs breaks that interoperability, they become outright harmful.

> Implementers should design protocols to specs; they should design
> applications to specs together with man pages and errata that discuss
> where the two diverge.

After reading the set of what I could find - the only conclusion 
regarding TCP Urgent that I could come to if I was designing an 
application - "Don't use it. At all."

On a related note, my understanding from reading the 
http://msdn.microsoft.com/en-us/library/ms740102(VS.85).aspx is that when 
the callers use SO_OOBINLINE in an attempt to be the "RFC-compliant", the 
urgent flag and pointer are pretty much a no-op altogether - maybe someone 
could correct me if I missed something:

"Note  When the SO_OOBINLINE socket option is set, the SIOCATMARK IOCTL 
always returns TRUE, and OOB data is returned to the user as normal 
data."

>
> IMO, the specs cannot constantly be downgraded to represent what is
> implemented solely for that reason; downgrading can - and should - occur
> if we, as a community, decide to change what we *want* the protocol to do.
>

This is a good point - so I will take a risk of being burned in-place for 
heresy :) - and will put a few open questions of a broader scope to the 
community:

1) Given the state of the matters and practical experience, are the OOB 
notifications (which TCP Urgent boils down to?) utilised enough in the 
today's (and tomorrow's) world to have them as part of the "core" protocol 
header as opposed to being an option ?

(searching suggests this has already been on the table back in '94 as one 
of the "small changes" within the tcpng bounds - but I was not able to 
find any discussions on the topic - I presume they happened offline - so 
would very much appreciate an enlightenment from someone who happened to 
be part of those discussions).

2) Would we want to more effectively utilise these 16 bits in the TCP 
header (assuming the URG flag rests at "0"), rather than transmitting two 
zero bytes for 99.99% of the cases ?

thanks,
andrew
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm