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

[Carsten Bormann <[e-mail]>]

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

Absolutely.  Making that easier to do was one reason we introduced ~ (unwrap) in CDDL.


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

Well, EAT should simply say what the claim is.  There is no need for a/b/c here.
Either you use the tag or just its definition of the semantics applied to the enclosed data item; I can’t imagine a case where anything is gained by allowing both.

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

Yes.  But it’s not that CWT forbids tags, it is that it defines the first seven claims for CWT in a way that does not make use of tags.  It would be as misleading to say that “COSE is forbidden in CWT” because the first seven claims don’t use COSE.

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

They never can for all tags, because all tags haven’t been invented yet.

> Mine does. That means those types of generic decoders have to know about case a), b) and c).

I still don’t think so.  That would only be the case if the decoder doesn’t “handle” the tag, but “hides” it.  That would indeed lead to problems.

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

Thanks.  We need to have these discussions to ensure we don’t have language in the spec that turns out to be misleading.  I just pushed a pull request for CBORbis that massively rearranges the language around tags, please have a look:

https://github.com/cbor-wg/CBORbis/pull/109

Grüße, Carsten