idnits 2.17.1 draft-nottingham-http-link-header-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4287, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4287, updated by this document, for RFC5378 checks: 2004-07-09) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 12, 2009) is 5401 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TM' is mentioned on line 653, but not defined ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 2068 (Obsoleted by RFC 2616) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft July 12, 2009 4 Updates: 4287 (if approved) 5 Intended status: Standards Track 6 Expires: January 13, 2010 8 Web Linking 9 draft-nottingham-http-link-header-06 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on January 13, 2010. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 This document specifies relation types for Web links, and defines a 58 registry for them. It also defines how to send such links in HTTP 59 headers with the Link header-field. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 65 3. Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4. Link Relation Types . . . . . . . . . . . . . . . . . . . . . 4 67 4.1. Registered Relation Types . . . . . . . . . . . . . . . . 5 68 4.2. Extension Relation Types . . . . . . . . . . . . . . . . . 6 69 5. The Link Header Field . . . . . . . . . . . . . . . . . . . . 6 70 5.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 72 6.1. Link Header Registration . . . . . . . . . . . . . . . . . 8 73 6.2. Link Relation Type Registry . . . . . . . . . . . . . . . 9 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 75 8. Internationalisation Considerations . . . . . . . . . . . . . 13 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 78 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 79 Appendix A. Notes on Using the Link Header with HTML4 . . . . . . 15 80 Appendix B. Notes on Using the Link Header with Atom . . . . . . 16 81 Appendix C. Defining New Link Serialisations . . . . . . . . . . 17 82 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 17 83 Appendix E. Document history . . . . . . . . . . . . . . . . . . 18 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 86 1. Introduction 88 A means of indicating the relationships between resources on the Web, 89 as well as indicating the type of those relationships, has been 90 available for some time in HTML [W3C.REC-html401-19991224], and more 91 recently in Atom [RFC4287]. These mechanisms, although conceptually 92 similar, are separately specified. However, links between resources 93 need not be format-specific; it can be useful to have typed links 94 that are independent of their serialisation, especially when a 95 resource has representations in multiple formats. 97 To this end, this document defines a framework for typed links that 98 isn't specific to a particular serialisation. It does so by re- 99 defining the link relation registry established by Atom to have a 100 broader scope, and adding to it the relations that are defined by 101 HTML. 103 Furthermore, an HTTP header-field for conveying typed links was 104 defined in [RFC2068], but removed from [RFC2616], due to a lack of 105 implementation experience. Since then, it has been implemented in 106 some User-Agents (e.g., for stylesheets), and several additional use 107 cases have surfaced. 109 Because it was removed, the status of the Link header is unclear, 110 leading some to consider minting new application-specific HTTP 111 headers instead of reusing it. This document addresses this by re- 112 specifying the Link header as one such serialisation, with updated 113 but backwards-compatible syntax. 115 [[ Feedback is welcome on the ietf-http-wg@w3.org mailing list, 116 although this is NOT a work item of the HTTPBIS WG. ]] 118 2. Notational Conventions 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in BCP 14, [RFC2119], as 123 scoped to those conformance targets. 125 This document uses the Augmented Backus-Naur Form (ABNF) notation of 126 [RFC2616], and explicitly includes the following rules from it: 127 quoted-string, token, SP (space). Additionally, the following rules 128 are included from [RFC3986]: URI and URI-Reference, and from 129 [RFC4288]: type-name and subtype-name. 131 3. Links 133 In this specification, a link is a typed connection between two 134 resources that are identified by IRIs [RFC3987], and is comprised of: 135 o A context IRI, and 136 o a link relation type (Section 4), and 137 o a target IRI, and 138 o optionally, target attributes. 140 A link can be viewed as a statement of the form "{context IRI} has a 141 {relation type} resource at {target IRI}, which has {target 142 attributes}." 144 Note that in the common case, the context IRI will also be a URI 145 [RFC3986], because many protocols (such as HTTP) do not support 146 dereferencing IRIs. Likewise, the target IRI will be converted to a 147 URI (see [RFC3987], Section 3.1) in serialisations that do not 148 support IRIs (e.g., the Link header). 150 This specification does not place restrictions on the cardinality of 151 links; there can be multiple links from and to a particular IRI, and 152 multiple links of different types between two given IRIs. Likewise, 153 the relative ordering of links in any particular serialisation, or 154 between serialisations (e.g., the Link header and in-content links) 155 is not specified or significant in this specification; applications 156 that wish to consider ordering significant MAY do so. 158 Target attributes are a set of key/value pairs that describe the link 159 or its target; for example, a media type hint. This specification 160 does not attempt to coordinate their names or use, but does provide 161 common target attributes for use in the Link HTTP header. 163 Finally, this specification does not define a general syntax for 164 expressing links, nor mandate a specific context for any given link; 165 it is expected that serialisations of links will specify both 166 aspects. One such serialisation is communication of links through 167 HTTP headers, specified in Section 5. 169 4. Link Relation Types 171 A link relation type identifies the semantics of a link. For 172 example, a link with the relation type "copyright" indicates that the 173 resource identified by the target IRI is a statement of the copyright 174 terms applying to the current context IRI. 176 Relation types are not to be confused with media types [RFC4288]; 177 they do not identify the format of the representation that results 178 when the link is dereferenced. Rather, they only describe how the 179 current context is related to another resource. 181 As such, relation types are not format-specific, and MUST NOT specify 182 a particular format or media type that they are to be used with. 183 Likewise, the context IRI for a given link is usually determined by 184 the serialisation of the link (e.g., the Link header, a HTML 185 document, etc.); a relation type SHOULD NOT specify the context IRI. 187 Relation types SHOULD NOT infer any additional semantics based upon 188 the presence or absence of another link relation, or its own 189 cardinality of occurrence. An exception to this is the combination 190 of the "alternate" and "stylesheet" registered relation types, which 191 have special meaning in HTML4 for historical reasons. 193 Consuming implementations SHOULD ignore relation types that they do 194 not understand or have no need to process. 196 There are two kinds of relation types: registered and extension. 198 4.1. Registered Relation Types 200 Commonly-used relation types with a clear meaning that are shared 201 across applications can be registered as tokens for convenience and 202 to promote reuse. For example, "self" and "alternate" are registered 203 relation types, because they are broadly useful. 205 This specification establishes an IANA registry of such relation 206 types; see Section 6.2. 208 Registered relation types MUST conform to the token rule, and SHOULD 209 conform to the sgml-name rule for compatibility with deployed 210 implementations; 212 sgml-name = ALPHA *( ALPHA | DIGIT | "." | "-" ) 214 Names that differ only in case from existing entries (e.g., "Foo" and 215 "foo") MUST NOT be registered. Registered relation types MUST be 216 compared character-by-character in a case-insensitive fashion. 218 Although registered relation types are specified as tokens, 219 applications wishing to internally refer to one using a URI MAY do so 220 by considering it relative to the base URI 221 "http://www.iana.org/assignments/relation/". However, the URI form 222 of a registered relation type SHOULD NOT be serialised when an 223 application specifies the use of a relation type, because a consuming 224 implementation may not recognise it. 226 4.2. Extension Relation Types 228 Applications that don't merit a registered relation type may use an 229 extension relation type, which is a URI [RFC3986] that uniquely 230 identifies the relation type. Although the URI MAY point to a 231 resource that contains a definition of the semantics of the relation 232 type, clients SHOULD NOT automatically access that resource to avoid 233 overburdening its server. 235 When extension relation types are compared, they MUST be compared as 236 URIs in a case-sensitive fashion, character-by-character. 238 Note that while extension relation types are required to be URIs, a 239 serialisation of links MAY specify that they are expressed in another 240 form, as long as they can be converted to URIs. 242 5. The Link Header Field 244 The Link entity-header field provides a means for serialising one or 245 more links in HTTP headers. It is semantically equivalent to the 246 element in HTML, as well as the atom:link feed-level element 247 in Atom [RFC4287]. 249 Link = "Link" ":" #link-value 250 link-value = "<" URI-Reference ">" *( ";" link-param ) 251 link-param = ( ( "rel" "=" relation-types ) 252 | ( "rev" "=" relation-types ) 253 | ( "type" "=" type-name "/" subtype-name ) 254 | ( "title" "=" quoted-string ) 255 | ( "title*" "=" enc2231-string ) 256 | ( "anchor" "=" <"> URI-Reference <"> ) 257 | ( link-extension ) ) 258 link-extension = token [ "=" ( token | quoted-string ) ] 259 enc2231-string = 260 relation-types = relation-type | 261 <"> relation-type *( SP relation-type ) <"> 262 relation-type = reg-relation-type | ext-relation-type 263 reg-relation-type = token 264 ext-relation-type = URI 266 Each link-value conveys one target IRI as a URI-Reference (after 267 conversion to one, if necessary; see [RFC3987], Section 3.1) inside 268 angle brackets ("<>"). If the URI-Reference is relative, it MUST be 269 resolved as per [RFC3986], Section 5. Note that any base IRI from 270 the body's content is not applied. 272 By default, the context of a link conveyed in the Link header field 273 is the IRI of the requested resource. When present, the anchor 274 parameter overrides this with another URI, such as a fragment of this 275 resource, or a third resource (i.e., when the anchor value is an 276 absolute URI). If the anchor parameter's value is a relative URI, it 277 MUST be resolved as per [RFC3986], Section 5. Note that any base URI 278 from the body's content is not applied. 280 Normally, the relation type of a link is conveyed in the "rel" 281 parameter's value. The "rev" parameter has also been used for this 282 purpose historically by some formats, and is included here for 283 compatibility with those uses, but its use is not encouraged nor 284 defined by this specification. 286 Note that extension relation types are REQUIRED to be absolute URIs 287 in Link headers, and MUST be quoted if they contain a semicolon (";") 288 or comma (","). 290 The "title", "title*", "type" and any link-extension link-params are 291 considered to be the target parameters for the link. 293 The "title" parameter is used to label the destination of a link such 294 that it can be used as a human-readable identifier (e.g. a menu 295 entry). Alternately, the "title*" parameter MAY be used encode this 296 label in a different character set, and/or contain language 297 information as per [RFC2231]. When using the enc2231-string syntax, 298 producers MUST NOT use a charset value other than 'ISO-8859-1' or 299 'UTF-8'. 301 The "type" parameter, when present, is a hint indicating what the 302 media type of the result of dereferencing the link should be. Note 303 that this is only a hint; for example, it does not override the 304 Content-Type header of a HTTP response obtained by following the 305 link. 307 5.1. Examples 309 NOTE: Non-ASCII characters used in prose for examples are encoded 310 using the format "Backslash-U with Delimiters", defined in Section 311 5.1 of [RFC5137]. 313 For example: 315 Link: ; rel="previous"; 316 title="previous chapter" 318 indicates that "chapter2" is previous to this resource in a logical 319 navigation path. 321 Similarly, 323 Link: ; rel="http://example.net/foo" 325 indicates that the root resource ("/") has the extension relation 326 "http://example.net/foo". 328 The example below shows an instance of the Link header encoding 329 multiple links, and also the use of RFC 2231 encoding to encode both 330 non-ASCII characters and language information. 332 Link: ; 333 rel="previous"; title*=UTF-8'de'letztes%20Kapitel", 334 ; 335 rel="next"; title*=UTF-8'de'n%c3%a4chstes%20Kapitel" 337 Here, the second link has a title encoded in UTF-8, uses the German 338 language ("de"), and contains the Unicode code point U+00E4 ("LATIN 339 SMALL LETTER A WITH DIAERESIS"). 341 Note that link-values may convey multiple links between the same 342 target and context IRIs; for example: 344 Link: ; rel=index; 345 rel="start http://example.net/relation/other" 347 Here, the link to "http://example.org/" has the registered relation 348 types "index" and "start", and the extension relation type 349 "http://example.net/relation/other". 351 6. IANA Considerations 353 6.1. Link Header Registration 355 This specification updates the Message Header Registry entry for 356 "Link" in HTTP [RFC3864] to refer to this document. 358 Header field: Link 359 Applicable protocol: http 360 Status: standard 361 Author/change controller: 362 IETF (iesg@ietf.org) 363 Internet Engineering Task Force 364 Specification document(s): 365 [ this document ] 367 6.2. Link Relation Type Registry 369 This specification establishes the Link Relation Type Registry, and 370 updates Atom [RFC4287] to refer to it in place of the "Registry of 371 Link Relations". 373 The requirements for registered relation types are described in 374 Section 4.1. 376 Relation types are registered on the advice of a Designated Expert 377 (appointed by the IESG or their delegate), with a Specification 378 Required (using terminology from [RFC5226]). 380 Registration requests consist of the completed registration template 381 below, typically published in an RFC or Open Standard (in the sense 382 described by [RFC2026], Section 7). However, to allow for the 383 allocation of values prior to publication, the Designated Expert may 384 approve registration once they are satisfied that an RFC (or other 385 Open Standard) will be published. 387 The registration template is: 389 o Relation Name: 390 o Description: 391 o Reference: 392 o Notes: [optional] 394 Upon receiving a registration request (usually via IANA), the 395 Designated Expert should request review and comment from the 396 apps-discuss@ietf.org mailing list (or a successor designated by the 397 APPS Area Directors). Before a period of 30 days has passed, the 398 Designated Expert will either approve or deny the registration 399 request, communicating this decision both to the review list and to 400 IANA. Denials should include an explanation and, if applicable, 401 suggestions as to how to make the request successful. 403 The Link Relation Type registry's initial contents are: 405 o Relation Name: alternate 406 o Description: Designates a substitute for the link's context. 407 o Reference: [W3C.REC-html401-19991224] 409 o Relation Name: appendix 410 o Description: Refers to an appendix. 411 o Reference: [W3C.REC-html401-19991224] 412 o Relation Name: bookmark 413 o Description: Refers to a bookmark or entry point. 414 o Reference: [W3C.REC-html401-19991224] 416 o Relation Name: chapter 417 o Description: Refers to a chapter in a collection of resources. 418 o Reference: [W3C.REC-html401-19991224] 420 o Relation Name: contents 421 o Description: Refers to a table of contents. 422 o Reference: [W3C.REC-html401-19991224] 424 o Relation Name: copyright 425 o Description: Refers to a copyright statement that applies to the 426 link's context. 427 o Reference: [W3C.REC-html401-19991224] 429 o Relation Name: current 430 o Description: Refers to a resource containing the most recent 431 item(s) in a collection of resources. 432 o Reference: [RFC5005] 434 o Relation Name: describedby 435 o Description: Refers to a resource providing information about the 436 link's context. 437 o Documentation: 439 o Relation Name: edit 440 o Description: Refers to a resource that can be used to edit the 441 link's context. 442 o Reference: [RFC5023] 444 o Relation Name: edit-media 445 o Description: Refers to a resource that can be used to edit media 446 associated with the link's context. 447 o Reference: [RFC5023] 449 o Relation Name: enclosure 450 o Description: Identifies a related resource that is potentially 451 large and might require special handling. 452 o Reference: [RFC4287] 454 o Relation Name: first 455 o Description: An IRI that refers to the furthest preceding resource 456 in a series of resources. 457 o Reference: [this document] 458 o Relation Name: glossary 459 o Description: Refers to a glossary of terms. 460 o Reference: [W3C.REC-html401-19991224] 462 o Relation Name: help 463 o Description: Refers to a resource offering help (more information, 464 links to other sources information, etc.) 465 o Reference: [W3C.REC-html401-19991224] 467 o Relation Name: index 468 o Description: Refers to an index. 469 o Reference: [W3C.REC-html401-19991224] 471 o Relation Name: last 472 o Description: An IRI that refers to the furthest following resource 473 in a series of resources. 474 o Reference: [this document] 476 o Relation Name: license 477 o Description: Refers to a license associated with the link's 478 context. 479 o Reference: [RFC4946] 481 o Relation Name: next 482 o Description: Refers to the next resource in a ordered series of 483 resources. 484 o Reference: [W3C.REC-html401-19991224] 486 o Relation Name: next-archive 487 o Description: Refers to the immediately following archive resource. 488 o Reference: [RFC5005] 490 o Relation Name: payment 491 o Description: indicates a resource where payment is accepted. 492 o Reference: [this document] 494 o Relation Name: prev 495 o Description: Refers to the previous resource in an ordered series 496 of resources. Synonym for "previous". 497 o Reference: [W3C.REC-html401-19991224] 499 o Relation Name: previous 500 o Description: Refers to the previous resource in an ordered series 501 of resources. Synonym for "prev". 502 o Reference: [W3C.REC-html401-19991224] 503 o Relation Name: prev-archive 504 o Description: Refers to the immediately preceding archive resource. 505 o Reference: [RFC5005] 507 o Relation Name: related 508 o Description: Identifies a related resource. 509 o Reference: [RFC4287] 511 o Relation Name: replies 512 o Description: Identifies a resource that is a reply to the context 513 of the link. 514 o Reference: [RFC4685] 516 o Relation Name: section 517 o Description: Refers to a section in a collection of resources. 518 o Reference: [W3C.REC-html401-19991224] 520 o Relation Name: self 521 o Description: Conveys an identifier for the link's context. 522 o Reference: [RFC4287] 524 o Relation Name: service 525 o Description: Indicates a URI that can be used to retrieve a 526 service document. 527 o Reference: [RFC5023] 528 o Notes: When used in an Atom document, this relation specifies Atom 529 Publishing Protocol service documents by default. 531 o Relation Name: start 532 o Description: Refers to the first resource in a collection of 533 resources. 534 o Reference: [W3C.REC-html401-19991224] 536 o Relation Name: stylesheet 537 o Description: Refers to an external style sheet. 538 o Reference: [W3C.REC-html401-19991224] 540 o Relation Name: subsection 541 o Description: Refers to a resource serving as a subsection in a 542 collection of resources. 543 o Reference: [W3C.REC-html401-19991224] 545 o Relation Name: up 546 o Description: Refers to a parent document in a hierarchy of 547 documents. 548 o Reference: [this document] 549 o Relation Name: via 550 o Description: Identifies a resource that is the source of the 551 information in the link's context. 552 o Reference: [RFC4287] 554 7. Security Considerations 556 The content of the Link header-field is not secure, private or 557 integrity-guaranteed, and due caution should be exercised when using 558 it. 560 Applications that take advantage of typed links should consider the 561 attack vectors opened by automatically following, trusting, or 562 otherwise using links gathered from HTTP headers. In particular, 563 Link headers that use the "anchor" parameter to associate a link's 564 context with another resource should be treated with due caution. 566 8. Internationalisation Considerations 568 Target IRIs may need to be converted to URIs in order to express them 569 in serialisations that do not support IRIs. This includes the Link 570 HTTP header. 572 Similarly, the anchor parameter of the Link header does not support 573 IRIs, and therefore IRIs must be converted to URIs before inclusion 574 there. 576 Relation types are defined as URIs, not IRIs, to aid in their 577 comparison. It is not expected that they will be displayed to end 578 users. 580 9. References 582 9.1. Normative References 584 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 585 3", BCP 9, RFC 2026, October 1996. 587 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 588 Requirement Levels", BCP 14, RFC 2119, March 1997. 590 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 591 Word Extensions: Character Sets, Languages, and 592 Continuations", RFC 2231, November 1997. 594 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 595 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 596 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 598 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 599 Procedures for Message Header Fields", BCP 90, RFC 3864, 600 September 2004. 602 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 603 Resource Identifier (URI): Generic Syntax", STD 66, 604 RFC 3986, January 2005. 606 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 607 Identifiers (IRIs)", RFC 3987, January 2005. 609 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 610 Registration Procedures", BCP 13, RFC 4288, December 2005. 612 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 613 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 614 May 2008. 616 9.2. Informative References 618 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 619 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 620 RFC 2068, January 1997. 622 [RFC4287] Nottingham, M. and R. Sayre, "The Atom Syndication 623 Format", RFC 4287, December 2005. 625 [RFC4685] Snell, J., "Atom Threading Extensions", RFC 4685, 626 September 2006. 628 [RFC4946] Snell, J., "Atom License Extension", RFC 4946, July 2007. 630 [RFC5005] Nottingham, M., "Feed Paging and Archiving", RFC 5005, 631 September 2007. 633 [RFC5023] Gregorio, J. and B. de hOra, "The Atom Publishing 634 Protocol", RFC 5023, October 2007. 636 [RFC5137] Klensin, J., "ASCII Escaping of Unicode Characters", 637 BCP 137, RFC 5137, February 2008. 639 [W3C.REC-html401-19991224] 640 Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01 641 Specification", W3C REC REC-html401-19991224, 642 December 1999. 644 [W3C.REC-rdfa-syntax-20081014] 645 Pemberton, S., Birbeck, M., Adida, B., and S. McCarron, 646 "RDFa in XHTML: Syntax and Processing", World Wide Web 647 Consortium Recommendation REC-rdfa-syntax-20081014, 648 October 2008, 649 . 651 [W3C.REC-xhtml-basic-20080729] 652 Baker, M., Wugofski, T., Ishikawa, M., Stark, P., Matsui, 653 S., and T. Yamakami, "XHTML[TM] Basic 1.1", World Wide Web 654 Consortium Recommendation REC-xhtml-basic-20080729, 655 July 2008, 656 . 658 Appendix A. Notes on Using the Link Header with HTML4 660 HTML motivated the original syntax of the Link header, and many of 661 the design decisions in this document are driven by a desire to stay 662 compatible with these uses. 664 In HTML4, the link element can be mapped to links as specified here 665 by using the "href" attribute for the target URI, and "rel" to convey 666 the relation type, as in the Link header. The context of the link is 667 the URI associated with the entire HTML document. 669 HTML4 also has a "rev" parameter for links that allows a link's 670 relation to be reversed. The Link header has a "rev" parameter to 671 allow the expression of these links in HTTP headers, but its use is 672 not encouraged, due to the confusion this mechanism causes as well as 673 conflicting interpretations among HTML versions. 675 All of the link relations defined by HTML4 have been included in the 676 link relation registry, so they can be used without modification. 677 However, extension link relations work differently in HTML4 and the 678 Link header; the former uses a document-wide "profile" URI to scope 679 the relations, while the latter allows the use of full URIs on 680 individual relations. 682 Therefore, when using the profile mechanism in HTML4, it is necessary 683 to map the profiled link relations to URIs when expressed in Link 684 headers. For example, in HTML: 686 687 688 689 690 [...] 692 could be represented as a header like this; 694 Link: ; rel="http://example.com/profile1/foo" 696 Profile authors should note this when creating profile URIs; it may 697 be desirable to use URIs that end in a delimiter (e.g., "/" or "#"), 698 to make extracting the specific relation in use easier. 700 Note that RDFa [W3C.REC-rdfa-syntax-20081014] defines a different way 701 to map link relations to URIs in XHTML 702 [W3C.REC-xhtml-basic-20080729]. Although this convention is not 703 defined for HTML4, some authors may still use it there. 705 Surveys of existing HTML content have shown that unregistered link 706 relation types that are not URIs are (perhaps inevitably) common. 707 Consuming HTML implementations should not consider such unregistered 708 short links to be errors, but rather relation types with a local 709 scope (i.e., their meaning is specific and perhaps private to that 710 document). 712 HTML4 also defines several attributes on links that are not 713 explicitly defined by the Link header. These attributes can be 714 serialised as link-extensions to maintain fidelity. 716 Finally, the HTML4 specification gives a special meaning when the 717 "alternate" and "stylesheet" relations coincide in the same link. 718 Such links should be serialised in the Link header using a single 719 list of relation-types (e.g., rel="alternate stylesheet") to preserve 720 this relationship. 722 Appendix B. Notes on Using the Link Header with Atom 724 Atom conveys links in the atom:link element, with the "href" 725 attribute indicating the target IRI and the "rel" attribute 726 containing the relation type. The context of the link is either a 727 feed IRI or an entry ID, depending on where it appears; generally, 728 feed-level links are obvious candidates for transmission as a Link 729 header. 731 When serialising an atom:link into a Link header, it is necessary to 732 convert target IRIs (if used) to URIs. 734 Atom defines extension relation types in terms of IRIs. This 735 specification re-defines them as URIs, to simplify and reduce errors 736 in their comparison. 738 Atom allows registered link relation types to be serialised as 739 absolute URIs. Such relation types SHOULD be converted to the 740 appropriate registered form (e.g., 741 "http://www.iana.org/assignments/relation/self" to "self") so that 742 they are not mistaken for extension relation types. 744 Furthermore, Atom link relations are always compared in a case- 745 sensitive fashion; therefore, registered link relations SHOULD be 746 converted to their registered form (usually, lower case) when 747 serialised in an Atom document. 749 Note also that while the Link header allows multiple relations to be 750 serialised in a single link, atom:link does not. In this case, a 751 single link-value may map to several atom:link elements. 753 As with HTML, atom:link defines some attributes that are not 754 explicitly mirrored in the Link header syntax, but they may also be 755 used as link-extensions to maintain fidelity. 757 Appendix C. Defining New Link Serialisations 759 New serialisations of links (as defined by this specification) need 760 to address several issues, including: 762 o Specific syntax for each component of the link model described in 763 Section 3. 764 o What target attributes, if any, are defined by the serialisation. 765 o How to determine the context of the link. 766 o How to differentiate registered link relations from extension link 767 relations (if the latter are serialised as URIs, this is 768 relatively straightforward). 770 Appendix D. Acknowledgements 772 This specification lifts the idea and definition for the Link header 773 from RFC2068; credit for it belongs entirely to the authors of and 774 contributors to that document. The link relation registrations 775 themselves are sourced from several documents; see the applicable 776 references. 778 The author would like to thank the many people who commented upon, 779 encouraged and gave feedback to this specification, especially 780 including Frank Ellermann, Roy Fielding and Julian Reschke. 782 Appendix E. Document history 784 [[ to be removed by the RFC editor before publication as an RFC. ]] 786 -06 788 o Added "up" and "service" relation types. 789 o Fixed "type" attribute syntax and added prose. 790 o Added note about RDFa and XHTML to HTML4 notes. 791 o Removed specific location for the registry, since IANA seems to 792 have its own ideas about that. 794 -05 796 o Clarified how to resolve relative URIs in the 'anchor' parameter. 797 o Tweaked language about dereferencing relation type URIs. 798 o Separated out examples. 799 o Made target-parameters more explicit in the model. 800 o Discourage special semantics between different relations, or based 801 upon cardinality. 802 o Grandfathered in special semantics of 'alternate stylesheet' for 803 HTML4. 804 o Note that extension types can be serialised in ways other than as 805 URIs, as long as they can be converted to URIs. 806 o Change default context of a link header to that of the requested 807 resource. 808 o Use this document as reference for relations that don't have a 809 formal definition other than the registry entries; avoids circular 810 references. 811 o Noted that ordering of links is not significant or defined in this 812 spec, but may be in specific applications. 813 o Adjusted uses of 'application' to 'serialisation' where 814 appropriate. 815 o Added 'Defining New Link Serialisations' section. 816 o Added note about case sensitivity when comparing registered 817 relation types in Atom. 819 -04 821 o Defined context as a resource, rather than a representation. 822 o Removed concept of link directionality; relegated to a deprecated 823 Link header extension. 825 o Relation types split into registered (non-URI) and extension 826 (URI). 827 o Changed wording around finding URIs for registered relation types. 828 o Changed target and context URIs to IRIs (but not extension 829 relation types). 830 o Add RFC2231 encoding for title parameter, explicit BNF for title*. 831 o Add i18n considerations. 832 o Specify how to compare relation types. 833 o Changed registration procedure to Designated Expert. 834 o Softened language around presence of relations in the registry. 835 o Added describedby relation. 836 o Re-added 'anchor' parameter, along with security consideration for 837 third-party anchors. 838 o Softened language around HTML4 attributes that aren't directly 839 accommodated. 840 o Various tweaks to abstract, introduction and examples. 842 -03 844 o Inverted focus from Link headers to link relations. 845 o Specified was a link relation type is. 846 o Based on discussion, re-added 'rev'. 847 o Changed IESG Approval to IETF Consensus for relation registrations 848 (i.e., require a document). 849 o Updated RFC2434 reference to RFC5226. 850 o Registered relations SHOULD conform to sgml-name. 851 o Cautioned against confusing relation types with media types. 853 -02 855 o Dropped XLink language. 856 o Removed 'made' example. 857 o Removed 'rev'. Can still be used as an extension. 858 o Added HTML reference to introduction. 859 o Required relationship values that have a ; or , to be quoted. 860 o Changed base URI for relation values. 861 o Noted registry location. 862 o Added advisory text about HTML profile URIs. 863 o Disallowed registration of relations that only differ in case. 864 o Clarified language about IRIs in Atom. 865 o Added descriptions for 'first', 'last', and 'payment', referring 866 to current IANA registry entries, as these were sourced from 867 e-mail. Will this cause self-referential implosion? 868 o Explicitly updates RFC4287. 869 o Added 'type' parameter. 870 o Removed unnecessary advice about non-HTML relations in HTML 871 section. 873 -01 875 o Changed syntax of link-relation to one or more URI; dropped 876 Profile. 877 o Dropped anchor parameter; can still be an extension. 878 o Removed Link-Template header; can be specified by templates spec 879 or elsewhere. 880 o Straw-man for link relation registry. 882 -00 884 o Initial draft; normative text lifted from RFC2068. 886 Author's Address 888 Mark Nottingham 890 Email: mnot@mnot.net 891 URI: http://www.mnot.net/