Representing Constrained RESTful Environments (CoRE) Link Format in JSON and CBOR
draft-ietf-core-links-json-10
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2018-10-13
|
10 | (System) | Document has expired |
2018-10-13
|
10 | (System) | IESG state changed to Dead from AD is watching::Revised I-D Needed |
2018-10-12
|
10 | Alexey Melnikov | IESG state changed to AD is watching::Revised I-D Needed from Waiting for AD Go-Ahead::Revised I-D Needed |
2018-04-23
|
10 | Alexey Melnikov | IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from IESG Evaluation::AD Followup |
2018-02-26
|
10 | Carsten Bormann | New version available: draft-ietf-core-links-json-10.txt |
2018-02-26
|
10 | (System) | New version approved |
2018-02-26
|
10 | (System) | Request for posting confirmation emailed to previous authors: core-chairs@ietf.org, Kepeng Li , Akbar Rahman , Carsten Bormann |
2018-02-26
|
10 | Carsten Bormann | Uploaded new revision |
2017-07-03
|
09 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2017-07-03
|
09 | Carsten Bormann | New version available: draft-ietf-core-links-json-09.txt |
2017-07-03
|
09 | (System) | New version approved |
2017-07-03
|
09 | (System) | Request for posting confirmation emailed to previous authors: Carsten Bormann , Kepeng Li , core-chairs@ietf.org, Akbar Rahman |
2017-07-03
|
09 | Carsten Bormann | Uploaded new revision |
2017-05-22
|
08 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'No Response' |
2017-04-27
|
08 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2017-04-27
|
08 | Adam Roach | [Ballot discuss] ====================================================================== The protocol has technical flaws that will prevent it from working properly, or the description is unclear in such a way that … [Ballot discuss] ====================================================================== The protocol has technical flaws that will prevent it from working properly, or the description is unclear in such a way that the reader cannot understand it without ambiguity. ====================================================================== The document requires that the thirteen defined values MUST be encoded as integers. The document does not define what implementations are to do if they receive a CBOR object that does not conform to this encoding: is the parameter ignored? Is the entire link relation ignored? Do you reject the entire collection of link relations? Or do you just go ahead and parse it anyway, since the intended meaning is unambiguous (even if out of spec)? ====================================================================== The draft omits a normative reference necessary for its implementation, or cites such a reference merely informatively rather than normatively. ====================================================================== ISSUE 1: This document appears to use CDDL to define the formal schema for both the JSON and CBOR representations of its data format, although the CDDL document itself is cited only informatively. ISSUE 2: figure 1 shows an application of CDDL to define schema for JSON. It's not clear from a skim through the CDDL document that it can be used for JSON; it would appear that using it in this fashion would require additional text in this document to talk about how to apply CDDL to JSON, or waiting for some other document to do so. |
2017-04-27
|
08 | Adam Roach | Ballot discuss text updated for Adam Roach |
2017-04-27
|
08 | Adam Roach | [Ballot discuss] ====================================================================== The protocol has technical flaws that will prevent it from working properly, or the description is unclear in such a way that … [Ballot discuss] ====================================================================== The protocol has technical flaws that will prevent it from working properly, or the description is unclear in such a way that the reader cannot understand it without ambiguity. ====================================================================== The document requires that the thirteen defined values MUST be encoded as integers. The document does not define what implementations are to do if they receive a CBOR object that does not conform to this encoding: is the parameter ignored? Is the entire link relation ignored? Do you reject the entire collection of link relations? Or do you just go ahead and parse it anyway, since the intended meaning is unambiguous (even if out of spec)? ====================================================================== The draft omits a normative reference necessary for its implementation, or cites such a reference merely informatively rather than normatively. ====================================================================== This document appears to use CDDL to define the formal schema for both the JSON and CBOR representations of its data format, although the CDDL document itself is cited only informatively. Additionally , figure 1 shows an application of CDDL to define schema for JSON. It's not clear from a skim through the CDDL document that it can be used for JSON; it would appear that using it in this fashion would require additional text in this document to talk about how to apply CDDL to JSON, or waiting for some other document to do so. |
2017-04-27
|
08 | Adam Roach | [Ballot comment] The example in Figure 6 would benefit greatly by showing both the array encoding and "foo" encoding used in Figure 4 (including, in … [Ballot comment] The example in Figure 6 would benefit greatly by showing both the array encoding and "foo" encoding used in Figure 4 (including, in particular, the string -- rather than integer -- encoding of the "foo=3" parameter). |
2017-04-27
|
08 | Adam Roach | Ballot comment and discuss text updated for Adam Roach |
2017-04-27
|
08 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2017-04-27
|
08 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2017-04-27
|
08 | Alexey Melnikov | [Ballot discuss] A few sentences to address Mark's ARTART Directorate review would be helpful as well. -- this might have been fixed. |
2017-04-27
|
08 | Alexey Melnikov | Ballot discuss text updated for Alexey Melnikov |
2017-04-27
|
08 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2017-04-27
|
08 | Carsten Bormann | New version available: draft-ietf-core-links-json-08.txt |
2017-04-27
|
08 | (System) | New version approved |
2017-04-27
|
08 | (System) | Request for posting confirmation emailed to previous authors: Carsten Bormann , Kepeng Li , core-chairs@ietf.org, Akbar Rahman |
2017-04-27
|
08 | Carsten Bormann | Uploaded new revision |
2017-04-27
|
07 | Alexey Melnikov | [Ballot discuss] Section 3.2 has cut & paste error that needs to be fixed. A few sentences to address Mark's ARTART Directorate review would be … [Ballot discuss] Section 3.2 has cut & paste error that needs to be fixed. A few sentences to address Mark's ARTART Directorate review would be helpful as well. Also, please address Alia's comment. |
2017-04-27
|
07 | Alexey Melnikov | [Ballot Position Update] Position for Alexey Melnikov has been changed to Discuss from Yes |
2017-04-26
|
07 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2017-04-26
|
07 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2017-04-26
|
07 | Alia Atlas | [Ballot comment] I did notice that " (Comment to be deleted before submitting this document to the IESG: This list should, again, be checked … [Ballot comment] I did notice that " (Comment to be deleted before submitting this document to the IESG: This list should, again, be checked against relevant references at WGLC time.)" under Table 1 wasn't, in fact, deleted. Has the relevant check been made? |
2017-04-26
|
07 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2017-04-26
|
07 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2017-04-26
|
07 | Alissa Cooper | [Ballot discuss] I'd like to see the major issue raised by Elwyn in his Gen-ART review resolved before this document proceeds: https://datatracker.ietf.org/doc/review-ietf-core-links-json-07-genart-lc-davies-2017-04-25/ |
2017-04-26
|
07 | Alissa Cooper | [Ballot comment] Elwyn's review contains a number of minor issues on which the authors are already engaging (thanks!). https://datatracker.ietf.org/doc/review-ietf-core-links-json-07-genart-lc-davies-2017-04-25/ |
2017-04-26
|
07 | Alissa Cooper | [Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper |
2017-04-25
|
07 | Ben Campbell | [Ballot comment] On a quick email scan, I gather that the discussion thread resulting from Mark's ART-ART review has not completely resolved, at least as … [Ballot comment] On a quick email scan, I gather that the discussion thread resulting from Mark's ART-ART review has not completely resolved, at least as of the time I reviewed the document. That probably needs to be resolved prior to progressing the draft. |
2017-04-25
|
07 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2017-04-25
|
07 | Elwyn Davies | Request for Last Call review by GENART Completed: Not Ready. Reviewer: Elwyn Davies. Sent review to list. |
2017-04-25
|
07 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2017-04-24
|
07 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2017-04-24
|
07 | Eric Rescorla | [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla |
2017-04-24
|
07 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2017-04-24
|
07 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2017-04-24
|
07 | Alexey Melnikov | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2017-04-24
|
07 | Alexey Melnikov | Ballot writeup was changed |
2017-04-21
|
07 | Paul Wouters | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Paul Wouters. Sent review to list. |
2017-04-21
|
07 | Adam Roach | [Ballot discuss] - The protocol has technical flaws that will prevent it from working properly, or the description is unclear in such a way that … [Ballot discuss] - The protocol has technical flaws that will prevent it from working properly, or the description is unclear in such a way that the reader cannot understand it without ambiguity. Ambiguity 1: Section 1.1 describes "round-tripping" between 6690 format and JSON/CBOR; however, the document describes the transform in one direction, leaving the other implicit. The non-normative code in Appendix A shows a conversion into link relation format, but it makes certain assumptions about the syntax of link relation parameters that, while possibly true today, are not guaranteed to hold true in the future. As defined in this document, the transform requires parameter-specific syntax knowledge of each link relation parameter that it will transform. The problem this causes is probably best demonstrated with an example. Let's say some future document defined a link relation ("smellslike") that included a parameter with ABNF syntax like: "smellsys" "=" quoted-string Now, if we were to apply the transform in this document to the following link relation: ;smellsys="h9341";rel="smellslike" We get: [{"href":"/smellr2", "smellsys":"h9341","rel":"smellslike"}] Applying the logic that is implicit in the document and explicit (if non-normative) in Appendix A, converting this back into a link relation yields: ;smellsys=h9341;rel=smellslike Note the stripping of double quotes from the parameter values. This is fine for "rel", whose ABNF syntax allows for the presence or absence of quotes -- but the emitted syntax for "smellsys" is actually in violation of its defined ABNF. This needs to be addressed by either indicating that conversion into link relations requires that the conversion routine has explicit knowledge of the syntax for each parameter it converts (and must fail to convert parameters it does not understand), *or* the JSON and CBOR representations need some additional indication that preserves knowledge of whether the indicated value is required to be quoted when converted to a link relation. If the first path is taken, the associated Ruby code needs to be updated accordingly. Ambiguity 2: The document requires that the thirteen defined values MUST be encoded as integers. The document does not define what implementations are to do if they receive a CBOR object that does not conform to this encoding: is the parameter ignored? Is the entire link relation ignored? Do you reject the entire collection of link relations? Or do you just go ahead and parse it anyway, since the intended meaning is unambiguous (even if out of spec)? - The draft omits a normative reference necessary for its implementation, or cites such a reference merely informatively rather than normatively. This document appears to use CDDL to define the formal schema for both the JSON and CBOR representations of its data format, although the CDDL document itself is cited only informatively. Additionally , figure 1 shows an application of CDDL to define schema for JSON. It's not clear from a skim through the CDDL document that it can be used for JSON; it would appear that using it in this fashion would require additional text in this document to talk about how to apply CDDL to JSON, or waiting for some other document to do so. |
2017-04-21
|
07 | Adam Roach | Ballot discuss text updated for Adam Roach |
2017-04-21
|
07 | Adam Roach | [Ballot discuss] - The protocol has technical flaws that will prevent it from working properly, or the description is unclear in such a way that … [Ballot discuss] - The protocol has technical flaws that will prevent it from working properly, or the description is unclear in such a way that the reader cannot understand it without ambiguity. Ambiguity 1: Section 1.1 describes "round-tripping" between 6690 format and JSON/CBOR; however, the document describes the transform in one direction, leaving the other implicit. The non-normative code in Appendix A shows a conversion into link relation format, but it makes certain assumptions about the syntax of link relation parameters that, while possibly true today, are not guaranteed to hold true in the future. As defined in this document, the transform requires parameter-specific syntax knowledge of each link relation parameter that it will transform. The problem this causes is probably best demonstrated with an example. Let's say some future document defined a link relation ("smellslike") that included a parameter with ABNF syntax like: "smellsys" "=" quoted-string Now, if we were to apply the transform in this document to the following link relation: ;smellsys="h9341";rel="smellslike" We get: [{"href":"/smellr2", "smellsys":"h9341","rel":"smellslike"}] Applying the logic that is implicit in the document and explicit (if non-normative) in Appendix A, converting this back into a link relation yields: ;smellsys=h9341;rel=smellslike Note the stripping of double quotes from the parameter values. This is fine for "rel", whose ABNF syntax allows for the presence or absence of quotes -- but the emitted syntax for "smellsys" is actually in violation of its defined ABNF. This needs to be addressed by either indicating that conversion into link relations requires that the conversion routine has explicit knowledge of the syntax for each parameter it converts (and must fail to convert parameters it does not understand), *or* the JSON and CBOR representations need some additional indication that preserves knowledge of whether the indicated value is required to be quoted when converted to a link relation. If the first path is taken, the associated Ruby code needs to be updated accordingly. Ambiguity 2: The document requires that the thirteen defined values MUST be encoded as integers. The document does not define what implementations are to do if they receive a CBOR object that does not conform to this encoding: is the parameter ignored? Is the entire link relation ignored? Do you reject the entire collection of link relations? Or do you just go ahead and parse it anyway, since the intended meaning is ambiguous (even if out of spec)? - The draft omits a normative reference necessary for its implementation, or cites such a reference merely informatively rather than normatively. This document appears to use CDDL to define the formal schema for both the JSON and CBOR representations of its data format, although the CDDL document itself is cited only informatively. Additionally , figure 1 shows an application of CDDL to define schema for JSON. It's not clear from a skim through the CDDL document that it can be used for JSON; it would appear that using it in this fashion would require additional text in this document to talk about how to apply CDDL to JSON, or waiting for some other document to do so. |
2017-04-21
|
07 | Adam Roach | [Ballot comment] In section 2.2, the phrase "outer collection" is a bit difficult to understand at first (on first reading, the sense of the word … [Ballot comment] In section 2.2, the phrase "outer collection" is a bit difficult to understand at first (on first reading, the sense of the word "outer" is unclear); recommend a more descriptive phrase like "The collection of link relations is represented as a JSON or CBOR array of links" The first paragraph on page 5 is using normal English prose to describe normative behavior, which is fine; however it plainly says that the encoding is normal JSON name/value pairs, and that "the value is a string," full stop, no exceptions. Further down, this section says the value can be a boolean, which effectively contradicts the earlier statement. Even further down, it says the value can be an array of strings. It would be much easier to understand if the initial statement said "the value can be a string, a boolean, or an array of strings, as described below," and then have each of the three situations described independently. Both of the CDDL schemata seem to omit support for array values (i.e., if a name appears twice in a link relation, as shown in Figure 4). Section 2.3 opens with "The above specification could be used as is..." -- there is a risk that implementors might read this as permission rather than hypothetical musing. Suggest rephrasing like "...might have been able to be used as-is..." Table 1 reads is introduced with the phrase "The substitution is summarized below," which had me looking for the actual definition elsewhere in the document. Not finding one, I conclude this table defines, rather than summarizes, the substitution. (Replace "summarized" with "defined"). One would presume the paragraph below table 1 should be removed. The example in Figure 6 would benefit greatly by showing both the array encoding and "foo" encoding used in Figure 4 (including, in particular, the string -- rather than integer -- encoding of the "foo=3" parameter). |
2017-04-21
|
07 | Adam Roach | [Ballot Position Update] New position, Discuss, has been recorded for Adam Roach |
2017-04-21
|
07 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2017-04-21
|
07 | Alexey Melnikov | [Ballot comment] Section 3.2 has cut & paste error that needs to be fixed. A few sentences to address Mark's ARTART Directorate review would be … [Ballot comment] Section 3.2 has cut & paste error that needs to be fixed. A few sentences to address Mark's ARTART Directorate review would be helpful as well. |
2017-04-21
|
07 | Alexey Melnikov | Ballot comment text updated for Alexey Melnikov |
2017-04-20
|
07 | Alexey Melnikov | Ballot has been issued |
2017-04-20
|
07 | Alexey Melnikov | [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov |
2017-04-20
|
07 | Alexey Melnikov | Created "Approve" ballot |
2017-04-20
|
07 | Alexey Melnikov | Ballot writeup was changed |
2017-04-20
|
07 | Alexey Melnikov | Placed on agenda for telechat - 2017-04-27 |
2017-04-20
|
07 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2017-04-20
|
07 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-core-links-json-07.txt. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-core-links-json-07.txt. If any part of this review is inaccurate, please let us know. The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete. First, in the application media types subregistry of the Media Types registry located at: https://www.iana.org/assignments/media-types/ two new mediate types will be registered as follows: Name: link-format+json Template: [ TBD-at-registration ] Reference: [ RFC-to-be ] Name: link-format+cbor Template: [ TBD-at-registration ] Reference: [ RFC-to-be ] Second, in the CoAP Content-Formats subregistry of the CoRE Parameters registry located at: https://www.iana.org/assignments/core-parameters/ Media Type: application/link-format+cbor Encoding: ID: [ TBD-at-Registration ] Reference: { RFC-to-be ] Media Type: application/link-format+cbor Encoding: ID: [ TBD-at-Registration ] Reference: { RFC-to-be ] Because this registry requires Expert Review [RFC5226] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC. The IANA Services Operator understands that these two actions are the only ones 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 only to confirm what actions will be performed. Thank you, Sabrina Tanamal IANA Services Specialist PTI |
2017-04-13
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2017-04-13
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2017-04-13
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Paul Wouters |
2017-04-13
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Paul Wouters |
2017-04-12
|
07 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Victor Kuarsingh |
2017-04-12
|
07 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Victor Kuarsingh |
2017-04-10
|
07 | Mark Nottingham | Request for Last Call review by ARTART Completed: Ready with Issues. Reviewer: Mark Nottingham. Sent review to list. |
2017-04-09
|
07 | Alexey Melnikov | Request for Last Call review by ARTART is assigned to Mark Nottingham |
2017-04-09
|
07 | Alexey Melnikov | Request for Last Call review by ARTART is assigned to Mark Nottingham |
2017-04-07
|
07 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2017-04-07
|
07 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: jaime.jimenez@ericsson.com, core-chairs@ietf.org, Jaime Jimenez , draft-ietf-core-links-json@ietf.org, core@ietf.org, … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: jaime.jimenez@ericsson.com, core-chairs@ietf.org, Jaime Jimenez , draft-ietf-core-links-json@ietf.org, core@ietf.org, alexey.melnikov@isode.com Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Representing CoRE Formats in JSON and CBOR) to Proposed Standard The IESG has received a request from the Constrained RESTful Environments WG (core) to consider the following document: - 'Representing CoRE Formats in JSON and CBOR' 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 ietf@ietf.org mailing lists by 2017-04-21. 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 JavaScript Object Notation, JSON (RFC7159) is a text-based data format which is popular for Web based data exchange. Concise Binary Object Representation, CBOR (RFC7049) is a binary data format which has been optimized for data exchange for the Internet of Things (IoT). For many IoT scenarios, CBOR formats will be preferred since it can help decrease transmission payload sizes as well as implementation code sizes compared to other data formats. Web Linking (RFC5988) provides a way to represent links between Web resources as well as the relations expressed by them and attributes of such a link. In constrained networks, a collection of Web links can be exchanged in the CoRE link format (RFC6690). Outside of constrained environments, it may be useful to represent these collections of Web links in JSON, and similarly, inside constrained environments, in CBOR. This specification defines a common format for this. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-core-links-json/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-core-links-json/ballot/ No IPR declarations have been submitted directly on this I-D. |
2017-04-07
|
07 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2017-04-07
|
07 | Alexey Melnikov | AD review: I found a small cut & paste error: In 3.2: +------------------------------+-------+ … AD review: I found a small cut & paste error: In 3.2: +------------------------------+-------+ | Media type | ID | +------------------------------+-------+ | application/link-format+cbor | TBD64 | | application/link-format+cbor | TBD54 | +------------------------------+-------+ I think one of these should be +json. |
2017-04-07
|
07 | Alexey Melnikov | Last call was requested |
2017-04-07
|
07 | Alexey Melnikov | Last call announcement was generated |
2017-04-07
|
07 | Alexey Melnikov | Ballot approval text was generated |
2017-04-07
|
07 | Alexey Melnikov | Ballot writeup was generated |
2017-04-07
|
07 | Alexey Melnikov | IESG state changed to Last Call Requested from AD Evaluation |
2017-04-07
|
07 | Alexey Melnikov | Requested Last Call review by ARTART |
2017-04-07
|
07 | Alexey Melnikov | IESG state changed to AD Evaluation from Publication Requested |
2017-04-07
|
07 | Alexey Melnikov | Changed consensus to Yes from Unknown |
2017-04-02
|
07 | Jaime Jimenez | Proper rendering at: http://jaimejim.github.io/temp/draft-ietf-core-links-json#shepherd-writeup ###Summary Document Shepherd: Jaime Jiménez, Area Director: Alexey Melnikov, JavaScript Object Notation, JSON (RFC7159) is a text-based data format … Proper rendering at: http://jaimejim.github.io/temp/draft-ietf-core-links-json#shepherd-writeup ###Summary Document Shepherd: Jaime Jiménez, Area Director: Alexey Melnikov, JavaScript Object Notation, JSON (RFC7159) is a text-based data format which is popular for Web based data exchange. Concise Binary Object Representation, CBOR (RFC7049) is a binary data format which has been optimized for data exchange for the Internet of Things (IoT). For many IoT scenarios, CBOR formats will be preferred since it can help decrease transmission payload sizes as well as implementation code sizes compared to other data formats. Web Linking (RFC5988) provides a way to represent links between Web resources as well as the relations expressed by them and attributes of such a link. In constrained networks, a collection of Web links can be exchanged in the CoRE link format (RFC6690). Outside of constrained environments, it may be useful to represent these collections of Web links in JSON, and similarly, inside constrained environments, in CBOR. This specification defines a common format for this. The document is intended for Standards Track. ###Review and Consensus The document has gone through multiple expert reviews and has been discussed on multiple IETF meetings. Before the last IETF the WGLC was completed. ###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 IMO the title should probably be: "Representing CoRE link-format in JSON and CBOR". A previous version included other formats, the present one doesn’t. ###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? `Mail sent to media-types@iana.org, waiting for anwer. New entries (link-format+json and link-format+cbor) need verification by media-types@iana.org.` * [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? `draft-greevenbosch-appsawg-cbor-cddl-09 ref should be updated` * [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? `Both seem correct to me` * [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. `TBD64 and TBD54 are the requested numbers, as shown on Table 2.` * [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? `no new registries` * [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? |
2017-04-02
|
07 | Jaime Jimenez | Responsible AD changed to Alexey Melnikov |
2017-04-02
|
07 | Jaime Jimenez | IETF WG state changed to Submitted to IESG for Publication from In WG Last Call |
2017-04-02
|
07 | Jaime Jimenez | IESG state changed to Publication Requested |
2017-04-02
|
07 | Jaime Jimenez | IESG process started in state Publication Requested |
2017-04-02
|
07 | Jaime Jimenez | Changed document writeup |
2017-03-22
|
07 | Jaime Jimenez | IETF WG state changed to In WG Last Call from WG Document |
2017-03-13
|
07 | Carsten Bormann | New version available: draft-ietf-core-links-json-07.txt |
2017-03-13
|
07 | (System) | New version approved |
2017-03-13
|
07 | (System) | Request for posting confirmation emailed to previous authors: Carsten Bormann , Kepeng Li , core-chairs@ietf.org, Akbar Rahman |
2017-03-13
|
07 | Carsten Bormann | Uploaded new revision |
2017-01-09
|
06 | (System) | Document has expired |
2016-07-08
|
06 | Carsten Bormann | New version available: draft-ietf-core-links-json-06.txt |
2016-06-11
|
05 | Alexey Melnikov | Notification list changed to "Jaime Jimenez" <jaime.jimenez@ericsson.com> |
2016-06-11
|
05 | Alexey Melnikov | Document shepherd changed to Jaime Jimenez |
2016-04-27
|
05 | Carsten Bormann | New version available: draft-ietf-core-links-json-05.txt |
2016-04-04
|
04 | Carsten Bormann | Added to session: IETF-95: core Tue-1740 |
2015-11-01
|
04 | Carsten Bormann | New version available: draft-ietf-core-links-json-04.txt |
2015-07-06
|
03 | Carsten Bormann | This document now replaces draft-li-core-cbor-equivalents, draft-bormann-core-links-json instead of draft-bormann-core-links-json |
2015-07-06
|
03 | Carsten Bormann | New version available: draft-ietf-core-links-json-03.txt |
2014-07-04
|
02 | Carsten Bormann | New version available: draft-ietf-core-links-json-02.txt |
2013-12-02
|
01 | Carsten Bormann | New version available: draft-ietf-core-links-json-01.txt |
2013-07-31
|
00 | Carsten Bormann | Intended Status changed to Proposed Standard from None |
2013-07-31
|
00 | Carsten Bormann | Intended Status changed to Proposed Standard from None |
2013-06-02
|
00 | Carsten Bormann | New version available: draft-ietf-core-links-json-00.txt |