Constrained RESTful Environments (CoRE) Link Format
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: http://www.youtube.com/watch?feature=player_embedded&v=LbK-g8tKnoc
Comment (2012-03-11 for -11)
Bill's ABNF parser suggests this change: OLD: cardinal = "0" / %x31-39 *DIGIT NEW: cardinal = "0" / ( %x31-39 *DIGIT ) Also: 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] form. 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
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)
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)
- 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 authenticated."
(Russ Housley) (was Discuss) No Objection
(Pete Resnick) No Objection
Comment (2012-03-09 for -11)
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)
s3.2 Any chance for an actual size for the reasonable size limit?