Constrained RESTful Environments (CoRE) Link Format
draft-ietf-core-link-format-14

[Ballot comment]
[Updated to add a comment about the ABNF in Section 2.]

Substantive comments; these are non-blocking, but please consider them seriously, and feel free to chat with me about them:

-- Section 2 --
RFC 5234 specifies the <"> syntax as "last resort", and it's meant to be a prose description, not actual inserted characters.  And DQUOTE is a built-in core rule.  I suggest you change all instances of <"> to DQUOTE in the link-param, quoted-mt, and relation-types productions.

-- Section 4.1 --
The ABNF here allows the following values for filter-query; are these acceptable (syntactically, whether or not they make sense to use)?:
    rt=
    rt==
    rt=;
    rt='
    rt=(

OLD
  If the decoded query-pattern ends with
  "*", it is sufficient that the remainder of the query-pattern be a
  prefix of the value denoted by the resource-param.  A query-pattern
  of "*" matches to an empty string value as well as to any other non-
  empty string.
COMMENT
This feels like awkward wording to me.  I suggest the following replacement.  I also suggest that this paragraph end here, and that a new paragraph be started with "It is not expected...".
NEW
  If the decoded query-pattern ends with
  "*", the search-token portion must match (byte-wise) the beginning
  of the value denoted by the resource-param.  A query-pattern of "*"
  matches every string, including the empty string.

-- Section 7.4 --
OLD
  This specification establishes two new registries, one for Resource
  Type (rt=) and the other for Interface Description (if=) link target
  attribute values.  This registry is similar to the Link Relation
  Registry defined in [RFC5988].  No initial entries are defined by
  this specification for either registry.
COMMENT
Especially if we use the same link-relation mailing list for discussion, I suggest that you explicitly make these new sub-registries of the Link Relations registry:
NEW
  This specification establishes two new sub-registries of Link
  Relations (defined in [RFC5988]), one for Resource Type (rt=)
  Link Target Attribute Values and the other for Interface
  Description (if=) Link Target Attribute Values.  No initial
  entries are defined by this specification for either registry.

I suggest re-casting the first bullet list (with the 2119 terms) as instructions to the designated expert, like this:

OLD
  These registries have the following requirements on values:
NEW
  The designated expert will enforce the following requirements:

In the second bullet, the first MUST (about conforming to ABNF) is the only normative requirement needed.  The rest is just clarification.  I suggest this:

OLD
  o  Registered values MUST conform to the ABNF reg-rel-type definition
      of Section 2, meaning the value MUST start with a lower case
      alphabet character, followed by a sequence of lower case alphabet,
      numeric, "." or "-" characters.  The value MUST NOT contain white
      space.
NEW
  o  Registered values MUST conform to the ABNF reg-rel-type definition
      of Section 2, meaning that the value starts with a lower case
      alphabetic character, followed by a sequence of lower case
      alphabetic, numeric, "." or "-" characters, and contains no white
      space.

Editorial: In the third bullet, recommendations need subjunctive mood, so change both occurrences of "character is used" to "character be used".

Now that we've clarified the IETF Review and Specification Required policies, we don't need to repeat here what those policies are.  So:

OLD
  Registration requests consist of the completed registration template
  below, typically published in an RFC or Open Standard (in the sense
  described by [RFC2026], Section 7).  However, to allow for the
  allocation of values prior to publication, the Designated Expert may
  approve registration once they are satisfied that a specification
  will be published.
NEW
  Registration requests consist of the completed registration template
  below, with the reference pointing to the required specification.
  To allow for the allocation of values prior to publication, the
  designated expert may approve registration once they are satisfied
  that a specification will be published.


OLD
  The registration template for both registries is:
NEW
  The registration template for both sub-registries is:

[Ballot comment]
[Updated to add a comment about the ABNF in Section 2.]

Substantive comments; these are non-blocking, but please consider them seriously, and feel free to chat with me about them:

-- Section 2 --
RFC 5234 specifies the <"> syntax as "last resort", and it's meant to be a prose description, not actual inserted characters.  And DQUOTE is a built-in core rule.  I suggest you change all instances of <"> to DQUOTE in the quoted-mt and relation-types productions.

-- Section 4.1 --
The ABNF here allows the following values for filter-query; are these acceptable (syntactically, whether or not they make sense to use)?:
    rt=
    rt==
    rt=;
    rt='
    rt=(

OLD
  If the decoded query-pattern ends with
  "*", it is sufficient that the remainder of the query-pattern be a
  prefix of the value denoted by the resource-param.  A query-pattern
  of "*" matches to an empty string value as well as to any other non-
  empty string.
COMMENT
This feels like awkward wording to me.  I suggest the following replacement.  I also suggest that this paragraph end here, and that a new paragraph be started with "It is not expected...".
NEW
  If the decoded query-pattern ends with
  "*", the search-token portion must match (byte-wise) the beginning
  of the value denoted by the resource-param.  A query-pattern of "*"
  matches every string, including the empty string.

-- Section 7.4 --
OLD
  This specification establishes two new registries, one for Resource
  Type (rt=) and the other for Interface Description (if=) link target
  attribute values.  This registry is similar to the Link Relation
  Registry defined in [RFC5988].  No initial entries are defined by
  this specification for either registry.
COMMENT
Especially if we use the same link-relation mailing list for discussion, I suggest that you explicitly make these new sub-registries of the Link Relations registry:
NEW
  This specification establishes two new sub-registries of Link
  Relations (defined in [RFC5988]), one for Resource Type (rt=)
  Link Target Attribute Values and the other for Interface
  Description (if=) Link Target Attribute Values.  No initial
  entries are defined by this specification for either registry.

I suggest re-casting the first bullet list (with the 2119 terms) as instructions to the designated expert, like this:

OLD
  These registries have the following requirements on values:
NEW
  The designated expert will enforce the following requirements:

In the second bullet, the first MUST (about conforming to ABNF) is the only normative requirement needed.  The rest is just clarification.  I suggest this:

OLD
  o  Registered values MUST conform to the ABNF reg-rel-type definition
      of Section 2, meaning the value MUST start with a lower case
      alphabet character, followed by a sequence of lower case alphabet,
      numeric, "." or "-" characters.  The value MUST NOT contain white
      space.
NEW
  o  Registered values MUST conform to the ABNF reg-rel-type definition
      of Section 2, meaning that the value starts with a lower case
      alphabetic character, followed by a sequence of lower case
      alphabetic, numeric, "." or "-" characters, and contains no white
      space.

Editorial: In the third bullet, recommendations need subjunctive mood, so change both occurrences of "character is used" to "character be used".

Now that we've clarified the IETF Review and Specification Required policies, we don't need to repeat here what those policies are.  So:

OLD
  Registration requests consist of the completed registration template
  below, typically published in an RFC or Open Standard (in the sense
  described by [RFC2026], Section 7).  However, to allow for the
  allocation of values prior to publication, the Designated Expert may
  approve registration once they are satisfied that a specification
  will be published.
NEW
  Registration requests consist of the completed registration template
  below, with the reference pointing to the required specification.
  To allow for the allocation of values prior to publication, the
  designated expert may approve registration once they are satisfied
  that a specification will be published.


OLD
  The registration template for both registries is:
NEW
  The registration template for both sub-registries is:

[Ballot comment]
[Updated to add a comment about the ABNF in Section 2.]

Substantive comments; these are non-blocking, but please consider them seriously, and feel free to chat with me about them:

-- Section 2 --
RFC 5234 specifies the <"> syntax as "last resort", and DQUOTE is a built-in core rule.  I suggest you change all instances of <"> to DQUOTE in the quoted-mt and relation-types productions.

-- Section 4.1 --
The ABNF here allows the following values for filter-query; are these acceptable (syntactically, whether or not they make sense to use)?:
    rt=
    rt==
    rt=;
    rt='
    rt=(

OLD
  If the decoded query-pattern ends with
  "*", it is sufficient that the remainder of the query-pattern be a
  prefix of the value denoted by the resource-param.  A query-pattern
  of "*" matches to an empty string value as well as to any other non-
  empty string.
COMMENT
This feels like awkward wording to me.  I suggest the following replacement.  I also suggest that this paragraph end here, and that a new paragraph be started with "It is not expected...".
NEW
  If the decoded query-pattern ends with
  "*", the search-token portion must match (byte-wise) the beginning
  of the value denoted by the resource-param.  A query-pattern of "*"
  matches every string, including the empty string.

-- Section 7.4 --
OLD
  This specification establishes two new registries, one for Resource
  Type (rt=) and the other for Interface Description (if=) link target
  attribute values.  This registry is similar to the Link Relation
  Registry defined in [RFC5988].  No initial entries are defined by
  this specification for either registry.
COMMENT
Especially if we use the same link-relation mailing list for discussion, I suggest that you explicitly make these new sub-registries of the Link Relations registry:
NEW
  This specification establishes two new sub-registries of Link
  Relations (defined in [RFC5988]), one for Resource Type (rt=)
  Link Target Attribute Values and the other for Interface
  Description (if=) Link Target Attribute Values.  No initial
  entries are defined by this specification for either registry.

I suggest re-casting the first bullet list (with the 2119 terms) as instructions to the designated expert, like this:

OLD
  These registries have the following requirements on values:
NEW
  The designated expert will enforce the following requirements:

In the second bullet, the first MUST (about conforming to ABNF) is the only normative requirement needed.  The rest is just clarification.  I suggest this:

OLD
  o  Registered values MUST conform to the ABNF reg-rel-type definition
      of Section 2, meaning the value MUST start with a lower case
      alphabet character, followed by a sequence of lower case alphabet,
      numeric, "." or "-" characters.  The value MUST NOT contain white
      space.
NEW
  o  Registered values MUST conform to the ABNF reg-rel-type definition
      of Section 2, meaning that the value starts with a lower case
      alphabetic character, followed by a sequence of lower case
      alphabetic, numeric, "." or "-" characters, and contains no white
      space.

Editorial: In the third bullet, recommendations need subjunctive mood, so change both occurrences of "character is used" to "character be used".

Now that we've clarified the IETF Review and Specification Required policies, we don't need to repeat here what those policies are.  So:

OLD
  Registration requests consist of the completed registration template
  below, typically published in an RFC or Open Standard (in the sense
  described by [RFC2026], Section 7).  However, to allow for the
  allocation of values prior to publication, the Designated Expert may
  approve registration once they are satisfied that a specification
  will be published.
NEW
  Registration requests consist of the completed registration template
  below, with the reference pointing to the required specification.
  To allow for the allocation of values prior to publication, the
  designated expert may approve registration once they are satisfied
  that a specification will be published.


OLD
  The registration template for both registries is:
NEW
  The registration template for both sub-registries is:

[Ballot discuss]
I realize that you may have just copied some text from another RFC, but that doesn't mean it's right; you know how that goes.

-- Section 7.4 --

(This is the DISCUSS portion; I have other comments on 7.4 in the COMMENTS portion.)

It would be best to put the registration policy up front, and to make the difference in policy between "core*" entries and others immediately clear.  It's also problematic to require "an IETF working group document".  You know there will be a time when we want to add something to the registry and won't want to spin up a working group to do it.  It would be better to pick a well-known registration policy from BCP 26.  I suggest that you insert this after the first paragraph (and delete the appropriate stuff later in the section):

NEW
  For both sub-registries, values starting with the characters
  "core" are registered using the IETF Review registration
  policy [RFC5226].  All other values are registered using
  the Specification Required policy, which requires review by
  a designated expert appointed by the IESG or their delegate.

This needs to be removed; we shouldn't be telling IANA how to manage its process:
REMOVE
  IANA should only accept registry updates from the Designated
  Expert(s), and should direct all requests for registration to the
  review mailing list.

[Ballot discuss]
I realize that you may have just copied some text from another RFC, but that doesn't mean it's right; you know how that goes.

-- Section 7.4 --

(This is the DISCUSS portion; I have other comments on 7.4 in the COMMENTS portion.)

It would be best to put the registration policy up front, and to make the difference in policy between "core*" entries and others immediately clear.  It's also problematic to require "an IETF working group document".  You know there will be a time when we want to add something to the registry and won't want to spin up a working group to do it.  It would be better to pick a well-known registration policy from BCP 26.  I suggest that you insert this after the first paragraph (and delete the appropriate stuff later in the section):

NEW
  For both sub-registries, values starting with the characters
  "core" are registered using the IETF Review registration
  policy [RFC5226].  All other values are are registered using
  the Specification Required policy, which requires review by
  a designated expert appointed by the IESG or their delegate.

This needs to be removed; we shouldn't be telling IANA how to manage its process:
REMOVE
  IANA should only accept registry updates from the Designated
  Expert(s), and should direct all requests for registration to the
  review mailing list.

[Ballot comment]
Substantive comments; these are non-blocking, but please consider them seriously, and feel free to chat with me about them:

-- Section 4.1 --
The ABNF here allows the following values for filter-query; are these acceptable (syntactically, whether or not they make sense to use)?:
    rt=
    rt==
    rt=;
    rt='
    rt=(

OLD
  If the decoded query-pattern ends with
  "*", it is sufficient that the remainder of the query-pattern be a
  prefix of the value denoted by the resource-param.  A query-pattern
  of "*" matches to an empty string value as well as to any other non-
  empty string.
COMMENT
This feels like awkward wording to me.  I suggest the following replacement.  I also suggest that this paragraph end here, and that a new paragraph be started with "It is not expected...".
NEW
  If the decoded query-pattern ends with
  "*", the search-token portion must match (byte-wise) the beginning
  of the value denoted by the resource-param.  A query-pattern of "*"
  matches every string, including the empty string.

-- Section 7.4 --
OLD
  This specification establishes two new registries, one for Resource
  Type (rt=) and the other for Interface Description (if=) link target
  attribute values.  This registry is similar to the Link Relation
  Registry defined in [RFC5988].  No initial entries are defined by
  this specification for either registry.
COMMENT
Especially if we use the same link-relation mailing list for discussion, I suggest that you explicitly make these new sub-registries of the Link Relations registry:
NEW
  This specification establishes two new sub-registries of Link
  Relations (defined in [RFC5988]), one for Resource Type (rt=)
  Link Target Attribute Values and the other for Interface
  Description (if=) Link Target Attribute Values.  No initial
  entries are defined by this specification for either registry.

I suggest re-casting the first bullet list (with the 2119 terms) as instructions to the designated expert, like this:

OLD
  These registries have the following requirements on values:
NEW
  The designated expert will enforce the following requirements:

In the second bullet, the first MUST (about conforming to ABNF) is the only normative requirement needed.  The rest is just clarification.  I suggest this:

OLD
  o  Registered values MUST conform to the ABNF reg-rel-type definition
      of Section 2, meaning the value MUST start with a lower case
      alphabet character, followed by a sequence of lower case alphabet,
      numeric, "." or "-" characters.  The value MUST NOT contain white
      space.
NEW
  o  Registered values MUST conform to the ABNF reg-rel-type definition
      of Section 2, meaning that the value starts with a lower case
      alphabetic character, followed by a sequence of lower case
      alphabetic, numeric, "." or "-" characters, and contains no white
      space.

Editorial: In the third bullet, recommendations need subjunctive mood, so change both occurrences of "character is used" to "character be used".

Now that we've clarified the IETF Review and Specification Required policies, we don't need to repeat here what those policies are.  So:

OLD
  Registration requests consist of the completed registration template
  below, typically published in an RFC or Open Standard (in the sense
  described by [RFC2026], Section 7).  However, to allow for the
  allocation of values prior to publication, the Designated Expert may
  approve registration once they are satisfied that a specification
  will be published.
NEW
  Registration requests consist of the completed registration template
  below, with the reference pointing to the required specification.
  To allow for the allocation of values prior to publication, the
  designated expert may approve registration once they are satisfied
  that a specification will be published.


OLD
  The registration template for both registries is:
NEW
  The registration template for both sub-registries is:

[Ballot discuss]
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

[Ballot comment]
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]

[Ballot discuss]
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

[Ballot comment]
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 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]

[Ballot comment]
- 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."

[Ballot comment]
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 for the HTTP Link Header. As a result,
  for the purposes of the present document, 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]

[Ballot comment]
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 for the HTTP Link Header. As a result, for the purposes
  of the present document, the [RFC5988] "Link" production should be modified
  as follows:

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

[Ballot discuss]

  The Gen-ART Review by Joel Halpern on 18-Feb 2012 raised a question
  that still needs to be resolved in the document.  Joel asked:
  >
  > What is the registration / collision avoidance strategy for resource
  > type (rt) and interface description (if) values?  They are both
  > defined as opaque strings which can happen to be URIs.  So there
  > seems to be potential for collision.
  >
  The author indicates that two separate IANA registries for rt and if
  types are fine with him, but this is not reflected in the document.

[Ballot comment]
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".

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (CoRE Link Format) to Proposed Standard


The IESG has received a request from the Constrained RESTful Environments
WG (core) to consider the following document:
- 'CoRE Link Format'
  as a 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 2012-02-28. 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


  This document defines Web Linking using a link format for use by
  constrained web servers to describe hosted resources, their
  attributes and other relationships between links.  Based on the HTTP
  Link Header format defined in RFC5988, the CoRE Link Format is
  carried as a payload and is assigned an Internet media type.  A well-
  known URI is defined as a default entry-point for requesting the
  links hosted by a server.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-core-link-format/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-core-link-format/


No IPR declarations have been submitted directly on this I-D.

Request for publication of draft-ietf-core-link-format-11.txt

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

The Document Shepherd is CoRE WG co-chair Carsten Bormann
(cabo@tzi.org).  He has personally reviewed the document and believes
that it is ready for forwarding to the IESG for publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed?

The document is one of the core output documents of the CoRE WG.  It
has received wide review, including some review from the wider Web
community, as well as wide interop testing in CoRE interop testing
events.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

It is not very easy to obtain the attention of the Web community.
While we have had review from some of the key people behind Web
Linking (RFC5988), additional attention would not hurt.  (One person
has proposed an application outside CoRE and uncovered requirements
that might require extensions beyond those required in CoRE.)  For the
specific purposes of the CoRE WG, however, there are no concerns that
the document requires additional broader review.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

There are no such concerns or issues.  The document represents a
strong WG consensus.  No IPR disclosures have been made.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

The document has been widely implemented and is the basis for various
discovery proposals from diverse groups within the WG.  The WG has
consensus that the document specifies the data format that will be
used in fulfilling the requirement for resource discovery in CoRE
environments.  A significant number of WG members have commented on
the technical substance and language of the specification, resulting
in 23 tickets closed over the 10 WG document revisions.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

The shepherd is not aware of any discontent related to the
specification.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

The shepherd has verified to the best of his ability that there are no
ID nits in this draft (the most recent versions were created solely to
clear some remaining ID nits).

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

The Document Shepherd believes all references are appropriately split.
(It is possibly a fine point whether RFC5785 is a normative or
informative reference.)  There are no down-references.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

The IANA considerations are quite important to this document and
appear to be correct.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

The document contains two short ABNF snippets, one in the RFC 2616
dialect (as imported from RFC 5988) and one in true RFC 5234 form.
These have been validated with the tool "bap".

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary

To enable machine-to-machine communication using REST-style protocols,
a standard way to do resource discovery is needed.  The present
document defines a link format to enable Web Linking by constrained
web servers for describing hosted resources, their attributes and
other relationships between links.  A small variation of the HTTP Link
Header format defined in RFC5988, the CoRE Link Format is carried as a
payload and is assigned an Internet media type.  A well-known URI is
defined as a default entry-point for requesting the links to resources
hosted by a server.

    Working Group Summary

This document represents the consensus of the CoRE WG.

    Document Quality

The document is a product of the CoRE working group and has been
reviewed in detail by a number of CoRE working group members.  The
principal content of the document has been technically stable for
nearly a year, during which certain fringe cases were identified by
reviewers and implementers and addressed in minor updates to the
specification.  The specification has been picked up widely in the
CoRE community and has been used as a central element of the CoRE
informal interoperability testing events.

1) A review of the ".well-known/core" URI (section 7.1):
  http://www.ietf.org/mail-archive/web/wellknown-uri-review/current/msg00044.html
