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

Commentary: Alexey notes ( Archived - At : ): Since data - ct needs almost all of the “ normative ” ABNF in media - content - type - format , I think the right thing to do would be to fully develop media - content - type - format and make it a normative reference . ( Note that media - content - type - format probably needs to be run by httpbis and emailcore [ ? ] soon and when it is nearing WGLC , and there may be surprises there . ) This course of action would probably delay data - ct a bit ; we might counteract the damage by early registration . Since data - ct only needs an “ Expert Review ” registration , we could decide to do this when we have processed the reviews that are now incoming . 
 I did n't do thorough review of the ABNF but otherwise looks good to me
Mailing list commentary: Hi all , Sorry for the belated review . I think the document is nearly ready for progression . I have a couple of minor related issues : 2 . Terminology Readers should also be familiar with the terms and concepts discussed in [ RFC8428 ] . Awareness of terminology issues discussed in [ I - D.bormann - core - media - content - type - format ] can also be very It is expired and it is currently not a WG document . At minimum it should be revived . ( Or see below ) helpful . 3 . SenML ( " ct " ) Field I wish the document has ABNF for the " ct " field . If you want to use ABNF from draft - bormann - core - media - content - type - format-01 , it should be Normative reference . If not , I think you should just cut & paste the ABNF into this document . Best Regards , Alexey
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 simplify processing of the data values this
document proposes to specify a new SenML field for indicating the
Content-Format of the data.
Paragraph (version A):
The Sensor Measurement Lists (SenML) media type RFC8428 can be used
to send various kinds of data.  In the example given in ex-1, a
temperature value, an indication whether a lock is open, and a data
value (with SenML field "vd") read from an NFC reader is sent in a
single SenML pack.
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 simplify processing of the data values,
this document proposes to specify a new SenML field for indicating
the Content-Format of the data.
Paragraph (version B):
The Sensor Measurement Lists (SenML) media types RFC8428 can be used
to send various kinds of data.  In the example given in ex-1, a
temperature value, an indication whether a lock is open, and a data
value (with SenML field "vd") read from an NFC reader is sent in a
single SenML pack.
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 (Section 12.3 in RFC7252) provides
just this information; enclosing a Content-Format number (in this
case number 60 as defined for content-type application/cbor in
RFC7049) in the Record is illustrated in ex-2.  All registered CoAP
Content-Formats are listed in the Content-Formats subregistry of the
CoRE Parameters registry IANA.core-parameters.
Paragraph (version A):
In this example SenML Record the data value contains a string "foo"
and a number 42 encoded in a CBOR RFC7049 array.  Since the example
above uses the JSON format of SenML, the data value containing the
binary CBOR value is base64-encoded.  The data value after base64
decoding is shown with CBOR diagnostic notation in ex-2-cbor.
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 content-coding right in the SenML
Record.  The CoAP Content-Format (RFC7252) provides just this
information; 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-Formats
are listed in the Content-Formats IANA.core-parameters of the CoRE
Parameters registry IANA.core-parameters.
Paragraph (version B):
In this example SenML Record, the data value contains a string "foo"
and a number 42 encoded in a CBOR RFC8949 array.  Since the example
above uses the JSON format of SenML, the data value containing the
binary CBOR value is base64-encoded (RFC4648).  The data value after
base64 decoding is shown with CBOR diagnostic notation in ex-2-cbor.
Paragraph (version A):
Readers should also be familiar with the terms and concepts discussed
in RFC8428.  Awareness of terminology issues discussed in I-
D.bormann-core-media-content-type-format can also be very helpful.
Paragraph (version A):
or a Content-Format-String I-D.bormann-core-media-content-type-
format containing a Content-Type and optionally a Content-Coding
(see below).
Paragraph (version A):
The CoAP Content-Format identifier 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 identifiers, 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):
To indicate that a Content-Coding is used with a Content-Type, the
Content-Coding value (e.g., "deflate" RFC7230) is appended to the
Content-Type value (media type and parameters, if any), separated by
a "@" sign.  For example: "text/plain; charset=utf-8@deflate".  If no
"@" sign is present outside the media type parameters, the Content-
Coding is not specified and the "identity" Content-Coding is used -
no encoding transformation is employed.
Paragraph (version B):
Readers should also be familiar with the terms and concepts discussed
in RFC8428.
Paragraph (version B):
or a Content-Format-String containing a Content-Type and
optionally a Content-Coding (see below).
Paragraph (version B):
The syntax of this field is formally defined in abnf.
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 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 B):
To indicate that a Content-Coding is used with a Content-Type, the
Content-Coding value (e.g., "deflate" RFC7230) is appended to the
Content-Type value (media type and parameters, if any), separated by
a "@" sign.  For example: "text/plain; charset=utf-8@deflate".  If no
"@" sign is present outside the media type parameters, the Content-
Coding is not specified and the "identity" Content-Coding is used --
no encoding transformation is employed.
Paragraph (version A):
The Base Content-Format Field, label "bct", provides a default value
for the Content-Format Field (label "ct") within its range.  The
range of the base field includes the Record containing it, up to (but
not including) the next Record containing a "bct" field, if any, or
up to the end of the pack otherwise.  Resolution (Section 4.6 of
RFC8428) of this base field is performed by adding its value with the
label "ct" to all Records in this range that carry a "vd" field but
do not already contain a Content-Format ("ct") field.
Paragraph (version B):
The Base Content-Format Field, label "bct", provides a default value
for the Content-Format Field (label "ct") within its range.  The
range of the base field includes the Record containing it, up to (but
not including) the next Record containing a "bct" field, if any, or
up to the end of the pack otherwise.  Resolution (RFC8428) of this
base field is performed by adding its value with the label "ct" to
all Records in this range that carry a "vd" field but do not already
contain a Content-Format ("ct") field.
Paragraph (version B):
This specification provides a formal definition of the syntax of
Content-Format-Spec strings using ABNF notation RFC5234, which
contains three new rules and a number of rules collected and adapted
from various RFCs RFC7231 RFC6838 RFC5234 RFC8866.