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

Hello, Joe,

Comments in-line....

> > So we have to issues:
> >
> > * Deprecate recv(2)/MSG_OOB and encourage SO_OOBINLINE. (with which you
> > seem to agree)
>
>That sounds like a Unix man page update, not an RFC.

RFC 793 specifies a minimalistic/generic API for TCP. Most (if not 
all) systems have misunderstood that API. And that's what I think 
should be clarified. recv(2)/MSG_OOB is simply an example of how the 
TCP API was misunderstood.

> > * Update RFC 793/RFC1122 wrt where the UP points to, to reflect what
> > everybody does and has been doing. (with which I don't know whether you
> > agree or not).
>
>Either this is an implementation error or it updates our definition of PUSH.

Push? Why Push?

And, well, you may take it as an "implementation error". But 
everybody has been ding this for... how long?... twenty years? If you 
were to push TCP implementations to implement the RFC1122-mandated 
semantics of the urgent pointer, that would simply break existing 
applciations, as that change is not backwards-compatible.

After twenty years of doing so, and with every stack doing it, it's 
completely unrealistic to expect any real system to move to the 
RFC1122 semantics of the Urgent Pointer (i.e., "the UP points to the 
last byte of urgent data" instead of "the urgent pointer points to 
the byte following the last byte of urgent data).

Keeping things "as they are" simply means that anybody trying to 
analyze real traffic and interpret it according to the existing 
specs, will be puzzled.

(FWIW, the same day I posted the announcement of our I-D, a TCP 
implementor of one of the major free OSes sent me an off-list note 
mentioning that he found our draft just in time, as he was in trouble 
trying to figure out what everybody was doing wrt TCP urgent data)

>If the former, it can be noted in the next version of the TCP
>implementation errors doc. If the latter, it would update 1122 - NOT
>793. As Dave noted, 1122 supercedes 793 on this issue.

Agreed. It would update RFC1122.

>I don't like the idea of continuing to document implementations that do
>not comply with current specs without either stating
>         a) this is BAD and should be fixed
>         b) this is GOOD and we're changing our spec

We are aiming at "b", if you want. It's not really that it is "good". 
It simply is. It's the real world. Ignoring the real world simply 
helps to have the specs become irrelevant.

>FWIW, so far, this looks to me like an implementation error, not a
>reason to change the spec.

At some point, the specs (RFC 793) were ambiguous. So implementations 
simply picked one of the possible intrepretations. The IETF later 
mandated the other possible interpretation. But nobody changed their 
stacks. And nobody will. At some point it may have been an 
implementation error. Nowadays... who cares? it's the de-facto standard.

What do others think about all this?

Thanks!

Kind regards,

--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

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