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
<[email protected]
<mailto:[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/
<https://mailarchive.ietf.org/arch/msg/cose/q_6kay8Z_4Wr48TFBXZU2oGRqoE/>____
__ __
__ __
__ __
__ __
*From: *Carsten Bormann <[email protected] <mailto:[email protected]>>
*Date: *Tuesday, 22 March 2022 at 00:00
*To: *Michael Richardson <[email protected]
<mailto:mcr%[email protected]>>
*Cc: *Laurence Lundblade <[email protected] <mailto:[email protected]>>, Orie Steele
<[email protected]>, Göran Selander <[email protected]
<mailto:[email protected]>>, [email protected] <mailto:[email protected]> <[email protected]
<mailto:[email protected]>>
*Subject: *Re: [COSE] Key identifier of type bstr / int____
On 21. Mar 2022, at 23:20, Michael Richardson <[email protected]
<mailto:mcr%[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] <mailto:[email protected]>
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
[email protected]
https://www.ietf.org/mailman/listinfo/cose
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
