< draft-nottingham-http-link-header-07.txt   draft-nottingham-http-link-header-08.txt >
Network Working Group M. Nottingham Network Working Group M. Nottingham
Internet-Draft January 19, 2010 Internet-Draft March 1, 2010
Updates: 4287 (if approved) Updates: 4287 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: July 23, 2010 Expires: September 2, 2010
Web Linking Web Linking
draft-nottingham-http-link-header-07 draft-nottingham-http-link-header-08
Abstract Abstract
This document specifies relation types for Web links, and defines a This document specifies relation types for Web links, and defines a
registry for them. It also defines the use of such links in HTTP registry for them. It also defines the use of such links in HTTP
headers with the Link header-field. headers with the Link header-field.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 23, 2010. This Internet-Draft will expire on September 2, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 16 skipping to change at page 3, line 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3
3. Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Link Relation Types . . . . . . . . . . . . . . . . . . . . . 4 4. Link Relation Types . . . . . . . . . . . . . . . . . . . . . 4
4.1. Registered Relation Types . . . . . . . . . . . . . . . . 5 4.1. Registered Relation Types . . . . . . . . . . . . . . . . 5
4.2. Extension Relation Types . . . . . . . . . . . . . . . . . 6 4.2. Extension Relation Types . . . . . . . . . . . . . . . . . 6
5. The Link Header Field . . . . . . . . . . . . . . . . . . . . 6 5. The Link Header Field . . . . . . . . . . . . . . . . . . . . 6
5.1. Target IRI . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Target IRI . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Context IRI . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Context IRI . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Relation Type . . . . . . . . . . . . . . . . . . . . . . 7 5.3. Relation Type . . . . . . . . . . . . . . . . . . . . . . 8
5.4. Target Attributes . . . . . . . . . . . . . . . . . . . . 7 5.4. Target Attributes . . . . . . . . . . . . . . . . . . . . 8
5.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6.1. Link HTTP Header Registration . . . . . . . . . . . . . . 9 6.1. Link HTTP Header Registration . . . . . . . . . . . . . . 10
6.2. Link Relation Type Registry . . . . . . . . . . . . . . . 10 6.2. Link Relation Type Registry . . . . . . . . . . . . . . . 10
6.3. Link Relation Field Registry . . . . . . . . . . . . . . . 14 6.3. Link Relation Application Data Registry . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. Internationalisation Considerations . . . . . . . . . . . . . 16 8. Internationalisation Considerations . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Link Relation Registry Format . . . . . . . . . . . . 18 Appendix A. Link Relation Registry Format . . . . . . . . . . . . 20
A.1. Relax NG Grammar . . . . . . . . . . . . . . . . . . . . . 18 A.1. Relax NG Grammar . . . . . . . . . . . . . . . . . . . . . 20
A.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 19 A.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 21
Appendix B. Notes on Using the Link Header with the HTML4 Appendix B. Notes on Using the Link Header with the HTML4
Format . . . . . . . . . . . . . . . . . . . . . . . 19 Format . . . . . . . . . . . . . . . . . . . . . . . 21
Appendix C. Notes on Using the Link Header with the Atom Appendix C. Notes on Using the Link Header with the Atom
Format . . . . . . . . . . . . . . . . . . . . . . . 20 Format . . . . . . . . . . . . . . . . . . . . . . . 22
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 21 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 23
Appendix E. Document history . . . . . . . . . . . . . . . . . . 21 Appendix E. Document history . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
A means of indicating the relationships between resources on the Web, A means of indicating the relationships between resources on the Web,
as well as indicating the type of those relationships, has been as well as indicating the type of those relationships, has been
available for some time in HTML [W3C.REC-html401-19991224], and more available for some time in HTML [W3C.REC-html401-19991224], and more
recently in Atom [RFC4287]. These mechanisms, although conceptually recently in Atom [RFC4287]. These mechanisms, although conceptually
similar, are separately specified. However, links between resources similar, are separately specified. However, links between resources
need not be format-specific; it can be useful to have typed links need not be format-specific; it can be useful to have typed links
that are independent of their serialisation, especially when a that are independent of their serialisation, especially when a
resource has representations in multiple formats. resource has representations in multiple formats.
To this end, this document defines a framework for typed links that To this end, this document defines a framework for typed links that
isn't specific to a particular serialisation or application. It does isn't specific to a particular serialisation or application. It does
so by re-defining the link relation registry established by Atom to so by re-defining the link relation registry established by Atom to
have a broader domain, and adding to it the relations that are have a broader domain, and adding to it the relations that are
defined by HTML. defined by HTML.
Furthermore, an HTTP header-field for conveying typed links was Furthermore, an HTTP header-field for conveying typed links was
defined in [RFC2068], but removed from [RFC2616], due to a lack of defined in Section 19.6.2.4 of [RFC2068], but removed from [RFC2616],
implementation experience. Since then, it has been implemented in due to a lack of implementation experience. Since then, it has been
some User-Agents (e.g., for stylesheets), and several additional use implemented in some User-Agents (e.g., for stylesheets), and several
cases have surfaced. additional use cases have surfaced.
Because it was removed, the status of the Link header is unclear, Because it was removed, the status of the Link header is unclear,
leading some to consider minting new application-specific HTTP leading some to consider minting new application-specific HTTP
headers instead of reusing it. This document addresses this by re- headers instead of reusing it. This document addresses this by re-
specifying the Link header as one such serialisation, with updated specifying the Link header as one such serialisation, with updated
but backwards-compatible syntax. but backwards-compatible syntax.
[[ Feedback is welcome on the ietf-http-wg@w3.org mailing list,
although this is NOT a work item of the HTTPBIS WG. ]]
2. Notational Conventions 2. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, [RFC2119], as document are to be interpreted as described in BCP 14, [RFC2119], as
scoped to those conformance targets. scoped to those conformance targets.
This document uses the Augmented Backus-Naur Form (ABNF) notation of This document uses the Augmented Backus-Naur Form (ABNF) notation of
[RFC2616], and explicitly includes the following rules from it: [RFC2616], and explicitly includes the following rules from it:
quoted-string, token, SP (space), LOALPHA, DIGIT. quoted-string, token, SP (space), LOALPHA, DIGIT.
Additionally, the following rules are included from [RFC3986]: URI Additionally, the following rules are included from [RFC3986]: URI
and URI-Reference; from [RFC4288]: type-name and subtype-name; from and URI-Reference; from [RFC4288]: type-name and subtype-name; from
[W3C.REC-html401-19991224]: MediaDesc, and from [RFC4646]: Language- [W3C.REC-html401-19991224]: MediaDesc; from [RFC5646]: Language-Tag;
Tag. and from [I-D.reschke-rfc2231-in-http], ext-value.
3. Links 3. Links
In this specification, a link is a typed connection between two In this specification, a link is a typed connection between two
resources that are identified by IRIs [RFC3987], and is comprised of: resources that are identified by IRIs [RFC3987], and is comprised of:
o A context IRI, and o A context IRI, and
o a link relation type (Section 4), and o a link relation type (Section 4), and
o a target IRI, and o a target IRI, and
o optionally, target attributes. o optionally, target attributes.
skipping to change at page 6, line 39 skipping to change at page 6, line 39
rule, and MUST be compared character-by-character in a case- rule, and MUST be compared character-by-character in a case-
insensitive fashion. They SHOULD be appropriate to the specificity insensitive fashion. They SHOULD be appropriate to the specificity
of the relation type; i.e., if the semantics are highly specific to a of the relation type; i.e., if the semantics are highly specific to a
particular application, the name should reflect that, so that more particular application, the name should reflect that, so that more
general names are available for less specific use. general names are available for less specific use.
Registered relation types MUST NOT constrain the media type of the Registered relation types MUST NOT constrain the media type of the
context IRI, and MUST NOT constrain the available representation context IRI, and MUST NOT constrain the available representation
media types of the target IRI. However, they MAY specify the media types of the target IRI. However, they MAY specify the
behaviours and properties of the target resource (e.g., allowable behaviours and properties of the target resource (e.g., allowable
methods, request and response media types which must be supported). HTTP methods, request and response media types which must be
supported).
Additionally, specific applications of linking may have additional Additionally, specific applications of linking may require additional
per-relation type attributes which are advantageous to register. For data to be included in the registry. For example, Web browsers might
example, some link relations might not be appropriate to use in want to know what kinds of links should be downloaded when they
particular contexts, or might have common behaviour such as whether archive a Web page; if this application-specific information is in
their content should be archived with the page. To accommodate this, the registry, new link relation types can control this behaviour
new per-entry fields MAY be added to the registry, by registering without unnecessary coordination.
them in the Link Relation Field Registry Section 6.3.
To accommodate this, per-entry application data MAY be added to the
Link Relation Type Registry, by registering it in the Link Relation
Application Data Registry (Section 6.3).
4.2. Extension Relation Types 4.2. Extension Relation Types
Applications that don't wish to register a relation type may use an Applications that don't wish to register a relation type may use an
extension relation type, which is a URI [RFC3986] that uniquely extension relation type, which is a URI [RFC3986] that uniquely
identifies the relation type. Although the URI can point to a identifies the relation type. Although the URI can point to a
resource that contains a definition of the semantics of the relation resource that contains a definition of the semantics of the relation
type, clients SHOULD NOT automatically access that resource to avoid type, clients SHOULD NOT automatically access that resource to avoid
overburdening its server. overburdening its server.
When extension relation types are compared, they MUST be compared as When extension relation types are compared, they MUST be compared as
URIs in a case-insensitive fashion, character-by-character. Because strings (after converting to URIs if serialised in a different
of this, all-lowercase URIs SHOULD be used for extension relations. format, such as a Curie [W3C.CR-curie-20090116]) in a case-
insensitive fashion, character-by-character. Because of this, all-
lowercase URIs SHOULD be used for extension relations.
Note that while extension relation types are required to be URIs, a Note that while extension relation types are required to be URIs, a
serialisation of links MAY specify that they are expressed in another serialisation of links can specify that they are expressed in another
form, as long as they can be converted to URIs. form, as long as they can be converted to URIs.
5. The Link Header Field 5. The Link Header Field
The Link entity-header field provides a means for serialising one or The Link entity-header field provides a means for serialising one or
more links in HTTP headers. It is semantically equivalent to the more links in HTTP headers. It is semantically equivalent to the
<LINK> element in HTML, as well as the atom:link feed-level element <LINK> element in HTML, as well as the atom:link feed-level element
in Atom [RFC4287]. in Atom [RFC4287].
Link = "Link" ":" #link-value Link = "Link" ":" #link-value
link-value = "<" URI-Reference ">" *( ";" link-param ) link-value = "<" URI-Reference ">" *( ";" link-param )
link-param = ( ( "rel" "=" relation-types ) link-param = ( ( "rel" "=" relation-types )
| ( "anchor" "=" <"> URI-Reference <"> ) | ( "anchor" "=" <"> URI-Reference <"> )
| ( "rev" "=" relation-types ) | ( "rev" "=" relation-types )
| ( "hreflang" "=" Language-Tag ) | ( "hreflang" "=" Language-Tag )
| ( "media" "=" ( MediaDesc | <"> MediaDesc <"> ) ) | ( "media" "=" ( MediaDesc | <"> MediaDesc <"> ) )
| ( "title" "=" quoted-string ) | ( "title" "=" quoted-string )
| ( "title*" "=" enc2231-string ) | ( "title*" "=" ext-value )
| ( "type" "=" type-name "/" subtype-name ) | ( "type" "=" ( media-type | quoted-media-type ) )
| ( link-extension ) ) | ( link-extension ) )
link-extension = token [ "=" ( token | quoted-string ) ] link-extension = ( token [ "=" ( ptoken | quoted-string ) ] )
enc2231-string = <extended-initial-value [RFC2231] Section 7> | ( ext-name-star "=" ext-value )
ext-name-star = token "*" ; reserved for RFC2231-profiled
; extensions. Whitespace NOT
; allowed in between.
ptoken = "!" | "#" | "$" | "%" | "&" | "'" | "("
| ")" | "*" | "+" | "-" | "." | "/" | DIGIT
| ":" | "<" | "=" | ">" | "?" | "@" | ALPHA
| "[" | "\" | "]" | "^" | "_" | "`" | "{"
| "|" | "}" | "~"
media-type = type-name "/" subtype-name
quoted-media-type = <"> media-type <">
relation-types = relation-type | relation-types = relation-type |
<"> relation-type *( 1*SP relation-type ) <"> <"> relation-type *( 1*SP relation-type ) <">
relation-type = reg-relation-type | ext-relation-type relation-type = reg-relation-type | ext-relation-type
reg-relation-type = LOALPHA *( LOALPHA | DIGIT | "." | "-" ) reg-relation-type = LOALPHA *( LOALPHA | DIGIT | "." | "-" )
ext-relation-type = URI ext-relation-type = URI
5.1. Target IRI 5.1. Target IRI
Each link-value conveys one target IRI as a URI-Reference (after Each link-value conveys one target IRI as a URI-Reference (after
conversion to one, if necessary; see [RFC3987], Section 3.1) inside conversion to one, if necessary; see [RFC3987], Section 3.1) inside
angle brackets ("<>"). If the URI-Reference is relative, parsers angle brackets ("<>"). If the URI-Reference is relative, parsers
MUST resolve it as per [RFC3986], Section 5. Note that any base IRI MUST resolve it as per [RFC3986], Section 5. Note that any base IRI
from the message's content is not applied. from the message's content is not applied.
5.2. Context IRI 5.2. Context IRI
By default, the context of a link conveyed in the Link header field By default, the context of a link conveyed in the Link header field
is the IRI of the requested resource. is the IRI of the requested resource.
When present and explicitly specified by use by an application, the When present, the anchor parameter overrides this with another URI,
anchor parameter overrides this with another URI, such as a fragment such as a fragment of this resource, or a third resource (i.e., when
of this resource, or a third resource (i.e., when the anchor value is the anchor value is an absolute URI). If the anchor parameter's
an absolute URI). If the anchor parameter's value is a relative URI, value is a relative URI, parsers MUST resolve it as per [RFC3986],
parsers MUST resolve it as per [RFC3986], Section 5. Note that any Section 5. Note that any base URI from the body's content is not
base URI from the body's content is not applied. applied.
The anchor parameter MUST be ignored by consuming implementations, Consuming implementations may choose to ignore links with an anchor
unless its use is specified by the application in use. parameter. For example, the application in use may not allow the
context IRI to be assigned to a different resource. In such cases,
the entire link is to be ignored; consuming implementations MUST NOT
process the link without applying the anchor.
Note that depending on HTTP status code and response headers, the
context IRI might be "anonymous" (i.e., no context IRI is available).
For instance, this is the case on a 404 response to a GET request.
5.3. Relation Type 5.3. Relation Type
The relation type of a link is conveyed in the "rel" parameter's The relation type of a link is conveyed in the "rel" parameter's
value. Note that the "rev" parameter has also been used by some value. The "rel" parameter MUST NOT appear more than once in a given
formats, and MAY be accommodated as a link-extension, but its use is link-value; occurrences after the first MUST be ignored by parsers.
neither encouraged nor defined by this specification.
The "rel" parameter MUST NOT appear more than once in a given link- The "rev" parameter has been used in the past to indicate that the
value; occurrences after the first MUST be ignored by parsers. semantics of the relationship are in the reverse direction. I.e., a
link from A to B with REL="X" expresses the same relationship as a
link from B to A with REV="X". "rev" is deprecated by this
specification because it often confuses authors and readers; in most
cases using a separate relation type is preferable.
Note that extension relation types are REQUIRED to be absolute URIs Note that extension relation types are REQUIRED to be absolute URIs
in Link headers, and MUST be quoted if they contain a semicolon (";") in Link headers, and MUST be quoted if they contain a semicolon (";")
or comma (","). or comma (",") (as these characters are used as delimiters in the
header itself).
5.4. Target Attributes 5.4. Target Attributes
The "hreflang", "media", "title", "title*", "type" and any link- The "hreflang", "media", "title", "title*", "type" and any link-
extension link-params are considered to be target attributes for the extension link-params are considered to be target attributes for the
link. link.
The "hreflang" parameter, when present, is a hint indicating what the The "hreflang" parameter, when present, is a hint indicating what the
language of the result of dereferencing the link should be. Note language of the result of dereferencing the link should be. Note
that this is only a hint; for example, it does not override the that this is only a hint; for example, it does not override the
Content-Language header of a HTTP response obtained by actually Content-Language header of a HTTP response obtained by actually
following the link. Multiple hreflang parameters on a single link- following the link. Multiple hreflang parameters on a single link-
value indicate that multiple languages are available from the value indicate that multiple languages are available from the
indicated resource. indicated resource.
The "media" parameter, when present, is used to indicate intended The "media" parameter, when present, is used to indicate intended
destination medium or media for style information (see destination medium or media for style information (see
[W3C.REC-html401-19991224], Section 6.13. Note that this may be [W3C.REC-html401-19991224], Section 6.13). Note that this may be
updated by [W3C.CR-css3-mediaqueries-20090915]). Its value MUST be updated by [W3C.CR-css3-mediaqueries-20090915]). Its value MUST be
quoted if it contains a semicolon (";") or comma (","), and there quoted if it contains a semicolon (";") or comma (","), and there
MUST NOT be more than one media parameter in a link-value. MUST NOT be more than one media parameter in a link-value.
The "title" parameter, when present, is used to label the destination The "title" parameter, when present, is used to label the destination
of a link such that it can be used as a human-readable identifier of a link such that it can be used as a human-readable identifier
(e.g. a menu entry). The "title" parameter MUST NOT appear more than (e.g. a menu entry). The "title" parameter MUST NOT appear more than
once in a given link-value; occurrences after the first MUST be once in a given link-value; occurrences after the first MUST be
ignored by parsers. ignored by parsers.
The "title*" parameter MAY be used encode this label in a different The "title*" parameter MAY be used to encode this label in a
character set, and/or contain language information as per [RFC2231]. different character set, and/or contain language information as per
When using the enc2231-string syntax, producers MUST NOT use a [I-D.reschke-rfc2231-in-http]. The "title*" parameter MAY appear
charset value other than 'ISO-8859-1' or 'UTF-8'. The "title*" more than once in a given link-value, but each occurrence MUST
parameter MAY appear more than once in a given link-value, but each indicate a different language; occurrences after the first for a
occurrence MUST indicate a different language; occurrences after the given language MUST be ignored by parsers.
first for a given language MUST be ignored by parsers.
When presenting links to users, agents SHOULD use the most When presenting links to users, agents SHOULD use the most
appropriate "title*" value, according to user preferences. If an appropriate "title*" value, according to user preferences. If an
appropriate "title*" value cannot be found, the "title" parameter's appropriate "title*" value cannot be found, the "title" parameter's
value, if available, can be used. value, if available, can be used.
The "type" parameter, when present, is a hint indicating what the The "type" parameter, when present, is a hint indicating what the
media type of the result of dereferencing the link should be. Note media type of the result of dereferencing the link should be. Note
that this is only a hint; for example, it does not override the that this is only a hint; for example, it does not override the
Content-Type header of a HTTP response obtained by actually following Content-Type header of a HTTP response obtained by actually following
skipping to change at page 11, line 32 skipping to change at page 12, line 21
The requirements for registered relation types are described in The requirements for registered relation types are described in
Section 4.1. Section 4.1.
Registration requests consist of the completed registration template Registration requests consist of the completed registration template
below, typically published in an RFC or Open Standard (in the sense below, typically published in an RFC or Open Standard (in the sense
described by [RFC2026], Section 7). However, to allow for the described by [RFC2026], Section 7). However, to allow for the
allocation of values prior to publication, the Designated Expert may allocation of values prior to publication, the Designated Expert may
approve registration once they are satisfied that a specification approve registration once they are satisfied that a specification
will be published. will be published.
Note that relation types can be registered by third parties, if the
Designated Expert determines that an unregistered relation type is
widely deployed and not likely to be registered in a timely manner.
The registration template is: The registration template is:
o Relation Name: o Relation Name:
o Description: o Description:
o Reference: o Reference:
o Notes: [optional] o Notes: [optional]
o Fields: [optional] o Application Data: [optional]
Registration requests should be sent to the [TBD]@ietf.org mailing Registration requests should be sent to the [TBD]@ietf.org mailing
list, marked clearly in the subject line (e.g,. "NEW RELATION list, marked clearly in the subject line (e.g,. "NEW RELATION
REQUEST"). REQUEST").
Within at most 14 days of the request, the Designated Expert(s) will Within at most 14 days of the request, the Designated Expert(s) will
either approve or deny the registration request, communicating this either approve or deny the registration request, communicating this
decision to the review list. Denials should include an explanation decision to the review list. Denials should include an explanation
and, if applicable, suggestions as to how to make the request and, if applicable, suggestions as to how to make the request
successful. Registration requests that are undetermined for a period successful. Registration requests that are undetermined for a period
longer than 21 days can be brought to the IESG's attention (using the longer than 21 days can be brought to the IESG's attention (using the
iesg@iesg.org mailing list) for resolution. iesg@iesg.org mailing list) for resolution.
When a registration request is successful, the Designated Expert(s) When a registration request is successful, the Designated Expert(s)
will update the registry XML file (using the format described in will update the registry XML file (using the format described in
Appendix A and send it to the [TBD-2]@ietf.org mailing list (which Appendix A including the MIT license) and send it to the [TBD-2]@
SHOULD NOT be centrally archived, and only accept posts from the ietf.org mailing list (which SHOULD NOT be centrally archived, and
Designated Expert(s)), so that implementers interested in receiving a only accept posts from the Designated Expert(s)), so that
machine-readable registry can do so. Simultaneously, they will send implementers interested in receiving a machine-readable registry can
a text (not XML) version of the registry to IANA for publication. do so. Simultaneously, they will send a text (not XML) version of
the registry to IANA for publication.
IANA should only accept registry updates from the Designated IANA should only accept registry updates from the Designated
Expert(s), and should direct all requests for registration to the Expert(s), and should direct all requests for registration to the
review mailing list. review mailing list.
6.2.2. Initial Registry Contents 6.2.2. Initial Registry Contents
The Link Relation Type registry's initial contents are: The Link Relation Type registry's initial contents are:
o Relation Name: alternate o Relation Name: alternate
skipping to change at page 13, line 27 skipping to change at page 14, line 21
o Relation Name: enclosure o Relation Name: enclosure
o Description: Identifies a related resource that is potentially o Description: Identifies a related resource that is potentially
large and might require special handling. large and might require special handling.
o Reference: [RFC4287] o Reference: [RFC4287]
o Relation Name: first o Relation Name: first
o Description: An IRI that refers to the furthest preceding resource o Description: An IRI that refers to the furthest preceding resource
in a series of resources. in a series of resources.
o Reference: [this document] o Reference: [this document]
o Notes: this relation type pre-exists this specification, and did o Notes: this relation type registration did not indicate a
not indicate a reference. Originally requested by Mark Nottingham reference. Originally requested by Mark Nottingham in December
in December 2004. 2004.
o Relation Name: glossary o Relation Name: glossary
o Description: Refers to a glossary of terms. o Description: Refers to a glossary of terms.
o Reference: [W3C.REC-html401-19991224] o Reference: [W3C.REC-html401-19991224]
o Relation Name: help o Relation Name: help
o Description: Refers to a resource offering help (more information, o Description: Refers to a resource offering help (more information,
links to other sources information, etc.) links to other sources information, etc.)
o Reference: [W3C.REC-html401-19991224] o Reference: [W3C.REC-html401-19991224]
o Relation Name: hub
o Description: Refers to a hub that enables registration for
notification of updates to the context.
o Reference: <http://pubsubhubbub.googlecode.com/>
o Notes: this relation type was requested by Brett Slakin.
o Relation Name: index o Relation Name: index
o Description: Refers to an index. o Description: Refers to an index.
o Reference: [W3C.REC-html401-19991224] o Reference: [W3C.REC-html401-19991224]
o Relation Name: last o Relation Name: last
o Description: An IRI that refers to the furthest following resource o Description: An IRI that refers to the furthest following resource
in a series of resources. in a series of resources.
o Reference: [this document] o Reference: [this document]
o Notes: this relation type pre-exists this specification, and did o Notes: this relation type registration did not indicate a
not indicate a reference. Originally requested by Mark Nottingham reference. Originally requested by Mark Nottingham in December
in December 2004. 2004.
o Relation Name: latest-version
o Description: Points to a resource containing the latest (e.g.,
current) version of the context.
o Reference: [I-D.brown-versioning-link-relations]
o Relation Name: license o Relation Name: license
o Description: Refers to a license associated with the link's o Description: Refers to a license associated with the link's
context. context.
o Reference: [RFC4946] o Reference: [RFC4946]
o Relation Name: next o Relation Name: next
o Description: Refers to the next resource in a ordered series of o Description: Refers to the next resource in a ordered series of
resources. resources.
o Reference: [W3C.REC-html401-19991224] o Reference: [W3C.REC-html401-19991224]
o Relation Name: next-archive o Relation Name: next-archive
o Description: Refers to the immediately following archive resource. o Description: Refers to the immediately following archive resource.
o Reference: [RFC5005] o Reference: [RFC5005]
o Relation Name: payment o Relation Name: payment
o Description: indicates a resource where payment is accepted. o Description: indicates a resource where payment is accepted.
o Reference: [this document] o Reference: [this document]
o Notes: this relation type pre-exists this specification, and did o Notes: this relation type registration did not indicate a
not indicate a reference. Requested by Joshua Kinberg and Robert reference. Requested by Joshua Kinberg and Robert Sayre.
Sayre.
o Relation Name: prev o Relation Name: prev
o Description: Refers to the previous resource in an ordered series o Description: Refers to the previous resource in an ordered series
of resources. Synonym for "previous". of resources. Synonym for "previous".
o Reference: [W3C.REC-html401-19991224] o Reference: [W3C.REC-html401-19991224]
o Relation Name: predecessor-version
o Description: Points to a resource containing the predecessor
version in the version history.
o Reference: [I-D.brown-versioning-link-relations]
o Relation Name: previous o Relation Name: previous
o Description: Refers to the previous resource in an ordered series o Description: Refers to the previous resource in an ordered series
of resources. Synonym for "prev". of resources. Synonym for "prev".
o Reference: [W3C.REC-html401-19991224] o Reference: [W3C.REC-html401-19991224]
o Relation Name: prev-archive o Relation Name: prev-archive
o Description: Refers to the immediately preceding archive resource. o Description: Refers to the immediately preceding archive resource.
o Reference: [RFC5005] o Reference: [RFC5005]
o Relation Name: related o Relation Name: related
skipping to change at page 15, line 33 skipping to change at page 16, line 42
o Relation Name: stylesheet o Relation Name: stylesheet
o Description: Refers to an external style sheet. o Description: Refers to an external style sheet.
o Reference: [W3C.REC-html401-19991224] o Reference: [W3C.REC-html401-19991224]
o Relation Name: subsection o Relation Name: subsection
o Description: Refers to a resource serving as a subsection in a o Description: Refers to a resource serving as a subsection in a
collection of resources. collection of resources.
o Reference: [W3C.REC-html401-19991224] o Reference: [W3C.REC-html401-19991224]
o Relation Name: successor-version
o Description: Points to a resource containing the successor version
in the version history.
o Reference: [I-D.brown-versioning-link-relations]
o Relation Name: up o Relation Name: up
o Description: Refers to a parent document in a hierarchy of o Description: Refers to a parent document in a hierarchy of
documents. documents.
o Reference: [this document] o Reference: [this document]
o Notes: this relation type pre-exists this specification, and did o Notes: this relation type registration did not indicate a
not indicate a reference. Requested by Noah Slater. reference. Requested by Noah Slater.
o Relation Name: version-history
o Description: points to a resource containing the version history
for the context.
o Reference: [I-D.brown-versioning-link-relations]
o Relation Name: via o Relation Name: via
o Description: Identifies a resource that is the source of the o Description: Identifies a resource that is the source of the
information in the link's context. information in the link's context.
o Reference: [RFC4287] o Reference: [RFC4287]
6.3. Link Relation Field Registry o Relation Name: working-copy
o Description: Points to a working copy for this resource.
o Reference: [I-D.brown-versioning-link-relations]
This specification also establishes the Link Relation Field Registry, o Relation Name: working-copy-of
to allow entries in the Link Relation Type Registry to be extended o Description: Points to the versioned resource from which this
with application-specific data (hereafter, "fields"). working copy was obtained.
o Reference: [I-D.brown-versioning-link-relations]
Fields are registered on the advice of a Designated Expert (appointed 6.3. Link Relation Application Data Registry
by the IESG or their delegate), with a Specification Required (using
terminology from [RFC5226]). This specification also establishes the Link Relation Application
Field Registry, to allow entries in the Link Relation Type Registry
to be extended with application-specific data (hereafter, "app data")
specific to all instances of a given link relation type.
Application data is registered on the advice of a Designated Expert
(appointed by the IESG or their delegate), with a Specification
Required (using terminology from [RFC5226]).
Registration requests consist of the completed registration template Registration requests consist of the completed registration template
below; below;
o Field Name: o Application Name:
o Description: o Description:
o Default Value: o Default Value:
o Notes: [optional] o Notes: [optional]
The Description SHOULD identify the value space of the field. The The Description SHOULD identify the value space of the app data. The
Default Value MUST be appropriate to entries which the field does not Default Value MUST be appropriate to entries which the app data does
apply to. not apply to.
Entries that pre-date the addition of a field will automatically be Entries that pre-date the addition of app data will automatically be
considered to have the default value for that field; if there are considered to have the default value for that app data; if there are
exceptions, the modification of such entries should be coordinated by exceptions, the modification of such entries should be coordinated by
the Designated Expert(s), in consultation with the author of the the Designated Expert(s), in consultation with the author of the
proposed field as well as the registrant of the existing entry (if proposed app data as well as the registrant of the existing entry (if
possible). possible).
Registration requests should be sent to the [TBD]@ietf.org mailing Registration requests should be sent to the [TBD]@ietf.org mailing
list, marked clearly in the subject line (e.g,. "NEW EXTENSION list, marked clearly in the subject line (e.g,. "NEW APP DATA").
FIELD").
Within at most 14 days of the request, the Designated Expert will Within at most 14 days of the request, the Designated Expert will
either approve or deny the registration request, communicating this either approve or deny the registration request, communicating this
decision to the review list. Denials should include an explanation decision to the review list. Denials should include an explanation
and, if applicable, suggestions as to how to make the request and, if applicable, suggestions as to how to make the request
successful. Registration requests that are undetermined for a period successful. Registration requests that are undetermined for a period
longer than 21 days MAY be brought to the IESG's attention (using the longer than 21 days MAY be brought to the IESG's attention (using the
iesg@iesg.org mailing list) for resolution. iesg@iesg.org mailing list) for resolution.
When a registration request is successful, the Designated Expert will When a registration request is successful, the Designated Expert will
skipping to change at page 17, line 25 skipping to change at page 19, line 9
there. there.
Relation types are defined as URIs, not IRIs, to aid in their Relation types are defined as URIs, not IRIs, to aid in their
comparison. It is not expected that they will be displayed to end comparison. It is not expected that they will be displayed to end
users. users.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.reschke-rfc2231-in-http]
Reschke, J., "Application of RFC 2231 Encoding to
Hypertext Transfer Protocol (HTTP) Header Fields",
draft-reschke-rfc2231-in-http-09 (work in progress),
February 2010.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996. 3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
Word Extensions: Character Sets, Languages, and
Continuations", RFC 2231, November 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004. September 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005. Identifiers (IRIs)", RFC 3987, January 2005.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005. Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", BCP 47, RFC 4646, September 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", BCP 47, RFC 5646, September 2009.
9.2. Informative References 9.2. Informative References
[I-D.brown-versioning-link-relations]
Brown, A., Clemm, G., and J. Reschke, "Link Relation Types
for Simple Version Navigation between Web Resources",
draft-brown-versioning-link-relations-07 (work in
progress), January 2010.
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
RFC 2068, January 1997. RFC 2068, January 1997.
[RFC4287] Nottingham, M. and R. Sayre, "The Atom Syndication [RFC4287] Nottingham, M. and R. Sayre, "The Atom Syndication
Format", RFC 4287, December 2005. Format", RFC 4287, December 2005.
[RFC4685] Snell, J., "Atom Threading Extensions", RFC 4685, [RFC4685] Snell, J., "Atom Threading Extensions", RFC 4685,
September 2006. September 2006.
[RFC4946] Snell, J., "Atom License Extension", RFC 4946, July 2007. [RFC4946] Snell, J., "Atom License Extension", RFC 4946, July 2007.
[RFC5005] Nottingham, M., "Feed Paging and Archiving", RFC 5005, [RFC5005] Nottingham, M., "Feed Paging and Archiving", RFC 5005,
September 2007. September 2007.
[RFC5023] Gregorio, J. and B. de hOra, "The Atom Publishing [RFC5023] Gregorio, J. and B. de hOra, "The Atom Publishing
Protocol", RFC 5023, October 2007. Protocol", RFC 5023, October 2007.
[W3C.CR-css3-mediaqueries-20090915] [W3C.CR-css3-mediaqueries-20090915]
Glazman, D., Celik, T., Lie, H., and A. Kesteren, "Media van Kesteren, A., Glazman, D., Lie, H., and T. Celik,
Queries", World Wide Web Consortium CR CR-css3- "Media Queries", W3C Candidate Recommendation CR-css3-
mediaqueries-20090915, September 2009, mediaqueries-20090915, September 2009,
<http://www.w3.org/TR/2009/CR-css3-mediaqueries-20090915>. <http://www.w3.org/TR/2009/
CR-css3-mediaqueries-20090915/>.
Latest version available at
<http://www.w3.org/TR/css3-mediaqueries/>.
[W3C.CR-curie-20090116]
Birbeck, M. and S. McCarron, "CURIE Syntax 1.0", W3C
Candidate Recommendation CR-curie-20090116, January 2009,
<http://www.w3.org/TR/2009/CR-curie-20090116>.
Latest version available at <http://www.w3.org/TR/curie>.
[W3C.REC-html401-19991224] [W3C.REC-html401-19991224]
Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01 Le Hors, A., Raggett, D., and I. Jacobs, "HTML 4.01
Specification", W3C REC REC-html401-19991224, Specification", W3C Recommendation REC-html401-19991224,
December 1999. December 1999,
<http://www.w3.org/TR/1999/REC-html401-19991224>.
Latest version available at
<http://www.w3.org/TR/html401>.
[W3C.REC-rdfa-syntax-20081014] [W3C.REC-rdfa-syntax-20081014]
Pemberton, S., Birbeck, M., Adida, B., and S. McCarron, Adida, B., Birbeck, M., McCarron, S., and S. Pemberton,
"RDFa in XHTML: Syntax and Processing", World Wide Web "RDFa in XHTML: Syntax and Processing", W3C
Consortium Recommendation REC-rdfa-syntax-20081014, Recommendation REC-rdfa-syntax-20081014, October 2008,
October 2008,
<http://www.w3.org/TR/2008/REC-rdfa-syntax-20081014>. <http://www.w3.org/TR/2008/REC-rdfa-syntax-20081014>.
Latest version available at
<http://www.w3.org/TR/rdfa-syntax>.
[W3C.REC-xhtml-basic-20080729] [W3C.REC-xhtml-basic-20080729]
Baker, M., Wugofski, T., Ishikawa, M., Stark, P., Matsui, Baker, M., Ishikawa, M., Stark, P., Matsui, S., Wugofski,
S., and T. Yamakami, "XHTML[TM] Basic 1.1", World Wide Web T., and T. Yamakami, "XHTML[TM] Basic 1.1", W3C
Consortium Recommendation REC-xhtml-basic-20080729, Recommendation REC-xhtml-basic-20080729, July 2008,
July 2008,
<http://www.w3.org/TR/2008/REC-xhtml-basic-20080729>. <http://www.w3.org/TR/2008/REC-xhtml-basic-20080729>.
Latest version available at
<http://www.w3.org/TR/xhtml-basic>.
Appendix A. Link Relation Registry Format Appendix A. Link Relation Registry Format
To facilitate applications that wish to use registry data, this To facilitate applications that wish to use registry data in an
specification defines an XML-based format for the registry entries. automated fashion, this specification defines an XML-based format for
the registry entries.
Each registered relation type is represented by a RelationType Each registered relation type is represented by a RelationType
element, and if any of the Field values are other than the default element, and if any of the app data values are other than the default
value identified in the Field Registry, they will be represented by value identified in the Application Data Registry, they will be
field elements. represented by appdata elements.
Note that this format is NOT that which IANA publishes the registry Note that this format is NOT that which IANA publishes the registry
in, because doing so would subject IANA's servers to, potentially, in, because doing so would subject IANA's servers to, potentially,
very high load (e.g., if Web browsers were to automatically update very high load (e.g., if Web browsers were to automatically update
their copies of the registry). Instead, this format is published to their copies of the registry). Instead, this format is published to
the [TBD-2]@ietf.org mailing list, so that interested implementors the [TBD-2]@ietf.org mailing list, so that interested implementors
can subscribe and distribute the machine-readable document using can subscribe and distribute the machine-readable document using
their own infrastructure. their own infrastructure.
A.1. Relax NG Grammar A.1. Relax NG Grammar
element RelationTypes { element RelationTypes {
element RelationType { element RelationType {
attribute name { text }, attribute name { text },
attribute reference { text }, attribute reference { text },
element description { text }, element description { text },
element notes { text }?, element notes { text }?,
element field { element appdata {
attribute name { text }, attribute name { text },
text text
}* }*
}+ }+
} }
A.2. Example A.2. Example
<RelationTypes> <RelationTypes>
<!--
Copyright (c) <year> The IETF Trust
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:
The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
-->
<RelationType name="example" <RelationType name="example"
reference="http://www.example.org/example_spec"> reference="http://www.example.org/example_spec">
<description>This is an example relation type.</description> <description>This is an example relation type.</description>
<field name="foo">This is the value of the Foo field.</field> <appdata name="foo">This is the value of Foo.</appdata>
</RelationType> </RelationType>
<!-- ... --> <!-- ... -->
</RelationTypes> </RelationTypes>
Appendix B. Notes on Using the Link Header with the HTML4 Format Appendix B. Notes on Using the Link Header with the HTML4 Format
HTML motivated the original syntax of the Link header, and many of HTML motivated the original syntax of the Link header, and many of
the design decisions in this document are driven by a desire to stay the design decisions in this document are driven by a desire to stay
compatible with these uses. compatible with these uses.
In HTML4, the link element can be mapped to links as specified here In HTML4, the link element can be mapped to links as specified here
by using the "href" attribute for the target URI, and "rel" to convey by using the "href" attribute for the target URI, and "rel" to convey
the relation type, as in the Link header. The context of the link is the relation type, as in the Link header. The context of the link is
the URI associated with the entire HTML document. the URI associated with the entire HTML document.
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 (briefly, some hold that rev reverses
the direction of the link, while others that it reverses the
semantics of the relation itself).
All of the link relation types defined by HTML4 have been included in All of the link relation types defined by HTML4 have been included in
the link relation type registry, so they can be used without the link relation type registry, so they can be used without
modification. However, there are several potential ways to serialise modification. However, there are several potential ways to serialise
extension relation types into HTML4, including extension relation types into HTML4, including
o As absolute URIs, or o As absolute URIs, or
o using the document-wide "profile" attribute's URI as a prefix for o using the document-wide "profile" attribute's URI as a prefix for
relation types, or relation types, or
o using the RDFa [W3C.REC-rdfa-syntax-20081014] convention of o using the RDFa [W3C.REC-rdfa-syntax-20081014] convention of
mapping token prefixes to URIs (in a manner similar to XML name mapping token prefixes to URIs (in a manner similar to XML name
skipping to change at page 22, line 26 skipping to change at page 24, line 41
The author would like to thank the many people who commented upon, The author would like to thank the many people who commented upon,
encouraged and gave feedback to this specification, especially encouraged and gave feedback to this specification, especially
including Frank Ellermann, Roy Fielding, Eran Hammer-Lahav, and including Frank Ellermann, Roy Fielding, Eran Hammer-Lahav, and
Julian Reschke. Julian Reschke.
Appendix E. Document history Appendix E. Document history
[[ to be removed by the RFC editor before publication as an RFC. ]] [[ to be removed by the RFC editor before publication as an RFC. ]]
-08
o Licensed machine-readable data under MIT.
o Clarified URI comparison for extension relation types.
o Various editorial tweaks (thanks, Julian!).
o Changed "fields" to "appdata" to avoid confusion, and add example
to clarify.
o Defined REV according to HTML2, deprecated.
o Clarified allowable characters in link-extensions.
o Changed RFC2231 reference to draft-reschke-rfc2231-in-http.
o Added hub, latest-version, predecessor-version, successor-version,
version-history, working-copy and working-copy-of relation types
to initial registry.
-07 -07
o Allowed multiple spaces between relation types. o Allowed multiple spaces between relation types.
o Relaxed requirements for registered relations. o Relaxed requirements for registered relations.
o Removed Defining New Link Serialisations appendix. o Removed Defining New Link Serialisations appendix.
o Added Field registry. o Added Field registry.
o Added registry XML format. o Added registry XML format.
o Changed registration procedure to use mailing list(s), giving the o Changed registration procedure to use mailing list(s), giving the
Designated Experts more responsibility for the smooth running of Designated Experts more responsibility for the smooth running of
the registry. the registry.
 End of changes. 61 change blocks. 
138 lines changed or deleted 258 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
X-Generator: pyht 0.35