Re: [Cbor] Request for IANA registry addition for cbor tag

[Laurence Lundblade <[e-mail]>]

Here’s some decoders types in relation to this tag:

1) It recognizes the tag, supports it and does the right thing.

2) It recognizes the tag, knows it can’t do what is required and errors out. For this decoder this type is invalid.

3) It doesn’t recognizes the tag and happens to do the wrong thing. That is perfectly OK.

4) It doesn’t recognize the tag and happens to do the right thing.

So anyone using this tag really needs to be sure they are using a decoder of type 1. Decoder types 3 and 4 are really the same in that there is no way to know which one you’ve got.

I don’t think we want some sort of implication that decoder type 3 is defective creating a situation where all decoders are forced to support this.

I think this should be spelled out in the description of this tag.

LL



> On Jan 21, 2020, at 3:26 AM, Carsten Bormann <[e-mail]> wrote:
> 
> Hi Kio,
> 
> overall, your registration request looks good to me.
> (Nit: The way you are using single quotes in your diagnostic notation triggers appendix G.2 of RFC 8610 [0], which apparently is not what you want.)
> In the editorial revision of RFC 7049 that we are creating right now [1], we are moving away from the concept of a strict decoder; instead we are identifying the specific checking tasks in more detail (here: map validity [2]).
> 
> Thank you for also bringing this to the WG.
> A lot of people have been suggesting one or another form of ordered map (including ordered multimaps, which would remove the need for avoiding duplicate keys).  Maybe we can have a short discussion if the registration of this kind of ordered maps is a good reason to complete registration of related kinds.
> 
> Grüße, Carsten
> 
> [0]: https://tools.ietf.org/html/rfc8610#appendix-G.2
> [1]: https://github.com/cbor-wg/CBORbis
> [2]: https://cbor-wg.github.io/CBORbis/draft-ietf-cbor-7049bis.html#rfc.section.5.3.1
> 
>> On 2020-01-21, at 12:14, Kio Smallwood <[e-mail]> wrote:
>> 
>> Hi CBOR list,
>> 
>> I'd like to register the following tag for representing key-value maps where the order of keys is significant and must be passed through encode/decode steps without re-ordering:
>> 
>> 
>> Requesting tag #272
>> Data item: array
>> Semantics: Ordered Map
>> Point of contact: [e-mail]
>> Description of semantics (URL): https://github.com/Sekenre/cbor-ordered-map-spec/blob/master/CBOR_Ordered_Map.md
>> 
>> 
>> Thanks!
>> 
>> _______________________________________________
>> CBOR mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/cbor
> 
> _______________________________________________
> CBOR mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cbor