2) A review of the 'hosts' relation type (section 7.2):
  http://www.ietf.org/mail-archive/web/link-relations/current/msg00307.html
3) A review of the link-format Internet media type (section 7.3):
  http://www.ietf.org/mail-archive/web/ietf-types/current/msg01621.html
have been requested as of 2012-02-14.

The proto writeup follows.

###

[Write-up template version dated September 17, 2008.]

Request for publication of draft-ietf-core-link-format-11.txt

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

The Document Shepherd is CoRE WG co-chair Carsten Bormann
(cabo@tzi.org).  He has personally reviewed the document and believes
that it is ready for forwarding to the IESG for publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed?

The document is one of the core output documents of the CoRE WG.  It
has received wide review, including some review from the wider Web
community, as well as wide interop testing in CoRE interop testing
events.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

It is not very easy to obtain the attention of the Web community.
While we have had review from some of the key people behind Web
Linking (RFC5988), additional attention would not hurt.  (One person
has proposed an application outside CoRE and uncovered requirements
that might require extensions beyond those required in CoRE.)  For the
specific purposes of the CoRE WG, however, there are no concerns that
the document requires additional broader review.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

There are no such concerns or issues.  The document represents a
strong WG consensus.  No IPR disclosures have been made.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

The document has been widely implemented and is the basis for various
discovery proposals from diverse groups within the WG.  The WG has
consensus that the document specifies the data format that will be
used in fulfilling the requirement for resource discovery in CoRE
environments.  A significant number of WG members have commented on
the technical substance and language of the specification, resulting
in 23 tickets closed over the 10 WG document revisions.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

