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

-----Original Message-----
From: CBOR <cbor-bounces@ietf.org> On Behalf Of Carsten Bormann
Sent: Tuesday, January 21, 2020 12:03 PM
To: Laurence Lundblade <lgl@island-resort.com>
Cc: cbor@ietf.org; Kio Smallwood <kio@mothers-arms.co.uk>
Subject: Re: [Cbor] Request for IANA registry addition for cbor tag

Hi Laurence,

I’m not sure I follow.  Decoders either implement a tag or they don’t.

> On 2020-01-21, at 18:58, Laurence Lundblade <lgl@island-resort.com> wrote:
> 
> Here’s some decoders types in relation to this tag:
> 
> 1) It recognizes the tag, supports it and does the right thing.

That would be a decoder that implements the tag.

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

That would be a decoder that fundamentally doesn’t accept this tag.
Not particularly useful.
What does “can’t do what is required” mean?

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

How would that be OK?  But maybe I don’t understand that “do the wrong thing” means.

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

Which would be to present the tag number and the tag content to the application.

> 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.

Now I’m completely lost about your type 3.  “Do the wrong thing” and “OK” don’t mix that well for me…

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

I think 7049bis might need some more text about handling unimplemented tags in decoders.

Right now, it says:
  Implementations receiving an unknown tag number can choose to simply ignore
  it or to process it as an unknown tag number wrapping the enclosed data
  item. The IANA registry in {{ianatags}} is the appropriate way to

[JLS]
Carsten,

I would argue that the decode that I use obeys the text above and would fall into the category of decode that is going to do one of "bad" things Laurence discussed above.  It will return a tree with the following 
<TAG  new tag number>
   <MAP>
       [<key> <value>]+

However, depending on what the final language that the group comes up with for the duplicate tag language, it will either take the first, the last or throw and exception when a duplicate tag is found.  That says that it can not do the first option (hey dup tags are not done will for hash based maps) and thus will either do 3  or totally fail.

I would not really be a huge fan of this tag.  If this is really what you want to do then an array seems to me to be a better answer.

Jim

But it also says:
Generic encoders provide an application interface that allows the application to specify any well-formed value, including simple values and tags unknown to the encoder.

So a generic encoder would not have problems with unimplemented tags; but other (e.g., task-specific) implementations might.

Grüße, Carsten

_______________________________________________
CBOR mailing list
CBOR@ietf.org
https://www.ietf.org/mailman/listinfo/cbor