Re: draft-nottingham-http-link-relation-07 progress

[Julian Reschke <[e-mail]>]

Mark Nottingham wrote:
> Based on Last Call feedback, as well as discussions with members of the HTML5 WG, I've taken another pass at this spec.
> 
> There's a complete change listing at the end of the spec, as well as a diff, but the biggest change is in the registry itself; it now allows extension "fields" to be registered by third parties, to aid in deploying applications that want to leverage the registry.
> ...

Thanks, Mark.

Comments below:

3.  Links

    This specification does not place restrictions on the cardinality of
    links; there can be multiple links from and to a particular IRI, and
    multiple links of different types between two given IRIs.  Likewise,
    the relative ordering of links in any particular serialisation, or
    between serialisations (e.g., the Link header and in-content links)
    is not specified or significant in this specification; applications
    that wish to consider ordering significant MAY do so.

s/MAX/can/

That being said, see TimBL's comment in
<http://lists.w3.org/Archives/Public/www-tag/2009Dec/0038.html>.

4.1.  Registered Relation Types

    Well-defined relation types SHOULD be registered as tokens for
    convenience and to promote reuse.  This specification establishes an
    IANA registry of such relation types; see Section 6.2.

Compared to earlier drafts, this seems to suggest that any well-defined
relation should be registered. Previously we had

    "Commonly-used relation types with a clear meaning that are shared
    across applications can be registered as tokens for convenience and
    to promote reuse." (draft 06)

Is this really a change we want to make? If yes, what would be the feedback
for the relations defined by CMIS (currently using extension types), such
as "http://docs.oasis-open.org/ns/cmis/link/200908/typedescendants" (see
<http://docs.oasis-open.org/cmis/CMIS/v1.0/cd04/cmis-spec-v1.0.html#_Toc243712631>)?


4.2.  Extension Relation Types

    Applications that don't wish to register a relation type may use an
    extension relation type, which is a URI [RFC3986] that uniquely
    identifies the relation type.  Although the URI MAY point to a
    resource that contains a definition of the semantics of the relation
    type, clients SHOULD NOT automatically access that resource to avoid
    overburdening its server.

s/MAY/can/

    When extension relation types are compared, they MUST be compared as
    URIs in a case-insensitive fashion, character-by-character.

Should we add guidance about how to mint the URIs then, such as "prefer
all-lowercase"?

5.  The Link Header Field

    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 body's content is not applied.

(maybe clarify "body" here)

    The relation type of a link is conveyed in the "rel" parameter's
    value.  The "rev" parameter has also been used for this purpose
    historically by some formats, and MAY be accommodated as a link-
    extension, but its use is neither encouraged nor defined by this
    specification.

Jonathan Rees points out in 
<http://lists.w3.org/Archives/Public/www-tag/2009Dec/0052.html>
that this makes it sound as if rev and rel are synonymous.


5.1.  Examples

    NOTE: Non-ASCII characters used in prose for examples are encoded
    using the format "Backslash-U with Delimiters", defined in Section
    5.1 of [RFC5137].

I think this note needs to be removed; it's not true anymore.

    The example below shows an instance of the Link header encoding
    multiple links, and also the use of RFC 2231 encoding to encode both
    non-ASCII characters and language information.

    Link: </TheBook/chapter2>;
          rel="previous"; title*=UTF-8'de'letztes%20Kapitel,
          </TheBook/chapter4>;
          rel="next"; title*=UTF-8'de'n%c3%a4chstes%20Kapitel

    Here, the second link has a title encoded in UTF-8, uses the German
    language ("de"), and contains the Unicode code point U+00E4 ("LATIN
    SMALL LETTER A WITH DIAERESIS").

"Here, both links have titles encoded in UTF-8, use the German language
("d"), and the second one contains the Unicode code point..."



6.2.  Link Relation Type Registry

    [[ Note to RFC Editor: Entries in the Atom registry that are not
    listed below at the time that IANA implements this change (i.e.,
    those that are registered before this document comes into effect)
    should be referred to the Designated Expert. ]]

Not sure that the RFC Editor is the right audience here; shouldn't it be 
the IESG?

6.2.1.  Registering new Link Relation Types

    Within at most 14 days of the request, the Designated Expert will
    either approve or deny the registration request, communicating this

(I think 14 days is really short; if the designated expert lived in 
Germany, for instance, being on vacation for two weeks in a row wouldn't 
be THAT exceptional).

    decision to the review list.  Denials should include an explanation
    and, if applicable, suggestions as to how to make the request
    successful.  Registration requests that are undetermined for a period
    longer than 21 days MAY be brought to the IESG's attention (using the
    [e-mail] mailing list) for resolution.

s/MAY/can/


7.  Security Considerations

    Applications that take advantage of typed links should consider the
    attack vectors opened by automatically following, trusting, or
    otherwise using links gathered from HTTP headers.  In particular,
    Link headers that use the "anchor" parameter to associate a link's
    context with another resource should be treated with due caution.

(maybe the case where anchor is needed on a non-GET response without
Content-Location response should be mentioned as a case where anchor
actually is needed; maybe this belongs somewhere else though).


Appendix B.  Notes on Using the Link Header with HTML4

    HTML4 also has a "rev" parameter for links that allows a link's
    relation to be reversed.  The Link header does not define a
    corresponding "rev" parameter to allow the expression of these links
    in HTTP headers, due to the confusion this mechanism causes as well
    as conflicting interpretations among HTML versions.

I think the part about the "conflicting interpretations" should be
explained somewhere for future reference (I'm still not sure I 
understand it).

    Individual applications of linking will therefore need to define
    their extension links should be serialised into HTML4.

s/define their/define how their/?

That being said, shouldn't we state a default?



Best regards, Julian