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

From: Laurence Lundblade <lgl@island-resort.com> 
Sent: Tuesday, January 21, 2020 6:26 PM
To: Jim Schaad <ietf@augustcellars.com>
Cc: Carsten Bormann <cabo@tzi.org>; cbor@ietf.org; Kio Smallwood <kio@mothers-arms.co.uk>
Subject: Re: [Cbor] Request for IANA registry addition for cbor tag

My bad. I read the proposal wrong.  Let me try again.

1) Decoder recognizes and supports the tag. A nice ordered map will be returned to the caller.

2) Decoder knows nothing of the tag. A tag plus an array (not a map) will be returned to the caller in order.

3) The programing environment can’t support returning an ordered map and the implementor considers doing something about the tag

3a) The mellow implementor opts for 2).

3b) The knows-what-is-best implementor considers the input invalid and returns an error.

3c) The lets-all-get-along implementor offers an option to behave as 2) or 3b).

This tag is really aimed at type 1) so it is sort of the same, if you use this tag, be sure the decoder supports it. Same with just about any tag. Seems OK.

Separately...

So it appears to me that no where does it say “arrays are ordered” in 7049 or CBORbis. This seems like an omission that should be fixed. They are ordered aren’t they? COSE would break if they weren’t.

[JLS]  I think that this is implicit in the definition.  Everything would break if arrays are not ordered.

Also, I noticed recently that JWT requires either duplicate detection or take-last. CWT is silent on this including inheriting this behavior from JWT.

[JLS] I would actually say that CWT is going to inherit behavior from 7049 not from JWT.

Jim

LL

On Jan 21, 2020, at 5:05 PM, Jim Schaad <ietf@augustcellars.com <mailto:ietf@augustcellars.com> > wrote:

-----Original Message-----
From: CBOR <cbor-bounces@ietf.org <mailto:cbor-bounces@ietf.org> > On Behalf Of Carsten Bormann
Sent: Tuesday, January 21, 2020 12:03 PM
To: Laurence Lundblade <lgl@island-resort.com <mailto:lgl@island-resort.com> >
Cc: cbor@ietf.org <mailto:cbor@ietf.org> ; Kio Smallwood <kio@mothers-arms.co.uk <mailto: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 <mailto: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 <mailto:CBOR@ietf.org> 
https://www.ietf.org/mailman/listinfo/cbor