Web Linking
draft-nottingham-http-link-header-10

[Ballot comment]
I am now satisfied that the "hub" relation will be more clearly defined in the next version of the PubsubHubbub specification, although I agree that the pointer from the registry should be to the specification itself, not the general website for the project.

[Ballot comment]
The document has a novel approach to expert review, with expiration of a timer
failing over to the IESG.

  Within at most 14 days of the request, the Designated Expert(s) will
  either approve or deny the registration request, communicating this
  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 can be brought to the IESG's attention (using the
  iesg@iesg.org mailing list) for resolution.

Vanilla expert review would be better...

As per discussion with Peter, I will deal with updating the "hub" registration (to get a better description and a more stable reference) post approval of this document.

[Note]: 'Julian Reschke <julian.reschke@greenbytes.de> is the document shepherd.
As per discussion with Peter, I will deal with updating the "hub" registration (to get a better description and a more stable reference) post approval of this document.' added by Alexey Melnikov

[Ballot discuss]
This is a good specification, and I support it becoming an RFC.
I did have one small issue, however. This ABNF definition:

  link-param        = ( ( "rel" "=" relation-types )
                    | ( "anchor" "=" <"> URI-Reference <"> )
                    | ( "rev" "=" relation-types )
                    | ( "hreflang" "=" Language-Tag )
                    | ( "media" "=" ( MediaDesc | <"> MediaDesc <"> ) )
                    | ( "title" "=" quoted-string )
                    | ( "title*" "=" ext-value )
                    | ( "type" "=" ( media-type | quoted-media-type ) )
                    | ( link-extension ) )

uses both | and sequencing on the definition of the "media=" attribute.
I do not see RFC 2616 explaining what the precedence rules are for
this version of ABNF, so I would suggest adding another set of
paranthesis:

                  | ( "media" "=" ( MediaDesc | ( <"> MediaDesc <"> )))

to avoid any confusion.

[Ballot discuss]
This ABNF definition:

  link-param        = ( ( "rel" "=" relation-types )
                    | ( "anchor" "=" <"> URI-Reference <"> )
                    | ( "rev" "=" relation-types )
                    | ( "hreflang" "=" Language-Tag )
                    | ( "media" "=" ( MediaDesc | <"> MediaDesc <"> ) )
                    | ( "title" "=" quoted-string )
                    | ( "title*" "=" ext-value )
                    | ( "type" "=" ( media-type | quoted-media-type ) )
                    | ( link-extension ) )

uses both | and sequencing on the definition of the "media=" attribute.
I do not see RFC 2616 explaining what the precedence rules are for
this version of ABNF, so I would suggest adding another set of
paranthesis:

                  | ( "media" "=" ( MediaDesc | ( <"> MediaDesc <"> )))

to avoid any confusion.

[Ballot discuss]
Should there be additional guidance to the expert reviewer on what to check for in the specification required by "Specification Required"? Is it sufficient for registration to have a document that contains only the template, or is that document expected to have more semantic content?

The answer to that may affect "first", "last", and "payment" in this document.

In either case, "hub" needs a more stable reference than googlecode.

[Ballot comment]
I concur with Tim Polk's concern regarding increased load on the IESG resulting from the (seemingly novel) 14-day rule for review of registration requests.

[Ballot discuss]
The reference for the "hub" relation type in the initial registration is "", however referencing a website does not appear to be consistent with "Specification Required" as mentioned in Section 6.2.1 and defined in RFC 5226. For consistency, it would be best for the person who requested this relation type to submit a brief Internet-Draft defining the relation, and for the initial registry contents to exclude the "hub" relation type pending submission of that Internet-Draft.

[Ballot comment]
I concur with Tim Polk's concern regarding increased load on the IESG resulting from the (seemingly novel) 14-day rule for review of registration requests.

[Ballot discuss]
The reference for the "hub" relation type in the initial registration is "", however referencing a website does not appear to be consistent with "Specification Required" as mentioned in Section 6.2.1 and defined in RFC 5226. For consistency, it would be best for the person who requested this relation type to submit a brief Internet-Draft defining the relation.

