Re: [Cbor] Validity checking and tags

[Carsten Bormann <[e-mail]>]

> Some CBOR protocols will require use of a tag to indicate a particular data type (on a per instance basis) and others will explicitly prohibit use of a tag (on a per instance basis).

Normally, you don’t “prohibit a tag”, you say what you want.  “This is a number.”

As in (RFC 8392 in one slide):

cwt = {
  ? iss => text
  ? sub => text
  ? aud => text
  ? exp => ~time
  ? nbf => ~time
  ? iat => ~time
  ? cti => bytes
  * int => any
}

iss = 1
sub = 2
aud = 3
exp = 4
nbf = 5
iat = 6
cti = 7

~time is a number (with a strong hint that this number is meant to be interpreted as similar to how the enclosed data item of a tag with number 1 would be, i.e. as an epoch-based time).

Note that the prelude says:

                  time = #6.1(number)
                  number = int / float

So the three lines

  ? exp => number
  ? nbf => number
  ? iat => number

in the above would have meant exactly the same, but without the little hint about interpretation.

> That implies that generic validity processing can only be performed on data items that are explicitly tagged. For example generic processing can’t check the internal structure of a decimal fraction for validity unless it is tagged. It just won’t know that it is a decimal fraction.

Generic validity processing sees an array and sees that this is valid (from a generic validity processing point of view).  Indeed, it won’t know that the application intends to process this as a decimal fraction.

> I think we expect protocols using using these new / custom / registered / bespoke data types to not require instances to be tagged, so validity checking will be limited. 

The checking cannot be done as “tag validity”, but it needs to be done in the application.

> I think this is mostly OK, but wanted to point it out.

I think so, too.

> (We refer to these new / custom / registered / bespoke data types primarily as tagged, but then say the tag is not necessary; I think this is confusing). 

The short form is: A CBOR-based protocol can make use of a tag definition in an interesting way: not by shaping the data as the tag that has been defined, but by shaping the data as what would have been the enclosed data item of the tag, and then saying with that (in prose, at this point) that the data item is to be processed as if it where that enclosed data item of the tag.  That is a useful device to reduce the amount of variation between different protocols.  Providing direct support for this from a CBOR decoder implementation would be an interesting addition (it would become a schema-informed CBOR decoder then, of course).

All this discussion may be somewhat clouded by the fact that RFC 7049 speaks about “optional tags”; these have never turned out to be particularly useful, so we should no longer talk about those when writing up 7049bis.

Grüße, Carsten