Michael Richardson <[email protected]> wrote: > Of course, it breaks if you can't process the new type. You'll reject > it. That's fine. You'll reject anything you don't undrstand. It's not > backwards compatible.
I received private email suggesting that surely I mean, forwards compatible. Nope, I mean backwards compatible. That means that a new sender can operate with an older receiver. MIME headers are backwards compatible. The sender doesn't need to know if my MTA supports DKIM headers, it can just put them in. My end will ignore stuff it does not understand. At the cost of transfering those bytes. If we change kid: to accept int as well as bstr, then a new sender who uses *int* will not be understood by an older receiver. But, since COSE is not a Protocol in of itself, but rather a building block for some bigger protocol (like RATS EAT, or draft-ietf-anima-constrained-voucher), if COSE adds int to the list of valid kids, then it would be up to EAT, or constrained-voucher to say which version of COSE it supports. -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
