Draft: draft-ietf-core-senml-data-ct

Commentary: Address    DISCUSS by allowing multiple content codings . Use the opportunity to also address    comment that  offered some sympathy to -- but staying with the ( now lower case ) term " content format " . 
 On 2020 - 08 - 19 , at 04:29 ,   < : ( Archived - At : ) Right , this would be what you easily get if you do a “ naïve ” resolution of “ bct " base fields . ( However , Section 4 says that you only copy them to records with “ vd ” fields . ) I think that it would be good to do the same thing with “ naïve ” resolution , i.e. , ignore “ ct ” if there is no “ vd ” . But I do n’t have a strong opinion . Section 3 says : When a SenML Record contains a Data Value field ( " vd " ) , the Record MAY also include a Content - Format indication field . In logic , it simply does n’t say anything about records without “ vd ” . In English , it does seem to imply that the MAY does not apply to them . ( But then it does n’t say what is supposed to happen . ) 
 I believe this is now covered by the text in Section 4 .
Mailing list commentary: For the most part it looks good . However , I am not sure that I understand what the correct behavior for { " bn":"urn : dev : ow::","n":"temp","u":"Cel","vs":"7.1","ct":"0 " } { " bn":"urn : dev : ow::","n":"temp","u":"Cel","v":7.1,"ct":"0 " } Should the ct be ignored if the value is not " vd " ? If it is present but does not make sense what should happen ?
Paragraph (version A):
The Sensor Measurement Lists (SenML) media type supports multiple
types of values, from numbers to text strings and arbitrary binary
data values.  In order to facilitate processing of binary data
values, this document specifies a pair of new SenML fields for
indicating the Content-Format of those binary data values, i.e.,
their Internet media type including parameters as well as any
Content-Coding applied.
Paragraph (version B):
The Sensor Measurement Lists (SenML) media type supports multiple
types of values, from numbers to text strings and arbitrary binary
data values.  In order to facilitate processing of binary data
values, this document specifies a pair of new SenML fields for
indicating the content format of those binary data values, i.e.,
their Internet media type including parameters as well as any content
codings applied.
Paragraph (version A):
The receiver is expected to know how to interpret the data in the
"vd" field based on the context, e.g., name of the data source and
out-of-band knowledge of the application.  However, this context may
not always be easily available to entities processing the SenML pack.
To facilitate automatic interpretation it is useful to be able to
indicate an Internet media type and content-coding right in the SenML
Record.  The CoAP Content-Format (RFC7252) provides this information
in the form of a single unsigned integer; enclosing a Content-Format
number (in this case number 60 as defined for content-type
application/cbor in RFC8949) in the Record is illustrated in ex-2.
All registered CoAP Content-Format numbers are listed in the
IANA.core-parameters IANA.core-parameters as specified by RFC7252.
Paragraph (version B):
The receiver is expected to know how to interpret the data in the
"vd" field based on the context, e.g., name of the data source and
out-of-band knowledge of the application.  However, this context may
not always be easily available to entities processing the SenML pack.
To facilitate automatic interpretation it is useful to be able to
indicate an Internet media type and, optionally, content codings
right in the SenML Record.
Paragraph (version B):
The CoAP Content-Format (RFC7252) provides this information in the
form of a single unsigned integer; enclosing a Content-Format number
(in this case number 60 as defined for content-type application/cbor
in RFC8949) in the Record is illustrated in ex-2.  All registered
CoAP Content-Format numbers are listed in the IANA.core-parameters
IANA.core-parameters as specified by RFC7252.  Note that, at the time
of writing, the structure of this registry only provides for zero or
one content codings; nothing in the present document needs to change
if the registry is extended to allow sequences of content codings.
Paragraph (version A):
a CoAP Content-Format identifier in decimal form with no leading
zeros (except for the value "0" itself).  This value represents an
unsigned integer in the range of 0-65535, similar to the CoRE Link
Format RFC6690 "ct" attribute).
Paragraph (version A):
or a Content-Format-String containing a Content-Type and
optionally a Content-Coding (see below).
Paragraph (version A):
The CoAP Content-Format number provides a simple and efficient way to
indicate the type of the data.  Since some Internet media types and
their content coding and parameter alternatives do not have assigned
CoAP Content-Format numbers, using Content-Type and Content-Coding is
also allowed.  Both methods use a string value in the "ct" field to
keep its data type consistent across uses.  When the "ct" field
contains only digits, it is interpreted as a CoAP Content-Format
identifier.
Paragraph (version A):
If no "@" sign is present after the media type and parameters, then
no Content-Coding has been specified, and the "identity" Content-
Coding is used -- no encoding transformation is employed.
Paragraph (version B):
a CoAP Content-Format number in decimal form with no leading zeros
(except for the value "0" itself).  This value represents an
unsigned integer in the range of 0-65535, similar to the CoRE Link
Format RFC6690 "ct" attribute).
Paragraph (version B):
or a Content-Format-String containing a Content-Type and
optionally zero or more content codings (see below).
Paragraph (version B):
The CoAP Content-Format number provides a simple and efficient way to
indicate the type of the data.  Since some Internet media types and
their content coding and parameter alternatives do not have assigned
CoAP Content-Format numbers, using Content-Type and zero or more
content codings is also allowed.  Both methods use a string value in
the "ct" field to keep its data type consistent across uses.  When
the "ct" field contains only digits, it is interpreted as a CoAP
Content-Format number.
Paragraph (version B):
If no "@" sign is present after the media type and parameters, then
no content coding has been specified, and the "identity" content
coding is used -- no encoding transformation is employed.