Sensor Measurement Lists (SenML) Fields for Indicating Data Value Content-Format
draft-ietf-core-senml-data-ct-07
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2024-01-26
|
07 | Gunter Van de Velde | Request closed, assignment withdrawn: Niclas Comstedt Last Call OPSDIR review |
2024-01-26
|
07 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue |
2022-02-23
|
07 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2022-02-01
|
07 | (System) | RFC Editor state changed to AUTH48 |
2021-12-15
|
07 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2021-10-25
|
07 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2021-10-25
|
07 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2021-10-25
|
07 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2021-10-25
|
07 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2021-10-23
|
07 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'Overtaken by Events' |
2021-10-23
|
07 | Tero Kivinen | Assignment of request for Last Call review by SECDIR to John Bradley was marked no-response |
2021-10-22
|
07 | (System) | RFC Editor state changed to EDIT |
2021-10-22
|
07 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2021-10-22
|
07 | (System) | Announcement was received by RFC Editor |
2021-10-22
|
07 | (System) | IANA Action state changed to In Progress |
2021-10-22
|
07 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2021-10-22
|
07 | Amy Vezza | IESG has approved the document |
2021-10-22
|
07 | Amy Vezza | Closed "Approve" ballot |
2021-10-22
|
07 | Amy Vezza | Ballot approval text was generated |
2021-10-22
|
07 | (System) | Removed all action holders (IESG state changed) |
2021-10-22
|
07 | Francesca Palombini | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2021-10-21
|
07 | Carsten Bormann | New version available: draft-ietf-core-senml-data-ct-07.txt |
2021-10-21
|
07 | (System) | New version accepted (logged-in submitter: Carsten Bormann) |
2021-10-21
|
07 | Carsten Bormann | Uploaded new revision |
2021-10-21
|
06 | Murray Kucherawy | [Ballot Position Update] Position for Murray Kucherawy has been changed to No Objection from Discuss |
2021-10-13
|
06 | Benjamin Kaduk | [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 … [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. |
2021-10-13
|
06 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2021-10-13
|
06 | (System) | Changed action holders to Francesca Palombini (IESG state changed) |
2021-10-13
|
06 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2021-10-13
|
06 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2021-10-13
|
06 | Carsten Bormann | New version available: draft-ietf-core-senml-data-ct-06.txt |
2021-10-13
|
06 | (System) | New version accepted (logged-in submitter: Carsten Bormann) |
2021-10-13
|
06 | Carsten Bormann | Uploaded new revision |
2021-10-13
|
05 | Marco Tiloca | Added to session: interim-2021-core-12 |
2021-09-23
|
05 | (System) | Changed action holders to Carsten Bormann, Ari Keränen, Francesca Palombini (IESG state changed) |
2021-09-23
|
05 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2021-09-22
|
05 | Murray Kucherawy | [Ballot comment] Thanks to Bron Gondwana for the ARTART review. |
2021-09-22
|
05 | Murray Kucherawy | Ballot comment text updated for Murray Kucherawy |
2021-09-22
|
05 | Murray Kucherawy | [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 … [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. |
2021-09-22
|
05 | Murray Kucherawy | [Ballot Position Update] New position, Discuss, has been recorded for Murray Kucherawy |
2021-09-22
|
05 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2021-09-22
|
05 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2021-09-22
|
05 | Benjamin Kaduk | [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 … [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. |
2021-09-22
|
05 | Benjamin Kaduk | [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 … [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)... |
2021-09-22
|
05 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2021-09-21
|
05 | John Scudder | [Ballot Position Update] New position, No Objection, has been recorded for John Scudder |
2021-09-21
|
05 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2021-09-21
|
05 | Robert Wilton | [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 … [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 |
2021-09-21
|
05 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2021-09-20
|
05 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2021-09-20
|
05 | Lars Eggert | [Ballot comment] The references to IANA registries could be informative, since RFC7252 is already normatively cited. ------------------------------------------------------------------------------- All comments below are about very minor potential … [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 |
2021-09-20
|
05 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert |
2021-09-18
|
05 | Roman Danyliw | [Ballot comment] Is there any generic guidance to provide on expected error handling behavior if: -- ct (or bct) contains a number outside of the … [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? |
2021-09-18
|
05 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2021-09-17
|
05 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2021-09-16
|
05 | Amy Vezza | Placed on agenda for telechat - 2021-09-23 |
2021-09-15
|
05 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2021-09-15
|
05 | Francesca Palombini | Ballot has been issued |
2021-09-15
|
05 | Francesca Palombini | [Ballot Position Update] New position, Yes, has been recorded for Francesca Palombini |
2021-09-15
|
05 | Francesca Palombini | Created "Approve" ballot |
2021-09-15
|
05 | Francesca Palombini | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup |
2021-09-15
|
05 | (System) | Changed action holders to Francesca Palombini (IESG state changed) |
2021-09-15
|
05 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2021-09-15
|
05 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2021-09-15
|
05 | Carsten Bormann | New version available: draft-ietf-core-senml-data-ct-05.txt |
2021-09-15
|
05 | (System) | New version accepted (logged-in submitter: Carsten Bormann) |
2021-09-15
|
05 | Carsten Bormann | Uploaded new revision |
2021-09-07
|
04 | Sabrina Tanamal | IANA Experts State changed to Expert Reviews OK from Reviews assigned |
2021-09-06
|
04 | (System) | Changed action holders to Carsten Bormann, Ari Keränen, Francesca Palombini (IESG state changed) |
2021-09-06
|
04 | Francesca Palombini | IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead |
2021-09-06
|
04 | Christer Holmberg | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Christer Holmberg. Sent review to list. |
2021-09-06
|
04 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2021-09-03
|
04 | Sabrina Tanamal | IANA Experts State changed to Reviews assigned |
2021-09-03
|
04 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2021-09-03
|
04 | Sabrina Tanamal | (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 … (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 |
2021-08-30
|
04 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Niclas Comstedt |
2021-08-30
|
04 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Niclas Comstedt |
2021-08-26
|
04 | Jean Mahoney | Request for Last Call review by GENART is assigned to Christer Holmberg |
2021-08-26
|
04 | Jean Mahoney | Request for Last Call review by GENART is assigned to Christer Holmberg |
2021-08-26
|
04 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to John Bradley |
2021-08-26
|
04 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to John Bradley |
2021-08-25
|
04 | Bron Gondwana | Request for Last Call review by ARTART Completed: Ready with Nits. Reviewer: Bron Gondwana. Sent review to list. |
2021-08-24
|
04 | Barry Leiba | Request for Last Call review by ARTART is assigned to Bron Gondwana |
2021-08-24
|
04 | Barry Leiba | Request for Last Call review by ARTART is assigned to Bron Gondwana |
2021-08-23
|
04 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2021-08-23
|
04 | Cindy Morgan | 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, … 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. |
2021-08-23
|
04 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2021-08-23
|
04 | Francesca Palombini | Last call was requested |
2021-08-23
|
04 | Francesca Palombini | Last call announcement was generated |
2021-08-23
|
04 | Francesca Palombini | Ballot approval text was generated |
2021-08-23
|
04 | Francesca Palombini | IESG state changed to Last Call Requested from AD Evaluation |
2021-07-21
|
04 | (System) | Changed action holders to Francesca Palombini (IESG state changed) |
2021-07-21
|
04 | Francesca Palombini | IESG state changed to AD Evaluation from Publication Requested |
2021-07-21
|
04 | Francesca Palombini | Ballot writeup was changed |
2021-07-12
|
04 | Jenny Bui | Changed consensus to Yes from Unknown |
2021-07-12
|
04 | Jenny Bui | Intended Status changed to Proposed Standard from None |
2021-07-12
|
04 | Jaime Jimenez | ### 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 … ### 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' |
2021-07-12
|
04 | Jaime Jimenez | Responsible AD changed to Francesca Palombini |
2021-07-12
|
04 | Jaime Jimenez | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2021-07-12
|
04 | Jaime Jimenez | IESG state changed to Publication Requested from I-D Exists |
2021-07-12
|
04 | Jaime Jimenez | IESG process started in state Publication Requested |
2021-07-12
|
04 | Jaime Jimenez | ### 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 … ### 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' |
2021-07-12
|
04 | Jaime Jimenez | ### 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 … ### 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' |
2021-07-12
|
04 | Jaime Jimenez | ### 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 … ### 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' |
2021-07-12
|
04 | Jaime Jimenez | Waiting for few nits and comments from authors. |
2021-07-12
|
04 | Jaime Jimenez | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2021-07-12
|
04 | Jaime Jimenez | ### 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 … ### 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' |
2021-07-08
|
04 | Carsten Bormann | New version available: draft-ietf-core-senml-data-ct-04.txt |
2021-07-08
|
04 | (System) | New version accepted (logged-in submitter: Carsten Bormann) |
2021-07-08
|
04 | Carsten Bormann | Uploaded new revision |
2021-07-05
|
03 | Marco Tiloca | Added to session: interim-2021-core-09 |
2021-02-27
|
03 | Marco Tiloca | Added to session: IETF-110: core Fri-1300 |
2021-01-15
|
03 | Carsten Bormann | New version available: draft-ietf-core-senml-data-ct-03.txt |
2021-01-15
|
03 | (System) | New version accepted (logged-in submitter: Carsten Bormann) |
2021-01-15
|
03 | Carsten Bormann | Uploaded new revision |
2021-01-14
|
02 | (System) | Document has expired |
2020-11-14
|
02 | Marco Tiloca | Added to session: IETF-109: core Fri-1600 |
2020-09-10
|
02 | Marco Tiloca | Changed document external resources from: [] to: github_repo https://github.com/core-wg/senml-data-ct (Working Group Repo) |
2020-08-17
|
02 | Jaime Jimenez | Notification list changed to Jaime Jimenez <jaime@iki.fi> |
2020-08-17
|
02 | Jaime Jimenez | Document shepherd changed to Jaime Jimenez |
2020-08-17
|
02 | Jaime Jimenez | IETF WG state changed to WG Document from In WG Last Call |
2020-07-30
|
02 | Marco Tiloca | IETF WG state changed to In WG Last Call from WG Document |
2020-07-25
|
02 | Marco Tiloca | Added to session: IETF-108: core Tue-1410 |
2020-07-13
|
02 | Carsten Bormann | New version available: draft-ietf-core-senml-data-ct-02.txt |
2020-07-13
|
02 | (System) | New version accepted (logged-in submitter: Carsten Bormann) |
2020-07-13
|
02 | Carsten Bormann | Uploaded new revision |
2020-05-07
|
01 | (System) | Document has expired |
2019-11-04
|
01 | Ari Keränen | New version available: draft-ietf-core-senml-data-ct-01.txt |
2019-11-04
|
01 | (System) | New version accepted (logged-in submitter: Ari Keränen) |
2019-11-04
|
01 | Ari Keränen | Uploaded new revision |
2019-08-29
|
00 | Jaime Jimenez | This document now replaces draft-keranen-core-senml-data-ct instead of None |
2019-08-29
|
00 | Ari Keränen | New version available: draft-ietf-core-senml-data-ct-00.txt |
2019-08-29
|
00 | (System) | WG -00 approved |
2019-08-29
|
00 | Ari Keränen | Set submitter to "Ari Keranen ", replaces to draft-keranen-core-senml-data-ct and sent approval email to group chairs: core-chairs@ietf.org |
2019-08-29
|
00 | Ari Keränen | Uploaded new revision |