Re: [core] #388 (coap-tcp-tls): Multiple versions over the same connection

[Christian Groves <[e-mail]>]

Hello Carsten,

Thanks for the background. I agree version negotiation for a reliable 
would be done at the start at the start of the stream. I was thinking 
that having backward compatible versioning might simplify negotiation 
but it seems one can't make that assumption.

Regards, Christian

On 27/04/2016 4:01 PM, Carsten Bormann wrote:
> Hi Christian,
>
>> Is there any assumption that new CoAP versions need to be backward
>> compatible? I didn't see anything mentioned in RFC7252.
> UDP CoAP packets have a "version number" because there were two bits
> free in the header and we wanted to have a specific bit pattern in there
> so CoAP packets multiplex nicely with DTLS and STUN packets on the same
> port.
>
> Nobody had or has any idea what a future version of CoAP would look
> like; no need for one has come up*).  A different version number would
> only be used to ensure that current CoAP implementations never process
> messages in a future new format; CoAP's protocol evolution method is to
> use options.
>
> In a reliable stream (TCP/TLS/Websockets), there is no need to indicate
> a protocol version per-message; if version negotiation is ever required,
> this can be done at the start of the stream.
>
> Grüße, Carsten
>
> PS.: I'm not sure people have tried using different HTTP versions (1.0
> vs. 1.1) within the same TCP connection; not that HTTP versions ever
> meant that much...   (See the note in Section 3.5 of RFC 7540 for the
> HTTP/2 view on that.)
>
> *)  OK, maybe we want to have a longer message ID in a future high-rate
> variant of UDP CoAP.  No message-IDs are needed in TCP CoAP...
>