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

[Laurence Lundblade <[e-mail]>]

Here's text I think might be useful to add to the Creating CBOR-based Protocols section:

Protocols using data types defined in the section Tagging of Items section can use them with explicit tags (type 6 enclosing data items) or with no tag and their type implied (no type 6 enclosing data item). If there is no explicit tag, the protocol design should be sure the data type can be unambiguously recognized in all use case. This is often accomplished by saying a member of a map with a particular label is always of a particular type.

Explicit tagging should only be used when it is actually necessary to clearly distinguish the type.

Some protocol designs may forbid explicit tagging of particular data items.

Protocol designs should directly state whether explicit tagging is required, disallowed or optional for each use of these data types.

One of the reasons I’m bring this up is that in a way section 3.4 Tagging of Items  has the horse before the cart. The definition of the new data types seems more important than the tagging as the tagging is the optional part. Alternative titles for the section might be Additional Data Types or Compound Data Types. The somewhat unclear (to me) characterization of the optionality of tagging is why I asked about tags in decimal fractions.


I think it is useful and practical for generic decoders to directly support tagged data types rather than just passing them on to the caller with the tag.

In some cases the tagged data types may have natural representations in the language or the platform (e.g. time formats). In some cases the tagged data types are complex enough that some CBOR expertise it helpful (e.g., array tags) when implementing. The decoder author might also want to encapsulate more of CBOR so the caller doesn’t have to know as much about CBOR.

Obviously, it can’t be for tags that aren’t invented yet, some tagged data types have use that is too narrow, and some may be poorly designed in the opinion of the author of the decoder. Generic decoders should also support the caller implementing tagged data types on their own and a mode to pass tags through.

That’s all just my view and no particular issue with the text. I mention it in part to say that generic decoders supporting tagged data types may wish to have features in their API to handle explicit / implicit tagging.

LL




> On Aug 25, 2019, at 2:32 PM, Carsten Bormann <[e-mail]> wrote:
> 
> 
>> 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
> 
> _______________________________________________
> CBOR mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cbor