[Ballot discuss]
The reference for the "hub" relation type in the initial registration is "", however referencing a website does not appear to be consistent with "Specification Required" as mentioned in Section 6.2.1 and defined in RFC 5226. For consistency, it would be best for the person who requested this relation type to submit a brief Internet-Draft defining the relation.

[Ballot discuss]
This is placeholder discuss.

The author has agreed to make revisions to the security considerations as a result of the secdir review (http://www.ietf.org/mail-archive/web/secdir/current/msg01605.html).  Once these changes are incorporated, I will clear.

[Ballot discuss]
This is a discuss-discuss.  To be clear, I am not asking for any change in the document at this
time.

Is there any precedent for the following text?:

  Within at most 14 days of the request, the Designated Expert(s) will
  either approve or deny the registration request, communicating this
  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 can be brought to the IESG's attention (using the
  iesg@iesg.org mailing list) for resolution.

It sounds like the IESG could be fielding a lot of registration requests.

[Ballot discuss]
DISCUSS: Have the [TBD]@ietf.org and [TBD-2]@ietf.org mailing lists
  been created? If so, that needs to happen, and an RFC Editor Note
  needs to ask them to substitute the final names.


Section 2., paragraph 2:
>    This document uses the Augmented Backus-Naur Form (ABNF) notation of
>    [RFC2616], and explicitly includes the following rules from it:
>    quoted-string, token, SP (space), LOALPHA, DIGIT.

  DISCUSS: The ABNF in Section 5 is not valid under RFC4234. Is there a
  strong reason to use the non-standard ABNF flavor used in RFC2616
  here?

  (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?

1) Julian Reschke
2) Yes, and yes.

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

