Skip to main content

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