Sensor Measurement Lists (SenML) Fields for Indicating Data Value Content-Format
draft-ietf-core-senml-data-ct-07

[Ballot comment]
Thanks for the updates in the -06 and the discussion to get there.
I'm happy with where things ended up, and have just one comment
after reading the diff:

The ABNF comment for the "Cleaned up" entries currently says
"leaving the parameter as mandatory", which is only true in a
very specific sense; "leaving the parameter as mandatory within
the grouping" or "leaving the parameter as mandatory when the
separator is present" might be more clear to a reader not focusing
on the specific context of the statement.

[Ballot discuss]
This should be easy to resolve:

The SenML Labels registry specifies a column called "EXT ID" (or actually just "EI" in RFC 8428) that is absent from the registrations in Section 8.  If that column should be empty for these new registrations, that should be explicit rather than implicit.

[Ballot discuss]
I have a couple points for discussion, essentially relating to how much
we're diverging from HTTP and to what extent the specifics of the
divergence should be specifically mentioned in the document.

(1) I'd like to dig a little more into the analogy with HTTP and
whether we are artificially limiting ourselves: currently we only allow
0 or 1 content-codings to be specified, but per
https://www.ietf.org/archive/id/draft-ietf-httpbis-semantics-19.html#name-content-encoding
the HTTP ecosystem permits multiple codings to be applied in turn to the
same representation.  While the sensor data values are likely to be
relatively small and applying multiple content-codings is not likely to
be useful in such a scenario, this seems like something where we should
only consciously diverge from HTTP, rather than inadvertently doing so.

(2) Let's also discuss whether we want to reuse ABNF rule names from
HTTP while having the rule content diverge, without specific enumeration
of the divergence.  So far I found instances where this document does
not allow HTAB or obs-text in places that draft-ietf-httpbis-semantics
does, which may well be the right way to spell the rule, but seems to
merit a little discussion.

[Ballot comment]
Do we want to comment anywhere about the situation where an
implementation receives a message using an IANA-registered numeric
content-format that is "too new" for that implementation to know about?

It also feels a little weird that we have to end up using the
text-string encoding of a decimal number for the Content-Format, even
for the CBOR representation of SenML structures, but I guess that's what
RFC 8428 intended and not worth trying to change.

Abstract

I'm somewhat sympathetic to the gen-art reviewer's contention that the
new field is not indicating the "Content-Format" of the binary data
values (since Content-Format is a defined term in CoAP and SenML is
claimed to not be limited to CoAP usage).  Perhaps we could switch
around the order of description, i.e., "for indicating the Internet
media type (including parameters) of these binary data values (i.e., the
CoAP Content-Format that would apply when CoAp is used), as well as any
content-coding that is applied"?

Section 3

  *  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).

Should we also reference
https://datatracker.ietf.org/doc/html/rfc7252#section-7.2.1 which is
where the "ct" link attribute is actually defined?  I spent a bit of
time looking for it in 6690 itself only to discover that it was removed
in draft-ietf-core-link-format-07 with remark "Moved [...] to the base
CoAP specification".

  The CoAP Content-Format number provides a simple and efficient way to
  indicate the type of the data.  [...]

If we're limited to string representation, is it really "efficient" in a
CBOR context?

Section 6

  ; Cleaned up from RFC 7231:

(per the DISCUSS,) I'm a bit anti-enthused about saying "cleaned up" without saying what
changed (i.e., whether it's just refactoring, or actual changes to the
rule like requiring specifically *SP instead of OWS that allows HTAB as
well).

Section 7

These security considerations are well-thought-out and nicely written.
Thank you!

I think there are some (rare) situations where individual media-type
(specifications) have their own security considerations, but I'm not
really convinced that we need to mention that/incorporate them by
reference, here.

NITS

Section 1

  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.

I'd consider adding ", especially if the pack is propagated to multiple
entities".

Section 2

  Content-Coding:  A name registered in the HTTP Content Coding
      registry [IANA.http-parameters] as specified by Section 8.5 of
      [RFC7230], indicating an encoding transformation with semantics
      further specified in Section 3.1.2.1 of [RFC7231].  [...]

(I expect that the RFC Editor will be able to replace the references to
point to draft-ietf-httpb-semantics if it has been published before this
document.)

Section 4

  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.

The conjugation "resolution" does not actually appear in RFC 8428
itself, just discussion of "resolved records" and "to resolve the
records".  It might be helpful to tweak things so that we don't rely on
the reader knowing the irregular conjugation (but I don't have any good
ideas off the top of my head)...

[Ballot comment]
Thanks for this document.