This document has been under development for several years now, and has
seen lots of reviews from several communities, such as HTTP, Atom, HTML,
and metadata related ones.
     
  (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?

No concerns.
               
  (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 interested community has discussed those issues and has
        indicated that it still wishes to advance the document, detail
        those concerns here.

No concerns (except for the nits that the AD himself just reported, mainly
the set of characters allowed in parameter values).       
       
  (1.e) How solid is the consensus of the interested community behind
        this document? Does it represent the strong concurrence of a few
        individuals, with others being silent, or does the interested
        community as a whole understand and agree with it?

I believe it represents strong consensus of several distinct communities.

The question of exactly how to discourage the use of the "rev" parameter
has required many iterations; the current language is believed to be
acceptable to all people involved.
       
  (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.)

No.
               
  (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?
       
See :

The nits reported are false positives or relate to xml2rfc shortcomings.

Exceptions:

  == Outdated reference: A later version (-10) exists of
    draft-reschke-rfc2231-in-http-09

(where -11 to be published soonish).

Also, not reported by ID-Nits:

- I-D.brown-versioning-link-relations is in AUTH48 will be published
as RFC 5829 very soon.
       
  (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].

$ saxon9 draft-nottingham-http-link-header-08.xml check-references.xslt       
Normative References:
draft-reschke-rfc2231-in-http-09: Alternate version available: 10
RFC2026: [BEST CURRENT PRACTICE] (-> BCP0009) ok
RFC2119: [BEST CURRENT PRACTICE] (-> BCP0014) ok
RFC2616: [DRAFT STANDARD] ok
RFC3864: [BEST CURRENT PRACTICE] (-> BCP0090) ok
RFC3986: [STANDARD] (-> STD0066) ok
RFC3987: [PROPOSED STANDARD] ok
RFC4288: [BEST CURRENT PRACTICE] (-> BCP0013) ok
RFC5226: [BEST CURRENT PRACTICE] (-> BCP0026) ok
RFC5646: [BEST CURRENT PRACTICE] (-> BCP0047) ok

Informative References:
draft-brown-versioning-link-relations-07: [2010-01-26 RFC-Editor] ok
RFC2068: [PROPOSED STANDARD] obsoleted by RFC2616
RFC4287: [PROPOSED STANDARD] ok
RFC4685: [PROPOSED STANDARD] ok
RFC4946: [EXPERIMENTAL] ok
RFC5005: [PROPOSED STANDARD] ok
RFC5023: [PROPOSED STANDARD] ok
CR-css3-mediaqueries-20090915: [CR] ok
CR-curie-20090116: [CR] ok
REC-html401-19991224: [REC] ok
REC-rdfa-syntax-20081014: [REC] ok
REC-xhtml-basic-20080729: [REC] ok
       
--> no problems.       
       
  (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

Yes.       

        reservations requested in appropriate IANA registries? Are the

Yes (grandfathering Atom link relation types)
       
        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?

Yes.       

        Does it suggested a reasonable name for the new registry? See

No!

        [I-D.narten-iana-considerations-rfc2434bis]. 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?

This has already happened while Lisa D. was responsible.       
       
  (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?

ABNF check:

-- snip --
$ saxon9 draft-nottingham-http-link-header-08.xml extract-artwork.xslt type=abnf2616 > not.abnf
$ $ bap -i core.abnf not.abnf
not.abnf(10:40): fyi: suggest DQUOTE or %x22 instead of <">.
not.abnf(10:58): fyi: suggest DQUOTE or %x22 instead of <">.
not.abnf(10:60): error: '/' is the alternation character in ABNF
not.abnf(16:53): fyi: suggest DQUOTE or %x22 instead of <">.
not.abnf(16:67): fyi: suggest DQUOTE or %x22 instead of <">.
not.abnf(48:25): fyi: suggest DQUOTE or %x22 instead of <">.
not.abnf(48:40): fyi: suggest DQUOTE or %x22 instead of <">.
not.abnf(52:23): fyi: suggest DQUOTE or %x22 instead of <">.
not.abnf(52:65): fyi: suggest DQUOTE or %x22 instead of <">.
not.abnf(60:4): error: syntax error

Link = "Link:" [ ( "," / link-value ) *( OWS "," [ OWS link-value ] ) ]
; URI-Reference UNDEFINED
link-value = "<" URI-Reference ">" *( ";" link-param )
; Language-Tag UNDEFINED
; MediaDesc UNDEFINED
; quoted-string UNDEFINED
; ext-value UNDEFINED
link-param = ( ( "rel=" relation-types ) / ( "anchor=" <"> URI-Reference <"> ) / ( "rev=" relation-types ) / ( "hreflang=" Language-Tag ) / ( "media=" ( MediaDesc / ( <"> MediaDesc <"> ) ) ) / ( "title=" quoted-string ) / ( "title*=" ext-value ) / ( "type=" ( media-type / quoted-media-type ) ) / link-extension )
; token UNDEFINED
link-extension = ( token [ "=" ( ptoken / quoted-string ) ] ) / ( ext-name-star "=" ext-value )
ext-name-star = token "*"
ptoken = "!" / "#" / "$" / "%" / "&" / "'" / "(" / ")" / "*" / "+" / "-" / "." / "/" / DIGIT / ":" / "<" / "=" / ">" / "?" / "@" / ALPHA / "[" / "\" / "]" / "^" / "_" / "`" / "{" / "|" / "}" / "~"
; type-name UNDEFINED
; subtype-name UNDEFINED
media-type = type-name "/" subtype-name
quoted-media-type = <"> media-type <">
relation-types = relation-type / ( <"> relation-type *( 1*SP relation-type ) <"> )
; ext-relation-type UNDEFINED
relation-type = reg-relation-type / ext-relation-type
; LOALPHA UNDEFINED
reg-relation-type = LOALPHA *( LOALPHA / DIGIT / "." / "-" )
; URI UNDEFINED
; Link defined but not used
parsing failed: 2 errors encountered
-- snip --

The reported issues are to be expected given the fact that the spec uses
the RFC2616 ABNF variant.

Checking the XML Relax NG syntax:

# artwork in XML source was augmented with type information
$ saxon9 draft-nottingham-http-link-header-08.xml extract-artwork.xslt type=application/relax-ng-compact-syntax > not.rnc
$ java -jar trang.jar -I rnc -O dtd not.rnc not.dtd
$ cat not.dtd













 
--> TRANG is happy, RNC seems to be ok

Checking the example:

# @name was added to spec source for extraction of artwork
$ saxon9 draft-nottingham-http-link-header-08.xml extract-artwork.xslt name=reg-example > not.xml
$ java -jar jing.jar -c not.rnc not.xml ; echo $?
0

-> JING has validated the example successfully.


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

    Technical Summary

        Relevant content can frequently be found in the abstract and/or
        introduction of the document. If not, this may be an
        indication that there are deficiencies in the abstract or
        introduction.

This document re-introduces the HTTP Link header (previously defined in the
obsoleted RFC 2068), and creates a protocol and format independent registry
of link relation types (replacing the Atom (RFC 4287) link type relation
registry).
       
    Working Group Summary

        Was there anything in the discussion in the interested
        community that is worth noting? For example, was there
        controversy about particular points or were there decisions
        where the consensus was particularly rough? Was the document
        considered in any WG, and if so, why was it not adopted as a
        work item there?

This document is not the product of any Working Group.

    Document Quality   

        Are there existing implementations of the protocol? Have a
        significant number of vendors indicated their plan to implement
        the specification? Are there any reviewers that merit special
        mention as having done a thorough review, e.g., one that
        resulted in important changes or a conclusion that the document
        had no substantive issues? If there was a MIB Doctor, Media
        Type or other expert review, what was its course (briefly)? In
        the case of a Media Type review, on what date was the request
        posted?   

Several browsers (Opera, Firefox) have been implementing a subset of the HTTP
link header syntaxg for the purpose of linking to stylesheets for a long time.

Other than that, additional implementations are known to be in process.

IANA comments:
ACTION 1:

IANA will make the following change to the "Permanent Message Header
Field Names" registry at
http://www.iana.org/assignments/message-headers/perm-headers.html

OLD:
Header Field Name Protocol Reference

Link http [RFC4229]

NEW:
Header Field Name Protocol Reference

Link http [RFC-nottingham-http-link-header-07]


ACTION 2:

IANA will replace the "Atom Link Relations" registry at
http://www.iana.org/assignments/link-relations/link-relations.xhtml
with the following:

Registry Name: Link Relation Types
Registration Procedures: Specification Required

o Relation Name: alternate
o Description: Designates a substitute for the link's context.
o Reference: [W3C.REC-html401-19991224]

o Relation Name: appendix
o Description: Refers to an appendix.
o Reference: [W3C.REC-html401-19991224]

o Relation Name: bookmark
o Description: Refers to a bookmark or entry point.
o Reference: [W3C.REC-html401-19991224]

o Relation Name: chapter
o Description: Refers to a chapter in a collection of resources.
o Reference: [W3C.REC-html401-19991224]

o Relation Name: contents
o Description: Refers to a table of contents.
o Reference: [W3C.REC-html401-19991224]

o Relation Name: copyright
o Description: Refers to a copyright statement that applies to the
link's context.
o Reference: [W3C.REC-html401-19991224]

o Relation Name: current
o Description: Refers to a resource containing the most recent
item(s) in a collection of resources.
o Reference: [RFC5005]

o Relation Name: describedby
o Description: Refers to a resource providing information about the
link's context.
o Documentation:

o Relation Name: edit
o Description: Refers to a resource that can be used to edit the
link's context.
o Reference: [RFC5023]

o Relation Name: edit-media
o Description: Refers to a resource that can be used to edit media
associated with the link's context.
o Reference: [RFC5023]

o Relation Name: enclosure
o Description: Identifies a related resource that is potentially
large and might require special handling.
o Reference: [RFC4287]

o Relation Name: first
o Description: An IRI that refers to the furthest preceding resource
in a series of resources.
o Reference: [this document]
o Notes: this relation type pre-exists this specification, and did
not indicate a reference. Originally requested by Mark Nottingham
in December 2004.

o Relation Name: glossary
o Description: Refers to a glossary of terms.
o Reference: [W3C.REC-html401-19991224]

o Relation Name: help
o Description: Refers to a resource offering help (more information,
links to other sources information, etc.)
o Reference: [W3C.REC-html401-19991224]

o Relation Name: index
o Description: Refers to an index.
o Reference: [W3C.REC-html401-19991224]

o Relation Name: last
o Description: An IRI that refers to the furthest following resource
in a series of resources.
o Reference: [this document]
o Notes: this relation type pre-exists this specification, and did
not indicate a reference. Originally requested by Mark Nottingham
in December 2004.

o Relation Name: license
o Description: Refers to a license associated with the link's
context.
o Reference: [RFC4946]

o Relation Name: next
o Description: Refers to the next resource in a ordered series of
resources.
o Reference: [W3C.REC-html401-19991224]

o Relation Name: next-archive
o Description: Refers to the immediately following archive resource.
o Reference: [RFC5005]

o Relation Name: payment
o Description: indicates a resource where payment is accepted.
o Reference: [this document]
o Notes: this relation type pre-exists this specification, and did
not indicate a reference. Requested by Joshua Kinberg and Robert
Sayre.

o Relation Name: prev
o Description: Refers to the previous resource in an ordered series
of resources. Synonym for "previous".
o Reference: [W3C.REC-html401-19991224]

o Relation Name: previous
o Description: Refers to the previous resource in an ordered series
of resources. Synonym for "prev".
o Reference: [W3C.REC-html401-19991224]

o Relation Name: prev-archive
o Description: Refers to the immediately preceding archive resource.
o Reference: [RFC5005]

o Relation Name: related
o Description: Identifies a related resource.
o Reference: [RFC4287]

o Relation Name: replies
o Description: Identifies a resource that is a reply to the context
of the link.
o Reference: [RFC4685]

o Relation Name: section
o Description: Refers to a section in a collection of resources.
o Reference: [W3C.REC-html401-19991224]

o Relation Name: self
o Description: Conveys an identifier for the link's context.
o Reference: [RFC4287]

o Relation Name: service
o Description: Indicates a URI that can be used to retrieve a
service document.
o Reference: [RFC5023]
o Notes: When used in an Atom document, this relation type specifies
Atom Publishing Protocol service documents by default. Requested
by James Snell.

o Relation Name: start
o Description: Refers to the first resource in a collection of
resources.
o Reference: [W3C.REC-html401-19991224]

o Relation Name: stylesheet
o Description: Refers to an external style sheet.
o Reference: [W3C.REC-html401-19991224]

o Relation Name: subsection
o Description: Refers to a resource serving as a subsection in a
collection of resources.
o Reference: [W3C.REC-html401-19991224]

o Relation Name: up
o Description: Refers to a parent document in a hierarchy of
documents.
o Reference: [this document]
o Notes: this relation type pre-exists this specification, and did
not indicate a reference. Requested by Noah Slater.

o Relation Name: via
o Description: Identifies a resource that is the source of the
information in the link's context.
o Reference: [RFC4287]


ACTION 3:

IANA will create the following registry at
http://www.iana.org/assignments/link-relations/link-relations.xhtml

Registry Name: Link Relation Field Registry
Registration Procedures: Specification Required

No initial registrations.

IANA questions/comments:

QUESTIONS:

- Is this document asking us to replace the Atom Link Relations registry
with a new registry? That is, should the current registry be removed?

- If so, the document appears to be asking us to make it the sole reference
for registrations that were made by individuals in the Atom Link Relations
registry. Is this possible?


ACTION 1:

IANA will make the follow change to the "Permanent Message Header Field
Names" registry at
http://www.iana.org/assignments/message-headers/perm-headers.html

OLD:
Header Field Name Protocol Reference

Link http [RFC4229]

NEW:
Header Field Name Protocol Reference

Link http [RFC-nottingham-http-link-header-06]


ACTION 2:

IANA will create the registry "Link Relation Types" located
http://www.iana.org/assignments/TBD
with the following content:

Registry Name: Link Relation Type
Reference: [RFC-nottingham-http-link-header-06]
Registration Procedures: Designated Expert with Specification Required

o Relation Name: alternate
o Description: Designates a substitute for the link's context.
o Reference: [W3C.REC-html401-19991224]

o Relation Name: appendix
o Description: Refers to an appendix.
o Reference: [W3C.REC-html401-19991224]

o Relation Name: bookmark
o Description: Refers to a bookmark or entry point.
o Reference: [W3C.REC-html401-19991224]

o Relation Name: chapter
o Description: Refers to a chapter in a collection of resources.
o Reference: [W3C.REC-html401-19991224]

o Relation Name: contents
o Description: Refers to a table of contents.
o Reference: [W3C.REC-html401-19991224]

o Relation Name: copyright
o Description: Refers to a copyright statement that applies to the
link's context.
o Reference: [W3C.REC-html401-19991224]

o Relation Name: current
o Description: Refers to a resource containing the most recent
item(s) in a collection of resources.
o Reference: [RFC5005]

o Relation Name: describedby
o Description: Refers to a resource providing information about the
link's context.
o Documentation:

o Relation Name: edit
o Description: Refers to a resource that can be used to edit the
link's context.
o Reference: [RFC5023]

o Relation Name: edit-media
o Description: Refers to a resource that can be used to edit media
associated with the link's context.
o Reference: [RFC5023]

o Relation Name: enclosure
o Description: Identifies a related resource that is potentially
large and might require special handling.
o Reference: [RFC4287]

o Relation Name: first
o Description: An IRI that refers to the furthest preceding resource
in a series of resources.
o Reference: [RFC-nottingham-http-link-header-06]

o Relation Name: glossary
o Description: Refers to a glossary of terms.
o Reference: [W3C.REC-html401-19991224]

o Relation Name: help
o Description: Refers to a resource offering help (more information,
links to other sources information, etc.)
o Reference: [W3C.REC-html401-19991224]

o Relation Name: index
o Description: Refers to an index.
o Reference: [W3C.REC-html401-19991224]

o Relation Name: last
o Description: An IRI that refers to the furthest following resource
in a series of resources.
o Reference: [RFC-nottingham-http-link-header-06]

o Relation Name: license
o Description: Refers to a license associated with the link's
context.
o Reference: [RFC4946]

o Relation Name: next
o Description: Refers to the next resource in a ordered series of
resources.
o Reference: [W3C.REC-html401-19991224]

o Relation Name: next-archive
o Description: Refers to the immediately following archive resource.
o Reference: [RFC5005]

o Relation Name: payment
o Description: indicates a resource where payment is accepted.
o Reference: [RFC-nottingham-http-link-header-06]

o Relation Name: prev
o Description: Refers to the previous resource in an ordered series
of resources. Synonym for "previous".
o Reference: [W3C.REC-html401-19991224]

o Relation Name: previous
o Description: Refers to the previous resource in an ordered series
of resources. Synonym for "prev".
o Reference: [W3C.REC-html401-19991224]

o Relation Name: prev-archive
o Description: Refers to the immediately preceding archive resource.
o Reference: [RFC5005]

o Relation Name: related
o Description: Identifies a related resource.
o Reference: [RFC4287]

o Relation Name: replies
o Description: Identifies a resource that is a reply to the context
of the link.
o Reference: [RFC4685]

o Relation Name: section
o Description: Refers to a section in a collection of resources.
o Reference: [W3C.REC-html401-19991224]

o Relation Name: self
o Description: Conveys an identifier for the link's context.
o Reference: [RFC4287]

o Relation Name: service
o Description: Indicates a URI that can be used to retrieve a
service document.
o Reference: [RFC5023]
o Notes: When used in an Atom document, this relation specifies Atom
Publishing Protocol service documents by default.

o Relation Name: start
o Description: Refers to the first resource in a collection of
resources.
o Reference: [W3C.REC-html401-19991224]

o Relation Name: stylesheet
o Description: Refers to an external style sheet.
o Reference: [W3C.REC-html401-19991224]

o Relation Name: subsection
o Description: Refers to a resource serving as a subsection in a
collection of resources.
o Reference: [W3C.REC-html401-19991224]

o Relation Name: up
o Description: Refers to a parent document in a hierarchy of
documents.
o Reference: [RFC-nottingham-http-link-header-06]

o Relation Name: via
o Description: Identifies a resource that is the source of the
information in the link's context.
o Reference: [RFC4287]