Constrained RESTful Environments (CoRE) Link Format
RFC 6690

Note: This ballot was opened for revision 11 and is now closed.

(Jari Arkko) Discuss

Discuss (2012-03-11 for -11)
This is a well written document, thank you for doing it. I have a small problem with the ABNF, however, see below for the details. Perhaps this video also illustrates my point:
Comment (2012-03-11 for -11)
No email
send info
Bill's ABNF parser suggests this change:

      cardinal          = "0" / %x31-39 *DIGIT
      cardinal          = "0" / ( %x31-39 *DIGIT )


   The CoRE link format is the [RFC5988] production named "Link", and
   imports the ABNF description and associated rules in Section 5 of
   that document.  The "Link:" text is omitted as that is part of the
   HTTP Link Header.  Note that the ABNF in the present document is
   compliant with [RFC5234].

This was very misleading to me, it took a while to realize that RFC 5988
uses the RFC 2616 ABNF, which is different from RFC 5234 ABNF.
Simply copying the ABNF from various RFCs into a file and compiling 
or verifying the ABNF will not work. Also, the actual definition of Link 
does not use the string "Link:" literally:

  Link           = "Link" ":" #link-value

I would suggest a rewrite as follows:

   The CoRE link format is the [RFC5988] ABNF production named
   "Link". This specification imports the ABNF from Section 5 of
   [RFC5988]. However, that ABNF has been defined using the
   format and auxiliary productions defined in [RFC2616] whereas
   the present document uses ABNF as defined in [RFC5234]. As a
   result, for the purposes of the present document, the [RFC5988]
   ABNF needs to be understood as if it were written in [RFC5234]

   In addition, for the purposes of CoRE link format, the "Link:" text
   is omitted as [RFC5988] used it only for the HTTP Link Header.
   As a result, for CoRE link type, the [RFC5988] "Link" production
   should be defined as follows:

   Link = link-value-list
   link-value-list = [ link-value *[ "," link-value ]]
   ;  link-value is as defined in [RFC5988]

(Barry Leiba) (was Discuss) Yes

Comment (2012-06-01)
No email
send info
All DISCUSSes and comments have been addressed.

(Peter Saint-Andre) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

Comment (2012-03-12 for -11)
No email
send info
One minor editorial suggestion: in the Introduction,
RFC 4919 might be a better general reference for
"6LoWPAN" than RFC 4944.

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2012-03-11 for -11)
No email
send info
- Richard Barnes' secdir review suggested text for section 6 about
authorization that the author seems to like, so this is just to note
that until its fixed.

- I'd also suggest adding the following to Richard's suggest text:
"While such servers might not return all links to all requesters, not
providing the link does not, by itsef, control access to the relevant
resource - a bad actor could know or guess the right URIs."

- I'd also suggest adding something about servers that might tell
lies to feed bad data to clients, e.g. "Servers can lie about the
resources available. If it is important for a client to only get
information from a known source, then that source needs to be

(Russ Housley) (was Discuss) No Objection

(Pete Resnick) No Objection

Comment (2012-03-09 for -11)
No email
send info
Only stylistic nits. Otherwise no problems.

I find the questions in section 1.1 a poor writing style and suggest they be removed.

The first sentence of section 6: "This document needs the same security considerations...". Please change "needs" to "has".

(Dan Romascanu) No Objection

(Robert Sparks) No Objection

(Sean Turner) No Objection

Comment (2012-03-14 for -11)
No email
send info
s3.2 Any chance for an actual size for the reasonable size limit?