I have to confess that I am less convinced of the need to have two ways to represent this information, i.e., to also support Content-Format-Strings as opposed to always requiring a entry in the CoAP Content-Formats registry.  The CoAP Content-Formats registry seems to be of reasonable size and have a lot of space available for FCFS allocations which would mean that it should be quite easy to extend if required.  However, I'm willing to defer to the authors & CORE WG expertise here supporting both ways are needed/useful.

Regards,
Rob

[Ballot comment]
The references to IANA registries could be informative, since RFC7252
is already normatively cited.

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 4. , paragraph 2, nit:
> t" fields (explanation/comments in parenthesis): * "60" (CoAP Content-Format
>                                ^^^^^^^^^^^^^^
Did you mean "in parentheses"? "parenthesis" is the singular.

These URLs in the document can probably be converted to HTTPS:
* http://www.iana.org/assignments/senml
* http://www.iana.org/assignments/core-parameters
* http://www.iana.org/assignments/http-parameters
* http://www.iana.org/assignments/media-types

[Ballot comment]
Is there any generic guidance to provide on expected error handling behavior if:

-- ct (or bct) contains a number outside of the 0-65535 range, or an unregistered value per the CoAP Content-Formats?

-- ct (or bct) contains a text value that is not a registered Content-Format-String?

-- ct (or bct) contains a valid Content-Format-String, but an unregistered  Content-Format?

Or is this application specific?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-core-senml-data-ct-04. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

Name: Base Content-Format
Label: bct
CBOR Label:
JSON Type: String
XML Type: String
EXI ID:
Reference: [ RFC-to-be ]
Note:

Name: Content-Format
Label: ct
CBOR Label:
JSON Type: String
XML Type: String
EXI ID:
Reference: [ RFC-to-be ]
Note:

IANA Question --> What should the entries be for CBOR Label and EXI ID for each of these new registrations?

As this document requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-09-06):

From: The IESG
To: IETF-Announce
CC: Jaime Jimenez , core-chairs@ietf.org, core@ietf.org, draft-ietf-core-senml-data-ct@ietf.org, francesca.palombini@ericsson.com, jaime@iki.fi
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (SenML Data Value Content-Format Indication) to Proposed Standard


The IESG has received a request from the Constrained RESTful Environments WG
(core) to consider the following document: - 'SenML Data Value Content-Format
Indication'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-09-06. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-core-senml-data-ct/



No IPR declarations have been submitted directly on this I-D.

### Summary

Document Shepherd: Jaime Jiménez
Area Director: Francesca Palombini

The document defines a new SenML field for indicating  the Content-Format of the data in order to facilitate automatic interpretation. Thus a new SenML field "ct" is created that ads the Content-Format information. A Base Content-Format field or "bct" is also defined when ct applies to all records.

The document also indicates that when content-coding is present, then instead of using the content-format identifier from IANA (integer value) the full content-type and content-coding are to be introduced in the ct field, appended by the "@" symbol. So, these two are valid ct fields:

"ct" = "60"
"ct" = "application/json@deflate"

The document is intended for Standards Track.

Version -04 includes required terminology (Media Type, Content-Type, etc) as well as the ABNF syntax of Content-Format-Spec.

### Review and Consensus

The document has been discussed on multiple IETF meetings and CoRE interim meetings, and has gone through multiple expert reviews.

