Re: Last Call: <draft-nottingham-rfc5988bis-05.txt> (Web Linking) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Here's my feedback, mainly editorial nits...:

   Additionally, the following rules are included from [RFC3986]: URI
   and URI-Reference; from [RFC6838]: type-name and subtype-name; from
   [W3C.CR-css3-mediaqueries-20090915]: media_query_list; and from
   [RFC5646]: Language-Tag.

That doesn't work, as "_" is not a legal ABNF character.

2.  Links

   In this specification, a link is a typed connection between two
   resources, and is comprised of:

   o  A _link context_,

   o  a _link relation type_ (Section 2.1),

   o  a _link target_, and

   o  optionally, _target attributes_ (Section 2.2).

It might be good to add forward references for "link context" and "link target" as well.

   Finally, links are consumed by _link applications_. Generally, an
   application will define the link relation type(s) it uses, along with
   the serialisation(s) that they might occur within.  For example, the
   application "Web browsing" looks for the "stylesheet" link relation
   type in the HTML link serialisation, whereas the application
   "AtomPub" uses the "edit" and "edit-media" link relations.

Actually, one popular browser also looks for the stylesheet link relation in the "Link" header field...

   Relation types are not to be confused with media types [RFC6838];

Media types are defined in RFC 2046; RFC 6838 is mainly about media type registrations.

   they do not identify the format of the representation that results
   when the link is dereferenced.  Rather, they only describe how the
   current context is related to another resource.

   o  *Reference*: Reference to the document that specifies the link
      relation type, preferably including a URI that can be used to
      retrieve a copy of the document.  An indication of the relevant
      section(s) MAY also be included, but is not required.

s/MAY/can/

   Note that relation types can be registered by third parties
   (including the Expert(s)), if the Expert(s) determine that an
   unregistered relation type is widely deployed and not likely to be
   registered in a timely manner.

maybe s/registered/registed otherwise/?

2.1.1.2.  Registration Request Processing

   Relation types are registered on the advice of a Designated Expert
   (appointed by the IESG or their delegate), with a Specification
   Required (using terminology from [RFC5226]).

s/[RFC5226]/Section 4.1 of [RFC5226]/


2.2.  Target Attributes

   This specification does not attempt to coordinate the name of target
   attributes, their cardinality or use.  Serialisations SHOULD
   coordinate their target attributes to avoid conflicts in semantics or
   syntax.

I'm not sure who's the audience for this SHOULD, and how to implement it. For instance, shouldn't this spec do this for the header field serialization?

3.  Link Serialisation in HTTP Headers

s/Headers/Header fields/

   This specification defines the link-params "rel", "anchor", "rev",
   "hreflang", "media", "title", "title*", and "type"; see Section 3.2,
   Section 3.3 and Section 3.4.

s/Section 3.2, Section 3.3 and Section 3.4/Sections 3.2, 3.3, and 3.4/

3.1.  Link Target

   Each link-value conveys one target IRI as a URI-Reference (after
   conversion to one, if necessary; see [RFC3987], Section 3.1) inside
   angle brackets ("<>").  If the URI-Reference is relative, parsers
   MUST resolve it as per [RFC3986], Section 5.  Note that any base IRI
   from the message's content is not applied.

Maybe s/base IRI from the message's content/base IRI appearing inside the message's content/

3.2.  Link Context

   By default, the context of a link conveyed in the Link header field
   is identity of the representation it is associated with, as defined
   in [RFC7231], Section 3.1.4.1, serialised as a URI.

Broken sentence: "is identity".

   The ABNF for the "anchor" parameter's value is:

     URI-Reference

s/URI-Reference/URI-Reference; Section 4.1 of [RFC3986]/

   Note that depending on HTTP status code and response headers, the
   link context might be "anonymous" (i.e., no link context is
   available).  For example, this is the case on a 404 response to a GET
   request.

I understand this is identical in RFC 5988, but where does this actually come from? It basically restricts use of anchor-less link header fields 2xx responses, right?

3.3.  Relation Type

   The ABNF for the "rel" and "rev" parameters' values is:

     relation-type *( 1*SP relation-type )

   where:

     relation-type  = reg-rel-type | ext-rel-type

