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

[Anders Rundgren <[e-mail]>]

On 2022-03-22 14:58, Orie Steele wrote:
> I prefer A, and have appreciated learning the history of the issue... I think the other proposals are not worth the cost.

Right, it is backward compatible and doesn't break existing code and applications.  This would be similar to an API method where you add an optional argument.  You obviously have to update associated documents, with something like "introduced in API level 3".  Why couldn't that apply to RFCs as well?


Personally I would (in the name of symmetry), make "kid" arguments comparable to CBOR map keys.  That is, kid => CBOR data item.

Anders

> 
> OS
> 
> On Tue, Mar 22, 2022 at 3:42 AM Göran Selander <goran.selander=[e-mail] <mailto:[e-mail]>> 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/ <https://mailarchive.ietf.org/arch/msg/cose/q_6kay8Z_4Wr48TFBXZU2oGRqoE/>____
> 
>     __ __
> 
>     __ __
> 
>     __ __
> 
>     __ __
> 
>     *From: *Carsten Bormann <[e-mail] <mailto:[e-mail]>>
>     *Date: *Tuesday, 22 March 2022 at 00:00
>     *To: *Michael Richardson <[e-mail] <mailto:[e-mail]>>
>     *Cc: *Laurence Lundblade <[e-mail] <mailto:[e-mail]>>, Orie Steele <[e-mail]>, Göran Selander <[e-mail] <mailto:[e-mail]>>, [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>
>     *Subject: *Re: [COSE] Key identifier of type bstr / int____
> 
>     On 21. Mar 2022, at 23:20, Michael Richardson <[e-mail] <mailto:[e-mail]>> 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
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/cose <https://www.ietf.org/mailman/listinfo/cose>
> 
> 
> 
> -- 
> *ORIE STEELE*
> Chief Technical Officer
> www.transmute.industries
> 
> <https://www.transmute.industries>
> 
> _______________________________________________
> COSE mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cose