Re: [Cbor] Invalid decimal fraction / big float?

[Laurence Lundblade <[e-mail]>]

> On Aug 25, 2019, at 12:45 PM, Carsten Bormann <[e-mail]> wrote:
> 
> On Aug 25, 2019, at 21:22, Laurence Lundblade <[e-mail]> wrote:
>> […] OK. Tag 2/3 is required. 
>> 
>> It seemed worth checking to me because of 1) comments and emails during the recent Prague meeting about tags being hints and optional and
> 
> That language is a bit weird.
> 
> Tags are elements of the CBOR data model.
> Their use is indeed optional, like with any other element of the CBOR data model.
> Some applications may be able to make sense of a CBOR data item while ignoring Tags that actually are present, but this requires a lot of foresight on the side of the application designer.
> 
> I don’t know why Tags would be “hints” in a general sense (well, some of them are designed to be exactly that, but that is then the semantics of that specific Tag — e.g., JSON encoding hints).

Yes, I misused the word “hints” here.


>> 2) CWT expressly forbidding them.
> 
> That is not the case at all.
> Only those 7 claims defined in RFC 8392 are defined to not use Tags (because they don’t need them, and nothing is gained by allowing them).

I mean forbids them only for the claims it defines:

   The claim values defined in this specification MUST NOT be prefixed
   with any CBOR tag. For instance, while CBOR tag 1 (epoch-based date/
   time) could logically be prefixed to values of the "exp", "nbf", and
   "iat" claims

Digging in a little deeper…

The claims “exp”… are defined by reference to NumericDate in JWT. They are not actually defined as a CBOR tag 1 date without a tag. This makes the comment about them not being tagged in 8392 a bit mis guided (but not problematic).

CWT aside, by my understanding, it is allowed for CBOR protocols to make use of the data types defined in “Optional Tagging of Items” section of 7049 without explicitly adding a tag. 

For example, I could say in the EAT definition that the claim labeled “teetime”  is a tag 1 epoch-based date as defined in 7049. EAT could (should?) then say which of a), b) or c) is allowed for use of the tag 1. Right? Since the data type is known from the map label / key any of a), b) or c) will work.

Maybe a bit more guidance on selecting between a), b) and c) in a protocol design would be useful?


> I cite from Section 5 of RFC 8392:
> 
> …  this does not prohibit future claim
>   definitions from requiring the use of CBOR tags for those specific
>   claims.

Agreed


>> Wanted to be sure there was no assumptions being made. 
>> 
>> There seems to be no rule about when tags are present or not. Each protocol gets to decide between:
>> a) required — for example decimal fraction
>> b) forbidden — for example time CWT
> 
> CWT can do that because the exp/nbf/iat claims are simply defined that way.
> There is nothing “forbidden” here.  If you really want to use this word, you are also “forbidden” to tag a claim 1 (“iss”) as a URI (or as a geographic coordinate, for that matter) — this claim always gets a text string.
> (Note that CWT defines Tag 61 as “CWT” and also uses COSE Tags, which makes it even more obvious Tags are not “forbidden” with CWT.)

When CWT says “MUST NOT be prefixed with any CBOR tag”, it sounds semantically like “forbidden” to me.


>> c) optional — (I don’t know of an example)
> 
> Any protocol that uses CDDL `unsigned` has “optional” Tags:
> Numbers below 2**64 do not use Tags, numbers equal to or greater than 2**64 do.
> 
>> A good generic decoders will handle all three, probably with some feature in the API to say which of the above scenarios to use.
> 
> Since the generic decoder hands the application the decoded data item, the application can handle the Tags and their being required/optional/forbidden.

Generic decoders can handle tagged types inside the decoder itself. Mine does. That means those types of generic decoders have to know about case a), b) and c). As the number of data types expands and becomes more useful, having generic decoders handle them seems beneficial. 


> 			.oOo.
> 
> I think that these are good comments, because they can help us get rid of some weasel wording in RFC 7049.  (In 2013, the concept of Tags was somewhat revolutionary, and maybe the authors were a bit too cautious foisting it on the CBOR community.  By now, people have become familiar with Tags, so maybe we can say in simpler words how they work.)


Despite my nit picking, I really do like CBOR a lot

LL