I prefer A, and have appreciated learning the history of the issue... I think the other proposals are not worth the cost.
OS On Tue, Mar 22, 2022 at 3:42 AM Göran Selander <goran.selander= [email protected]> wrote: > > I’d like to ask those who are proposing kid => int / bytes: are the > two kid name spaces disjoint > > > > Yes. An integer kid is considered different from a byte string kid. > > > > > > Just to be clear on the source. This proposal is based on a previous > conclusion on the COSE mailing list considering different solutions: > > > > Solution A. > > kid => int / bytes > > > > Solution B. > > kid => bytes > > kid2 => int / bytes > > > > Solution C. > > kid => bytes > > kid2 => int > > > > In this previous discussion (see first part of this thread [1]) there was > a mild preference for A. We can revisit this now, but it is good if people > participating in the discussion are aware of the arguments made previously. > > > > > > Göran > > > > [1] > https://mailarchive.ietf.org/arch/msg/cose/q_6kay8Z_4Wr48TFBXZU2oGRqoE/ > > > > > > > > > > *From: *Carsten Bormann <[email protected]> > *Date: *Tuesday, 22 March 2022 at 00:00 > *To: *Michael Richardson <[email protected]> > *Cc: *Laurence Lundblade <[email protected]>, Orie Steele > <[email protected]>, Göran Selander <[email protected]>, > [email protected] <[email protected]> > *Subject: *Re: [COSE] Key identifier of type bstr / int > > On 21. Mar 2022, at 23:20, Michael Richardson <[email protected]> > wrote: > > > >> kid => int / bstr > > > > It's one of the features of CBOR, as a self-describing format, that we > can > > introduce new ways to do things. > > Indeed. > > So this is obviously an extension. Old implementations can’t use the new > data items enabled by that extension. > New implementations don’t have problems with old data items, so we call > this backwards compatible, but not forward compatible. > We didn’t identify this as an extension point, so the lack of forward > compatibility is likely to be universal — if you use an integer kid, old > systems overwhelmingly will not understand you. > > Now, there is also API compatibility — can you upgrade the COSE library > without upgrading the using application. > > I’d like to ask those who are proposing kid => int / bytes: are the two > kid name spaces disjoint (so you need an API extension, too), or is an > integer kid just a way to express the same kid as was already possible to > express using a byte string kid. Another way to say the latter is that all > kids are byte strings and the integer representation is just a compressed > way to express such a byte string. Obviously, the latter way to interpret > kids is slightly less efficient, because there are now two ways to express > certain kids. But the change is also local, i.e. you can do it in your > library without changing anything else. > > If we go for the latter, we will want to make sure that in particular the > integers -24..23 map to useful byte strings and v.v. Note that there is no > need to make these byte strings short; e.g., a decimal representation > (‘-24’ to ‘-1’ and ‘0' to ’23’ in CBOR DN), or maybe an octal one (’50’ to > ’77’ and ’00’ to ’27’) would work well. We don’t even need to support > integers outside -24..23. > > Grüße, Carsten > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose > -- *ORIE STEELE* Chief Technical Officer www.transmute.industries <https://www.transmute.industries>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
