Hi Thomas,
> Now, it turns out in the specific situation (and whenever the data
> framing is provided by a higher layer protocol - CoAP, SCTP, DNS) one
> might as well buffer and coalesce all the application stuff into one
> single record, making the need for CID compression moot.
I'm not sure,
Hi Achim and all,
> > Now, it turns out in the specific situation (and whenever the data
> > framing is provided by a higher layer protocol - CoAP, SCTP, DNS) one
> > might as well buffer and coalesce all the application stuff into one
> > single record, making the need for CID compression moot.
Hi Achim,
> I'm not sure, how CoAP (RFC 7252) offers framing. AFAIK it uses the
> size of the UDP message (or that of the DTLS "application_data" part).
> Only for TCP the size is explicitly encoded in the CoAP messages (but
> that's not RFC7252). If I miss something about that, it would be
> grea
I agree with EKR that this seems like the most expedient solution to the
issue.
--Richard
On Thu, May 21, 2020 at 12:00 PM Christopher Wood
wrote:
> PR #148 in the DTLS 1.3 draft (
> https://github.com/tlswg/dtls13-spec/pull/148) proposes banning implicit
> CIDs. This comes at an obvious cost i
Hi,
I changed my mind and support PR #148 on removing implicit CIDs.
Reason, FWIW: The main use of implicit CIDs is reduced transmission bandwidth
in case of multiple records within a single datagram, which I still consider
valid.
However, firstly there doesn't appear to be consensus on the rele