The last version includes terminology information and the ABNF as requested on one of the reviews (https://github.com/core-wg/senml-data-ct/issues/2).

It was also decided to migrate the relevant terminology definitions from draft-bormann-core-media-content-type-format into the terminology section of this draft and to remove the normative reference to the previous document.

Consensus has been reached on the scope, content and level of detail of the document.

### Intellectual Property

Each author has stated that they do not have direct, personal knowledge of any IPR related to this document. I am not aware of any IPR discussion about this document on the CoRE WG.

### Other Points

The document registers:

* Two new labels for Base Content-Format (bct) and Content-Format (ct) are requested from IANA Senml Registry (http://www.iana.org/assignments/senml)

### Checklist

- [X] Does the shepherd stand behind the document and think the document is ready for publication?

- [X] Is the correct RFC type indicated in the title page header?

- [X] Is the abstract both brief and sufficient, and does it stand alone as a brief summary?

- [X] Is the intent of the document accurately and adequately explained in the introduction?

- [X] Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed?

- [X] Has the shepherd performed automated checks -- idnits (see http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests?
    - There were no errors but some minor stylistic warnings on the ABNF check.

- [X] Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79?

- [X] Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified?

- [X] Are all normative references made to documents that are ready for advancement and are otherwise in a clear state?

- [X] If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction?
'Does not apply'

- [X] If this is a "bis" document, have all of the errata been considered?
'Does not apply'

**IANA** Considerations:

- [X] Are the IANA Considerations clear and complete? Remember that IANA have to understand unambiguously what's being requested, so they can perform the required actions.
- [X] Are all protocol extensions that the document makes associated with the appropriate reservations in IANA registries?
- [X] Are all IANA registries referred to by their exact names (check them in http://www.iana.org/protocols/ to be sure)?
- [X] Have you checked that any registrations made by this document correctly follow the policies and procedures for the appropriate registries?
- [X] For registrations that require expert review (policies of Expert Review or Specification Required), have you or the working group had any early review done, to make sure the requests are ready for last call?
- [X] For any new registries that this document creates, has the working group actively chosen the allocation procedures and policies and discussed the alternatives?
'Does not apply'
- [X]  Have reasonable registry names been chosen (that will not be confused with those of other registries), and have the initial contents and valid value ranges been clearly specified?
'Does not apply'

### Summary

Document Shepherd: Jaime Jiménez
Area Director: Francesca Palombini

The document defines a new SenML field for indicating  the Content-Format of the data in order to facilitate automatic interpretation. Thus a new SenML field "ct" is created that ads the Content-Format information. A Base Content-Format field or "bct" is also defined when ct applies to all records.

The document also indicates that when content-coding is present, then instead of using the content-format identifier from IANA (integer value) the full content-type and content-coding are to be introduced in the ct field, appended by the "@" symbol. So, these two are valid ct fields:

"ct" = "60"
"ct" = "application/json@deflate"

The document is intended for Standards Track.

Version -04 includes required terminology (Media Type, Content-Type, etc) as well as the ABNF syntax of Content-Format-Spec.

### Review and Consensus

The document has been discussed on multiple IETF meetings and CoRE interim meetings, and has gone through multiple expert reviews.

The last version includes terminology information and the ABNF as requested on one of the reviews (https://github.com/core-wg/senml-data-ct/issues/2).

It was also decided to migrate the relevant terminology definitions from draft-bormann-core-media-content-type-format into the terminology section of this draft and to remove the normative reference to the previous document.

Consensus has been reached on the scope, content and level of detail of the document.

### Intellectual Property

Each author has stated that they do not have direct, personal knowledge of any IPR related to this document. I am not aware of any IPR discussion about this document on the CoRE WG.

### Other Points

The document registers:

* Two new labels for Base Content-Format (bct) and Content-Format (ct) are requested from IANA Senml Registry (http://www.iana.org/assignments/senml)

### Checklist

- [X] Does the shepherd stand behind the document and think the document is ready for publication?

- [X] Is the correct RFC type indicated in the title page header?

- [X] Is the abstract both brief and sufficient, and does it stand alone as a brief summary?

- [X] Is the intent of the document accurately and adequately explained in the introduction?

- [X] Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed?

- [X] Has the shepherd performed automated checks -- idnits (see http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests?
    - There were no errors but some minor stylistic warnings on the ABNF check.

- [X] Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79?

- [X] Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified?

- [X] Are all normative references made to documents that are ready for advancement and are otherwise in a clear state?

- [X] If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction?
'Does not apply'

- [X] If this is a "bis" document, have all of the errata been considered?
'Does not apply'

**IANA** Considerations:

- [X] Are the IANA Considerations clear and complete? Remember that IANA have to understand unambiguously what's being requested, so they can perform the required actions.
- [X] Are all protocol extensions that the document makes associated with the appropriate reservations in IANA registries?
- [X] Are all IANA registries referred to by their exact names (check them in http://www.iana.org/protocols/ to be sure)?
- [X] Have you checked that any registrations made by this document correctly follow the policies and procedures for the appropriate registries?
- [X] For registrations that require expert review (policies of Expert Review or Specification Required), have you or the working group had any early review done, to make sure the requests are ready for last call?
- [X] For any new registries that this document creates, has the working group actively chosen the allocation procedures and policies and discussed the alternatives?
'Does not apply'
- [X]  Have reasonable registry names been chosen (that will not be confused with those of other registries), and have the initial contents and valid value ranges been clearly specified?
'Does not apply'

### Summary

Document Shepherd: Jaime Jiménez
Area Director: Francesca Palombini

The document defines a new SenML field for indicating  the Content-Format of the data in order to facilitate automatic interpretation. Thus a new SenML field "ct" is created that ads the Content-Format information. A Base Content-Format field or "bct" is also defined when ct applies to all records.

The document also indicates that when content-coding is present, then instead of using the content-format identifier from IANA (integer value) the full content-type and content-coding are to be introduced in the ct field, appended by the "@" symbol. So, these two are valid ct fields:

"ct" = "60"
"ct" = "application/json@deflate"

The document is intended for Standards Track.

Version -04 includes required terminology (Media Type, Content-Type, etc) as well as the ABNF syntax of Content-Format-Spec.

### Review and Consensus

The document has been discussed on multiple IETF meetings and CoRE interim meetings, and has gone through multiple expert reviews.

The last version includes terminology information and the ABNF as requested on one of the reviews (https://github.com/core-wg/senml-data-ct/issues/2).

It was also decided to migrate the relevant terminology definitions from draft-bormann-core-media-content-type-format into the terminology section of this draft and to remove the normative reference to the previous document.

Consensus has been reached on the scope, content and level of detail of the document.

### Intellectual Property

Each author has stated that they do not have direct, personal knowledge of any IPR related to this document. I am not aware of any IPR discussion about this document on the CoRE WG.

### Other Points

The document registers:

* Two new labels for Base Content-Format (bct) and Content-Format (ct) are requested from IANA Senml Registry (http://www.iana.org/assignments/senml)

### Checklist

- [X] Does the shepherd stand behind the document and think the document is ready for publication?

- [X] Is the correct RFC type indicated in the title page header?

- [X] Is the abstract both brief and sufficient, and does it stand alone as a brief summary?

- [X] Is the intent of the document accurately and adequately explained in the introduction?

- [X] Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed?

- [X] Has the shepherd performed automated checks -- idnits (see http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests?
    - There were no errors but some minor stylistic warnings on the ABNF check.

- [ ] Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79?
    - One of the authors is currently on vacation, we are waiting for a reply.

- [X] Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified?

- [X] Are all normative references made to documents that are ready for advancement and are otherwise in a clear state?

- [X] If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction?
'Does not apply'

- [X] If this is a "bis" document, have all of the errata been considered?
'Does not apply'

**IANA** Considerations:

- [X] Are the IANA Considerations clear and complete? Remember that IANA have to understand unambiguously what's being requested, so they can perform the required actions.
- [X] Are all protocol extensions that the document makes associated with the appropriate reservations in IANA registries?
- [X] Are all IANA registries referred to by their exact names (check them in http://www.iana.org/protocols/ to be sure)?
- [X] Have you checked that any registrations made by this document correctly follow the policies and procedures for the appropriate registries?
- [X] For registrations that require expert review (policies of Expert Review or Specification Required), have you or the working group had any early review done, to make sure the requests are ready for last call?
- [X] For any new registries that this document creates, has the working group actively chosen the allocation procedures and policies and discussed the alternatives?
'Does not apply'
- [X]  Have reasonable registry names been chosen (that will not be confused with those of other registries), and have the initial contents and valid value ranges been clearly specified?
'Does not apply'

### Summary

Document Shepherd: Jaime Jiménez
Area Director: Francesca Palombini

The document defines a new SenML field for indicating  the Content-Format of the data in order to facilitate automatic interpretation. Thus a new SenML field "ct" is created that ads the Content-Format information. A Base Content-Format field or "bct" is also defined when ct applies to all records.

The document also indicates that when content-coding is present, then instead of using the content-format identifier from IANA (integer value) the full content-type and content-coding are to be introduced in the ct field, appended by the "@" symbol. So, these two are valid ct fields:

"ct" = "60"
"ct" = "application/json@deflate"

The document is intended for Standards Track.

Version -04 includes hypermedia terminology (Media Type, Content-Type, etc) as well as the ABNF syntax of Content-Format-Spec.

### Review and Consensus

The document has been discussed on multiple IETF meetings and CoRE interim meetings, and has gone through multiple expert reviews.

The last version includes terminology information and the ABNF as requested on one of the reviews (https://github.com/core-wg/senml-data-ct/issues/2).

It was also decided to migrate the relevant terminology definitions from draft-bormann-core-media-content-type-format into the terminology section of this draft and to remove the normative reference to the previous document.

Consensus has been reached on the scope, content and level of detail of the document.

### Intellectual Property

Each author has stated that they do not have direct, personal knowledge of any IPR related to this document. I am not aware of any IPR discussion about this document on the CoRE WG.

### Other Points

The document registers:

* Two new labels for Base Content-Format (bct) and Content-Format (ct) are requested from IANA Senml Registry (http://www.iana.org/assignments/senml)

### Checklist

- [X] Does the shepherd stand behind the document and think the document is ready for publication?

- [X] Is the correct RFC type indicated in the title page header?

- [X] Is the abstract both brief and sufficient, and does it stand alone as a brief summary?

- [X] Is the intent of the document accurately and adequately explained in the introduction?

- [X] Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed?

- [X] Has the shepherd performed automated checks -- idnits (see http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests?
    - There were no errors but some minor stylistic warnings on the ABNF check.

- [ ] Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79?
    - One of the authors is currently on vacation, we are waiting for a reply.

- [X] Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified?

- [X] Are all normative references made to documents that are ready for advancement and are otherwise in a clear state?

- [X] If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction?
'Does not apply'

- [X] If this is a "bis" document, have all of the errata been considered?
'Does not apply'

**IANA** Considerations:

- [X] Are the IANA Considerations clear and complete? Remember that IANA have to understand unambiguously what's being requested, so they can perform the required actions.
- [X] Are all protocol extensions that the document makes associated with the appropriate reservations in IANA registries?
- [X] Are all IANA registries referred to by their exact names (check them in http://www.iana.org/protocols/ to be sure)?
- [X] Have you checked that any registrations made by this document correctly follow the policies and procedures for the appropriate registries?
- [X] For registrations that require expert review (policies of Expert Review or Specification Required), have you or the working group had any early review done, to make sure the requests are ready for last call?
- [X] For any new registries that this document creates, has the working group actively chosen the allocation procedures and policies and discussed the alternatives?
'Does not apply'
- [X]  Have reasonable registry names been chosen (that will not be confused with those of other registries), and have the initial contents and valid value ranges been clearly specified?
'Does not apply'

### Summary

Document Shepherd: Jaime Jiménez
Area Director: Francesca Palombini

The document defines a new SenML field for indicating  the Content-Format of the data in order to facilitate automatic interpretation. Thus a new SenML field "ct" is created that ads the Content-Format information. A Base Content-Format field or "bct" is also defined when ct applies to all records.

The document also indicates that when content-coding is present, then instead of using the content-format identifier from IANA (integer value) the full content-type and content-coding are to be introduced in the ct field, appended by the "@" symbol. So, these two are valid ct fields:

"ct" = "60"
"ct" = "application/json@deflate"

The document is intended for Standards Track.

Version -04 includes hypermedia terminology (Media Type, Content-Type, etc) as well as the ABNF syntax of Content-Format-Spec.

### Review and Consensus

The document has been discussed on multiple IETF meetings and CoRE interim meetings, and has gone through multiple expert reviews.

The last version includes terminology information and the ABNF as requested on one of the reviews (https://github.com/core-wg/senml-data-ct/issues/2).

It was also decided to migrate the relevant terminology definitions from draft-bormann-core-media-content-type-format into the terminology section of this draft and to remove the normative reference to the previous document.

Consensus has been reached on the scope, content and level of detail of the document.

### Intellectual Property

Each author has stated that they do not have direct, personal knowledge of any IPR related to this document. I am not aware of any IPR discussion about this document on the CoRE WG.

### Other Points

The document registers:

* Two new labels for Base Content-Format (bct) and Content-Format (ct) are requested from IANA Senml Registry (http://www.iana.org/assignments/senml)

### Checklist

- [X] Does the shepherd stand behind the document and think the document is ready for publication?

- [X] Is the correct RFC type indicated in the title page header?

- [X] Is the abstract both brief and sufficient, and does it stand alone as a brief summary?

- [X] Is the intent of the document accurately and adequately explained in the introduction?

- [X] Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed?

- [X] Has the shepherd performed automated checks -- idnits (see http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests?
    - There were no errors but some warnings on the ABNF check.

- [ ] Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79?
    - One of the authors is currently on vacation, we are waiting for a reply.

- [X] Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified?

- [X] Are all normative references made to documents that are ready for advancement and are otherwise in a clear state?

- [X] If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction?
'Does not apply'

- [X] If this is a "bis" document, have all of the errata been considered?
'Does not apply'

**IANA** Considerations:

- [X] Are the IANA Considerations clear and complete? Remember that IANA have to understand unambiguously what's being requested, so they can perform the required actions.
- [X] Are all protocol extensions that the document makes associated with the appropriate reservations in IANA registries?
- [X] Are all IANA registries referred to by their exact names (check them in http://www.iana.org/protocols/ to be sure)?
- [X] Have you checked that any registrations made by this document correctly follow the policies and procedures for the appropriate registries?
- [X] For registrations that require expert review (policies of Expert Review or Specification Required), have you or the working group had any early review done, to make sure the requests are ready for last call?
- [X] For any new registries that this document creates, has the working group actively chosen the allocation procedures and policies and discussed the alternatives?
'Does not apply'
- [X]  Have reasonable registry names been chosen (that will not be confused with those of other registries), and have the initial contents and valid value ranges been clearly specified?
'Does not apply'