Re: [COSE] Key identifier of type bstr / int

[Michael Richardson <[e-mail]>]

Michael Richardson <[e-mail]> 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 <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-