Re: [Cbor] Chair review of cbor-file-magic 08

[Carsten Bormann <[e-mail]>]

On 2022-03-07, at 22:08, Michael Richardson <[e-mail]> wrote:
> 
> 
> 
> Christian Amsüss <[e-mail]> wrote:
>> Two things were left but minor enough to be addressed in the next phase:
> 
>> * In Section 5.3 (IANA / CBOR Tags for CoAP Content-Format Numbers), it
>> still says "Date item: byte string"
> 
> In the other two IANA cases it says "tagged byte string"
> In the CF case, the *tag* we agreed applies to the byte string 'BOR'
> 
> In the case of 55800 (5.1) and 55801 (5.2), the newly allocated tags apply to
> a tagged byte stream.  I.e.:
>  #6.55800<#6.12345678<BOR>>
> 
> while for the CF tags, it's not the outer piece that we are allocating,
> but the inner part (12345678).  So it's correct: it tags 'BOR', not #6.foo<BOR>

The tags allocated in 5.3 are described in Appendix A.
This should make clear that the data item is actually /any/.
(Byte string normally and in cases of 55800 and 55801, but /any/ in case of tag 55799.)

>> * The introduction of Appendix A ("CBOR Tags for CoAP Content Formats")
>> says:
> 
>>> Often, there is a need to identify a media type (or content type,
>>> i.e., media type optionally used with parameters) that applies to
>>> the contents of a byte string in a CBOR data item.
> 
>> Of all the things we describe how these 64k tags could be used,
>> annotating a byte string is none of them -- and I think the sentence
>> just needs an editorial nudge.
> 
> How about this:
> 
> diff --git a/cbor-file-magic.mkd b/cbor-file-magic.mkd
> index 3db8f84..7939740 100644
> --- a/cbor-file-magic.mkd
> +++ b/cbor-file-magic.mkd
> @@ -401,16 +401,13 @@ Reference:
> 
> # CBOR Tags for CoAP Content Formats {#ct-tags}
> 
> -Often, there is a need to identify a media type (or content type,
> -i.e., media type optionally used with parameters) that applies to the
> -contents of a
> -byte string in a CBOR data item.
> -
> {{Section 5.10.3 of -coap}} defines the concept of a Content-Format,
> which is a short 16-bit unsigned integer that identifies a specific
> content type (media type plus optionally parameters), optionally
> together with a content encoding.
> 
> +Outside of a CoAP transfer it may be necessary to identify the contents of the CoAP payload when it is on disk, in firmware, or when debugging.
> +

This almost works for me, except that it somehow relates this to CoAP transfer.
The Content-Format concept comes from CoAP, but is not limited to CoAP transfer (e.g., RFC 9165).

How about:

> +Outside of a transfer protocol that indicates the Content-Format for a representation, it may be necessary to identify the Content-Format of the representation when it is on disk, in firmware, or when debugging.
> +

Or some such.

Grüße, Carsten