The shepherd is not aware of any discontent related to the
specification.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

The shepherd has verified to the best of his ability that there are no
ID nits in this draft (the most recent versions were created solely to
clear some remaining ID nits).

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

The Document Shepherd believes all references are appropriately split.
(It is possibly a fine point whether RFC5785 is a normative or
informative reference.)  There are no down-references.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

The IANA considerations are quite important to this document and
appear to be correct.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

The document contains two short ABNF snippets, one in the RFC 2616
dialect (as imported from RFC 5988) and one in true RFC 5234 form.
These have been validated with the tool "bap".

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary

To enable machine-to-machine communication using REST-style protocols,
a standard way to do resource discovery is needed.  The present
document defines a link format to enable Web Linking by constrained
web servers for describing hosted resources, their attributes and
other relationships between links.  A small variation of the HTTP Link
Header format defined in RFC5988, the CoRE Link Format is carried as a
payload and is assigned an Internet media type.  A well-known URI is
defined as a default entry-point for requesting the links to resources
hosted by a server.

    Working Group Summary

This document represents the consensus of the CoRE WG.

    Document Quality

The document is a product of the CoRE working group and has been
reviewed in detail by a number of CoRE working group members.  The
principal content of the document has been technically stable for
nearly a year, during which certain fringe cases were identified by
reviewers and implementers and addressed in minor updates to the
specification.  The specification has been picked up widely in the
CoRE community and has been used as a central element of the CoRE
informal interoperability testing events.

1) A review of the ".well-known/core" URI (section 7.1):
  http://www.ietf.org/mail-archive/web/wellknown-uri-review/current/msg00044.html
2) A review of the 'hosts' relation type (section 7.2):
  http://www.ietf.org/mail-archive/web/link-relations/current/msg00307.html
3) A review of the link-format Internet media type (section 7.3):
  http://www.ietf.org/mail-archive/web/ietf-types/current/msg01621.html
have been requested as of 2012-02-14.

###