Finally I can use this link https://www.youtube.com/watch?v=LbK-g8tKnoc in LC feedback!

     reg-rel-type   = LOALPHA *( LOALPHA | DIGIT | "." | "-" )
     ext-rel-type   = URI

s/URI/URI; Section 3 of [RFC3986]/

   Note that extension relation types are REQUIRED to be absolute URIs
   in Link headers, and MUST be quoted if they contain a semicolon (";")

s/headers/header fields/

   or comma (",") (as these characters are used as delimiters in the
   header field itself).

There are more characters legal in URIs but illegal in token -- so maybe phrasing it like this can cause confusion. Maybe "MUST be quoted when they contain characters not allowed in tokens, such as ...."?

3.4.1.  Serialisation-Defined Attributes

   The ABNF for the "type" parameter's value is:

     type-name "/" subtype-name

(maybe point to https://tools.ietf.org/html/rfc6838#section-4.2 here)


3.5.  Link Header Field Examples

Maybe add an example for multiple Link header field instances in a single message?


4.1.  Link HTTP Header Field Registration

   Header field: Link
   Applicable protocol: http
   Status: standard
   Author/change controller:
       IETF  (iesg@xxxxxxxx)
       Internet Engineering Task Force
   Specification document(s):
       [RFC&rfc.number;]

s/[RFC&rfc.number;]/this document/


4.2.  Link Relation Type Registry

   Each published document will be at a URL mutually agreed to by IANA
   and the Expert(s), and IANA will set HTTP response headers on them as
   (reasonably) requested by the Expert(s).

Wow. Does IANA know that we want to configure their web server?


5.  Security Considerations

   Link applications ought to consider the attack vectors opened by
   automatically following, trusting, or otherwise using links gathered
   from HTTP headers.  In particular, Link header fields that use the

s/headers/header fields/

   "anchor" parameter to associate a link's context with another
   resource are to be treated with due caution.

   The Link header field makes extensive use of IRIs and URIs.  See
   [RFC3987] for security considerations relating to IRIs.  See
   [RFC3986] for security considerations relating to URIs.  See
   [RFC7230] for security considerations relating to HTTP headers.

s/headers/header fields/

7.1.  Normative References

   [W3C.CR-css3-mediaqueries-20090915]
              Lie, H., Celik, T., Glazman, D., and A. Kesteren, "Media
              Queries", World Wide Web Consortium CR CR-css3-
              mediaqueries-20090915, September 2009,
              <http://www.w3.org/TR/2009/CR-css3-mediaqueries-20090915>.

Need to update to <https://www.w3.org/TR/2012/REC-css3-mediaqueries-20120619/>.

   [W3C.REC-html5-20141028]
              Hickson, I., Berjon, R., Faulkner, S., Leithead, T.,
              Navara, E., O&#039;Connor, T., and S. Pfeiffer, "HTML5",
              World Wide Web Consortium Recommendation REC-
              html5-20141028, October 2014,
              <http://www.w3.org/TR/2014/REC-html5-20141028>.

Broken escape in author name.


A.1.  Link Serialisation in HTML

   HTML5 ([W3C.REC-html5-20141028]) Section 4.8 defines modern HTML

"Section 4.8 of HTML5"

   links.  That document links to the Microformats Wiki as a registry;
   over time, the IANA registry ought to mirror its contents, and
   ideally eventually replace it (although that depends on the HTML
   community).


Appendix B.  Algorithm for Parsing Link Headers

   Given a HTTP header field-value "field_value" as a string assuming
   ASCII encoding, the following algorithm can be used to parse it into
   the model described by this specification:

This part is a bit scary -- I don't know how to review it. It might be better to have code in an actual programming language, and a set of tests for it.

   1.  Let "links" be an empty list.

   2.  Create "link_strings" by splitting "field_value" on ","
       characters, excepting "," characters within quoted strings as per

I have my doubts that people will be able to translate it into actually correct code. To detect whether something is inside a quoted-string essentially requires running a parser; the prose here suggests that this is not necessary.

It also should mention that there might be multiple instances of field_value.




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]