Re: [Cbor] I-D Action: draft-ietf-cbor-file-magic-06.txt

[Christian Amsüss <[e-mail]>]

Hello Carsten, hello Michael,

> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-cbor-file-magic-06

The example has now become inconsistent, mixing the CBOR Tag Wrapped and
CBOR Tags for Content Formats parts:

> to translate the Content-Format number registered for
> application/senml+cbor, the number 112, into the tag 1668546560+112 =
> 1668546672.
>
> 55799(1668546672([{0: "current", 6: 3, 2: 1.5}]))

puts CBOR data into the content-format generated item, whereas Appendix
A says:

> The tag content tagged with tag number [...] is a byte string that is
> to be interpreted as a representation of the content format
> NNNNNNNN-1668546560.

which would look like 55799(1668546672(h'a30067...')).

My understanding so far was that with the current appendix, all data
would be bstr-valued, and if a) the content format is CBOR based, and b)
the transport coding is "identity", and c) the representation is
actually well-formed in the advertised content format, only then will
the byte string (happen to) be valid CBOR, but still encoded in a byte
string.

I kind of like having pre-allocated tags for the CBOR protocols implied
by a content format (where applicable) for reasons of closure, that it
works this way and how it works (can't share the same 16bit tag range
without creating ambiguity, can it?) needs to be spelled out -- right
now, this is internally contradictory.

Could you clarify what your intentions are here, or whether I missed a
discussion due to which this is being changed?

BR
Christian

-- 
There's always a bigger fish.
  -- Qui-Gon Jinn