idnits 2.17.1 draft-nottingham-rfc5988bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 obsoletes RFC5988, but the abstract doesn't seem to directly say this. It does mention RFC5988 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, 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 (May 3, 2016) is 2912 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) == Unused Reference: 'RFC2026' is defined on line 575, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-ietf-httpbis-rfc5987bis-01 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 2068 (Obsoleted by RFC 2616) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft May 3, 2016 4 Obsoletes: 5988 (if approved) 5 Intended status: Standards Track 6 Expires: November 4, 2016 8 Web Linking 9 draft-nottingham-rfc5988bis-01 11 Abstract 13 This specification defines a way to indicate the relationships 14 between resources on the Web ("links") and the type of those 15 relationships ("link relation types"). 17 It also defines the use of such links in HTTP headers with the Link 18 header field. 20 Note to Readers 22 This is a work-in-progress to revise RFC5988. 24 The issues list can be found at https://github.com/mnot/I-D/labels/ 25 rfc5988bis . 27 The most recent (often, unpublished) draft is at 28 https://mnot.github.io/I-D/rfc5988bis/ . 30 Recent changes are listed at https://github.com/mnot/I-D/commits/gh- 31 pages/rfc5988bis . 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on November 4, 2016. 50 Copyright Notice 52 Copyright (c) 2016 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 This document may contain material from IETF Documents or IETF 66 Contributions published or made publicly available before November 67 10, 2008. The person(s) controlling the copyright in some of this 68 material may not have granted the IETF Trust the right to allow 69 modifications of such material outside the IETF Standards Process. 70 Without obtaining an adequate license from the person(s) controlling 71 the copyright in such materials, this document may not be modified 72 outside the IETF Standards Process, and derivative works of it may 73 not be created outside the IETF Standards Process, except to format 74 it for publication as an RFC or to translate it into languages other 75 than English. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 80 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 81 3. Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 82 4. Link Relation Types . . . . . . . . . . . . . . . . . . . . . 5 83 4.1. Registered Relation Types . . . . . . . . . . . . . . . . 5 84 4.1.1. Registering Link Relation Types . . . . . . . . . . . 6 85 4.2. Extension Relation Types . . . . . . . . . . . . . . . . 7 86 5. Link Serialisation in the Link HTTP Header Field . . . . . . 7 87 5.1. Link Target . . . . . . . . . . . . . . . . . . . . . . . 8 88 5.2. Link Context . . . . . . . . . . . . . . . . . . . . . . 8 89 5.3. Relation Type . . . . . . . . . . . . . . . . . . . . . . 9 90 5.4. Target Attributes . . . . . . . . . . . . . . . . . . . . 9 91 5.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 10 92 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 93 6.1. Link HTTP Header Field Registration . . . . . . . . . . . 11 94 6.2. Link Relation Type Registry . . . . . . . . . . . . . . . 11 95 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 96 8. Internationalisation Considerations . . . . . . . . . . . . . 12 97 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 98 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 99 9.2. Informative References . . . . . . . . . . . . . . . . . 14 100 Appendix A. Link Serialisation in HTML . . . . . . . . . . . . . 16 101 Appendix B. Link Serialisation in Atom . . . . . . . . . . . . . 16 102 Appendix C. Changes from RFC5988 . . . . . . . . . . . . . . . . 17 103 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 105 1. Introduction 107 This specification defines a way to indicate the relationships 108 between resources on the Web ("links") and the type of those 109 relationships ("link relation types"). 111 HTML [W3C.REC-html5-20141028] and Atom [RFC4287] both have well- 112 defined concepts of linking; this specification generalises this into 113 a framework that encompasses linking in these formats and 114 (potentially) elsewhere. 116 Furthermore, this specification formalises an HTTP header field for 117 conveying such links, having been originally defined in 118 Section 19.6.2.4 of [RFC2068], but removed from [RFC2616]. 120 2. Notational Conventions 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in BCP 14, [RFC2119], as 125 scoped to those conformance targets. 127 This document uses the Augmented Backus-Naur Form (ABNF) notation of 128 [RFC7230], including the #rule, and explicitly includes the following 129 rules from it: quoted-string, token, SP (space), LOALPHA, DIGIT. 131 Additionally, the following rules are included from [RFC3986]: URI 132 and URI-Reference; from [RFC6838]: type-name and subtype-name; from 133 [W3C.CR-css3-mediaqueries-20090915]: media_query_list; from 134 [RFC5646]: Language-Tag; and from [I-D.ietf-httpbis-rfc5987bis], ext- 135 value and parmname. 137 3. Links 139 In this specification, a link is a typed connection between two 140 resources, and is comprised of: 142 o A _link context_, 144 o a _link relation type_ (Section 4), 145 o a _link target_, and 147 o optionally, _target attributes_. 149 A link can be viewed as a statement of the form "{link context} has a 150 {link relation type} resource at {link target}, which has {target 151 attributes}". 153 Link contexts and link targets are both IRIs [RFC3987]. However, in 154 the common case, the link context will also be a URI [RFC3986], 155 because many protocols (such as HTTP) do not support dereferencing 156 IRIs. Likewise, the link target will be sometimes be converted to a 157 URI (see [RFC3987], Section 3.1) in places that do not support IRIs 158 (such as the Link header field defined in Section 5). 160 This specification does not place restrictions on the cardinality of 161 links; there can be multiple links to and from a particular target, 162 and multiple links of the same or different types between a given 163 context and target. Likewise, the relative ordering of links in any 164 particular serialisation, or between serialisations (e.g., the Link 165 header field and in-content links) is not specified or significant in 166 this specification; applications that wish to consider ordering 167 significant can do so. 169 _Target attributes_ are a set of key/value pairs that describe the 170 link or its target; for example, a media type hint. This 171 specification does not attempt to coordinate their names, cardinality 172 or use, but individual link relations, link serialisations and link 173 applications can do so. This specification does provide common 174 target attributes for use in the Link HTTP header field. 176 Links are conveyed in _link serialisations_; they are the "bytes on 177 the wire", and can occur in various forms. This specification does 178 not define a general syntax for links, nor does it mandate a specific 179 context for any given link; it is expected that serialisations of 180 links will specify both aspects. One such serialisation is 181 communication of links through HTTP headers, specified in Section 5. 183 Finally, links are consumed by _link applications_. Generally, an 184 application will define the link relation types it uses, along with 185 the serialisations that they might occur within. For example, the 186 application "Web browsing" looks for the "stylesheet" link relation 187 type in the HTML link serialisation. 189 4. Link Relation Types 191 In the simplest case, a link relation type identifies the semantics 192 of a link. For example, a link with the relation type "copyright" 193 indicates that the resource identified by the link target is a 194 statement of the copyright terms applying to the current link 195 context. 197 Link relation types can also be used to indicate that the target 198 resource has particular attributes, or exhibits particular 199 behaviours; for example, a "service" link implies that the identified 200 resource is part of a defined protocol (in this case, a service 201 description). 203 Relation types are not to be confused with media types [RFC6838]; 204 they do not identify the format of the representation that results 205 when the link is dereferenced. Rather, they only describe how the 206 current context is related to another resource. 208 Relation types SHOULD NOT infer any additional semantics based upon 209 the presence or absence of another link relation type, or its own 210 cardinality of occurrence. An exception to this is the combination 211 of the "alternate" and "stylesheet" registered relation types, which 212 has special meaning in HTML for historical reasons. 214 There are two kinds of relation types: registered and extension. 216 4.1. Registered Relation Types 218 Well-defined relation types can be registered as tokens for 219 convenience and/or to promote reuse by other applications, using the 220 procedure in Section 4.1.1. 222 Registered relation type names MUST conform to the reg-rel-type rule, 223 and MUST be compared character-by-character in a case-insensitive 224 fashion. They SHOULD be appropriate to the specificity of the 225 relation type; i.e., if the semantics are highly specific to a 226 particular application, the name should reflect that, so that more 227 general names are available for less specific use. 229 Registered relation types MUST NOT constrain the media type of the 230 link context, and MUST NOT constrain the available representation 231 media types of the link target. However, they can specify the 232 behaviours and properties of the target resource (e.g., allowable 233 HTTP methods, request and response media types that must be 234 supported). 236 Historically, applications have sometimes referred to registered 237 relation types with a URI [RFC3986] (e.g., Appendix B) by prefixing 238 their names with an application-defined base URI. This practice is 239 NOT RECOMMENDED, because the resulting strings will not be considered 240 equivalent to the registered relation types by other processors. 241 Applications that do use such URIs internally MUST NOT use them in 242 link serialisations that do not explicitly accommodate them. 244 4.1.1. Registering Link Relation Types 246 Relation types are registered on the advice of a Designated Expert 247 (appointed by the IESG or their delegate), with a Specification 248 Required (using terminology from [RFC5226]). 250 The Expert(s) will establish procedures for requesting registrations, 251 and make them available from the registry page. 253 Registration requests consist of at least the following information: 255 o Relation Name: 257 o Description: 259 o Reference: 261 The Expert(s) MAY define additional fields to be collected in the 262 registry. 264 General requirements for registered relation types are described in 265 Section 4.1. 267 See the registry for examples of the description field; generally, it 268 SHOULD identify the semantics in terms of the link's context and 269 target. 271 Registrations MUST reference a freely available, stable 272 specification. 274 Note that relation types can be registered by third parties, if the 275 Expert(s) determine that an unregistered relation type is widely 276 deployed and not likely to be registered in a timely manner. 278 Decisions (or lack thereof) made by the Expert(s) can be first 279 appealed to Application Area Directors (contactable using app- 280 ads@tools.ietf.org email address or directly by looking up their 281 email addresses on http://www.iesg.org/ website) and, if the 282 appellant is not satisfied with the response, to the full IESG (using 283 the iesg@iesg.org mailing list). 285 4.2. Extension Relation Types 287 Applications that don't wish to register a relation type can use an 288 extension relation type, which is a URI [RFC3986] that uniquely 289 identifies the relation type. Although the URI can point to a 290 resource that contains a definition of the semantics of the relation 291 type, clients SHOULD NOT automatically access that resource to avoid 292 overburdening its server. 294 The URI used for an extension relation type SHOULD be under the 295 control of the person or party defining it, or be delegated to them. 296 These URIs also SHOULD NOT use the base URI defined by an application 297 for registered relation types (as per Section 4.1). 299 When extension relation types are compared, they MUST be compared as 300 strings (after converting to URIs if serialised in a different 301 format, such as a XML QNames [W3C.REC-xml-names-20091208]) in a case- 302 insensitive fashion, character-by-character. Because of this, all- 303 lowercase URIs SHOULD be used for extension relations. 305 Note that while extension relation types are required to be URIs, a 306 serialisation of links can specify that they are expressed in another 307 form, as long as they can be converted to URIs. 309 5. Link Serialisation in the Link HTTP Header Field 311 The Link header field provides a means for serialising one or more 312 links into HTTP headers. 314 Link = "Link" ":" #link-value 315 link-value = "<" URI-Reference ">" *( ";" link-param ) 316 link-param = ( ( "rel" "=" relation-types ) 317 | ( "anchor" "=" <"> URI-Reference <"> ) 318 | ( "rev" "=" relation-types ) 319 | ( "hreflang" "=" Language-Tag ) 320 | ( "media" "=" 321 ( media_query_list | ( <"> media_query_list <"> ) ) 322 ) 323 | ( "title" "=" quoted-string ) 324 | ( "title*" "=" ext-value ) 325 | ( "type" "=" ( media-type | quoted-mt ) ) 326 | ( link-extension ) ) 327 link-extension = ( parmname [ "=" ( ptoken | quoted-string ) ] ) 328 | ( ext-name-star "=" ext-value ) 329 ext-name-star = parmname "*" ; reserved for RFC5987-profiled 330 ; extensions. Whitespace NOT 331 ; allowed in between. 332 ptoken = 1*ptokenchar 333 ptokenchar = "!" | "#" | "$" | "%" | "&" | "'" | "(" 334 | ")" | "*" | "+" | "-" | "." | "/" | DIGIT 335 | ":" | "<" | "=" | ">" | "?" | "@" | ALPHA 336 | "[" | "]" | "^" | "_" | "`" | "{" | "|" 337 | "}" | "~" 338 media-type = type-name "/" subtype-name 339 quoted-mt = <"> media-type <"> 340 relation-types = relation-type 341 | <"> relation-type *( 1*SP relation-type ) <"> 342 relation-type = reg-rel-type | ext-rel-type 343 reg-rel-type = LOALPHA *( LOALPHA | DIGIT | "." | "-" ) 344 ext-rel-type = URI 346 5.1. Link Target 348 Each link-value conveys one target IRI as a URI-Reference (after 349 conversion to one, if necessary; see [RFC3987], Section 3.1) inside 350 angle brackets ("<>"). If the URI-Reference is relative, parsers 351 MUST resolve it as per [RFC3986], Section 5. Note that any base IRI 352 from the message's content is not applied. 354 5.2. Link Context 356 By default, the context of a link conveyed in the Link header field 357 is identity of the representation it is associated with, as defined 358 in [RFC7231], Section 3.1.4.1, serialised as a URI. 360 When present, the anchor parameter overrides this with another URI, 361 such as a fragment of this resource, or a third resource (i.e., when 362 the anchor value is an absolute URI). If the anchor parameter's 363 value is a relative URI, parsers MUST resolve it as per [RFC3986], 364 Section 5. Note that any base URI from the body's content is not 365 applied. 367 Consuming implementations can choose to ignore links with an anchor 368 parameter. For example, the application in use might not allow the 369 link context to be assigned to a different resource. In such cases, 370 the entire link is to be ignored; consuming implementations MUST NOT 371 process the link without applying the anchor. 373 Note that depending on HTTP status code and response headers, the 374 link context might be "anonymous" (i.e., no link context is 375 available). For instance, this is the case on a 404 response to a 376 GET request. 378 5.3. Relation Type 380 The relation type of a link is conveyed in the "rel" parameter's 381 value. The "rel" parameter MUST NOT appear more than once in a given 382 link-value; occurrences after the first MUST be ignored by parsers. 384 The "rev" parameter has been used in the past to indicate that the 385 semantics of the relationship are in the reverse direction. That is, 386 a link from A to B with REL="X" expresses the same relationship as a 387 link from B to A with REV="X". "rev" is deprecated by this 388 specification because it often confuses authors and readers; in most 389 cases, using a separate relation type is preferable. 391 Note that extension relation types are REQUIRED to be absolute URIs 392 in Link headers, and MUST be quoted if they contain a semicolon (";") 393 or comma (",") (as these characters are used as delimiters in the 394 header field itself). 396 5.4. Target Attributes 398 The "hreflang", "media", "title", "title*", "type", and any link- 399 extension link-params are considered to be target attributes for the 400 link. 402 The "hreflang" parameter, when present, is a hint indicating what the 403 language of the result of dereferencing the link should be. Note 404 that this is only a hint; for example, it does not override the 405 Content-Language header field of a HTTP response obtained by actually 406 following the link. Multiple "hreflang" parameters on a single link- 407 value indicate that multiple languages are available from the 408 indicated resource. 410 The "media" parameter, when present, is used to indicate intended 411 destination medium or media for style information (see 412 [W3C.REC-html5-20141028], Section 4.2.4). Its value MUST be quoted 413 if it contains a semicolon (";") or comma (","), and there MUST NOT 414 be more than one "media" parameter in a link-value. 416 The "title" parameter, when present, is used to label the destination 417 of a link such that it can be used as a human-readable identifier 418 (e.g., a menu entry) in the language indicated by the Content- 419 Language header field (if present). The "title" parameter MUST NOT 420 appear more than once in a given link-value; occurrences after the 421 first MUST be ignored by parsers. 423 The "title*" parameter can be used to encode this label in a 424 different character set, and/or contain language information as per 425 [I-D.ietf-httpbis-rfc5987bis]. The "title*" parameter MUST NOT 426 appear more than once in a given link-value; occurrences after the 427 first MUST be ignored by parsers. If the parameter does not contain 428 language information, its language is indicated by the Content- 429 Language header field (when present). 431 If both the "title" and "title*" parameters appear in a link-value, 432 processors SHOULD use the "title*" parameter's value. 434 The "type" parameter, when present, is a hint indicating what the 435 media type of the result of dereferencing the link should be. Note 436 that this is only a hint; for example, it does not override the 437 Content-Type header field of a HTTP response obtained by actually 438 following the link. The "type" parameter MUST NOT appear more than 439 once in a given link-value; occurrences after the first MUST be 440 ignored by parsers. 442 5.5. Examples 444 For example: 446 Link: ; rel="previous"; 447 title="previous chapter" 449 indicates that "chapter2" is previous to this resource in a logical 450 navigation path. 452 Similarly, 454 Link: ; rel="http://example.net/foo" 456 indicates that the root resource ("/") is related to this resource 457 with the extension relation type "http://example.net/foo". 459 The example below shows an instance of the Link header field encoding 460 multiple links, and also the use of RFC 5987 encoding to encode both 461 non-ASCII characters and language information. 463 Link: ; 464 rel="previous"; title*=UTF-8'de'letztes%20Kapitel, 465 ; 466 rel="next"; title*=UTF-8'de'n%c3%a4chstes%20Kapitel 468 Here, both links have titles encoded in UTF-8, use the German 469 language ("de"), and the second link contains the Unicode code point 470 U+00E4 ("LATIN SMALL LETTER A WITH DIAERESIS"). 472 Note that link-values can convey multiple links between the same link 473 target and link context; for example: 475 Link: ; 476 rel="start http://example.net/relation/other" 478 Here, the link to "http://example.org/" has the registered relation 479 type "start" and the extension relation type 480 "http://example.net/relation/other". 482 6. IANA Considerations 484 In addition to the actions below, IANA should terminate the Link 485 Relation Application Data Registry, as it has not been used, and 486 future use is not anticipated. 488 6.1. Link HTTP Header Field Registration 490 This specification updates the Message Header registry entry for 491 "Link" in HTTP [RFC3864] to refer to this document. 493 Header field: Link 494 Applicable protocol: http 495 Status: standard 496 Author/change controller: 497 IETF (iesg@ietf.org) 498 Internet Engineering Task Force 499 Specification document(s): 500 [RFC&rfc.number;] 502 6.2. Link Relation Type Registry 504 This specification updates the registration procedures for the Link 505 Relation Type registry; see Section 4.1.1. The Expert(s) and IANA 506 will interact as outlined below. 508 IANA will direct any incoming requests regarding the registry to the 509 processes established by the Expert(s); typically, this will mean 510 referring them to the registry HTML page. 512 The Expert(s) will provide registry data to IANA in an agreed form 513 (e.g. a specific XML format). IANA will publish: * The raw registry 514 data * The registry data, transformed into HTML * The registry data 515 in any alternative formats provided by the Expert(s) 517 Each published document will be at a URL agreed to by IANA and the 518 Expert(s), and IANA will set HTTP response headers on them as 519 (reasonably) requested by the Expert(s). 521 Additionally, the HTML generated by IANA will: * Take directions from 522 the Expert(s) as to the content of the HTML page's introductory text 523 and markup * Include a stable HTML fragment identifier for each 524 registered link relation 526 All registry data documents MUST include Simplified BSD License text 527 as described in Section 4.e of the Trust Legal Provisions 528 (). 530 7. Security Considerations 532 The content of the Link header field is not secure, private or 533 integrity-guaranteed, and due caution should be exercised when using 534 it. Use of Transport Layer Security (TLS) with HTTP ([RFC2818] and 535 [RFC2817]) is currently the only end-to-end way to provide such 536 protection. 538 Link applications ought to consider the attack vectors opened by 539 automatically following, trusting, or otherwise using links gathered 540 from HTTP headers. In particular, Link header fields that use the 541 "anchor" parameter to associate a link's context with another 542 resource should be treated with due caution. 544 The Link header field makes extensive use of IRIs and URIs. See 545 [RFC3987] for security considerations relating to IRIs. See 546 [RFC3986] for security considerations relating to URIs. See 547 [RFC7230] for security considerations relating to HTTP headers. 549 8. Internationalisation Considerations 551 Link targets may need to be converted to URIs in order to express 552 them in serialisations that do not support IRIs. This includes the 553 Link HTTP header field. 555 Similarly, the anchor parameter of the Link header field does not 556 support IRIs, and therefore IRIs must be converted to URIs before 557 inclusion there. 559 Relation types are defined as URIs, not IRIs, to aid in their 560 comparison. It is not expected that they will be displayed to end 561 users. 563 Note that registered Relation Names are required to be lower-case 564 ASCII letters. 566 9. References 568 9.1. Normative References 570 [I-D.ietf-httpbis-rfc5987bis] 571 Reschke, J., "Indicating Character Encoding and Language 572 for HTTP Header Field Parameters", draft-ietf-httpbis- 573 rfc5987bis-01 (work in progress), March 2016. 575 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 576 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 577 . 579 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 580 Requirement Levels", BCP 14, RFC 2119, 581 DOI 10.17487/RFC2119, March 1997, 582 . 584 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 585 Procedures for Message Header Fields", BCP 90, RFC 3864, 586 DOI 10.17487/RFC3864, September 2004, 587 . 589 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 590 Resource Identifier (URI): Generic Syntax", STD 66, 591 RFC 3986, DOI 10.17487/RFC3986, January 2005, 592 . 594 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 595 Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, 596 January 2005, . 598 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 599 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 600 DOI 10.17487/RFC5226, May 2008, 601 . 603 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 604 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 605 September 2009, . 607 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 608 Specifications and Registration Procedures", BCP 13, 609 RFC 6838, DOI 10.17487/RFC6838, January 2013, 610 . 612 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 613 Protocol (HTTP/1.1): Message Syntax and Routing", 614 RFC 7230, DOI 10.17487/RFC7230, June 2014, 615 . 617 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 618 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 619 DOI 10.17487/RFC7231, June 2014, 620 . 622 [W3C.CR-css3-mediaqueries-20090915] 623 Lie, H., Celik, T., Glazman, D., and A. Kesteren, "Media 624 Queries", World Wide Web Consortium CR CR-css3- 625 mediaqueries-20090915, September 2009, 626 . 628 9.2. Informative References 630 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. 631 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 632 RFC 2068, DOI 10.17487/RFC2068, January 1997, 633 . 635 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 636 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 637 Transfer Protocol -- HTTP/1.1", RFC 2616, 638 DOI 10.17487/RFC2616, June 1999, 639 . 641 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 642 HTTP/1.1", RFC 2817, DOI 10.17487/RFC2817, May 2000, 643 . 645 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 646 DOI 10.17487/RFC2818, May 2000, 647 . 649 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 650 Syndication Format", RFC 4287, DOI 10.17487/RFC4287, 651 December 2005, . 653 [W3C.REC-html-rdfa-20150317] 654 Sporny, M., "HTML+RDFa 1.1 - Second Edition", World Wide 655 Web Consortium Recommendation REC-html-rdfa-20150317, 656 March 2015, 657 . 659 [W3C.REC-html5-20141028] 660 Hickson, I., Berjon, R., Faulkner, S., Leithead, T., 661 Navara, E., O'Connor, E., and S. Pfeiffer, "HTML5", 662 World Wide Web Consortium Recommendation REC- 663 html5-20141028, October 2014, 664 . 666 [W3C.REC-xml-names-20091208] 667 Bray, T., Hollander, D., Layman, A., Tobin, R., and H. 668 Thompson, "Namespaces in XML 1.0 (Third Edition)", World 669 Wide Web Consortium Recommendation REC-xml-names-20091208, 670 December 2009, 671 . 673 Appendix A. Link Serialisation in HTML 675 HTML [W3C.REC-html5-20141028] motivated the original syntax of the 676 Link header field, and many of the design decisions in this document 677 are driven by a desire to stay compatible with it. 679 In HTML, the link element can be mapped to links as specified here by 680 using the "href" attribute for the target URI, and "rel" to convey 681 the relation type, as in the Link header field. The context of the 682 link is the URI associated with the entire HTML document. 684 All of the link relation types defined by HTML have been included in 685 the Link Relation Type registry, so they can be used without 686 modification. However, there are several potential ways to serialise 687 extension relation types into HTML, including: 689 o As absolute URIs, 691 o using the RDFa [W3C.REC-html-rdfa-20150317] convention of mapping 692 token prefixes to URIs (in a manner similar to XML name spaces). 694 Individual applications of linking will therefore need to define how 695 their extension links should be serialised into HTML. 697 Surveys of existing HTML content have shown that unregistered link 698 relation types that are not URIs are (perhaps inevitably) common. 699 Consuming HTML implementations ought not consider such unregistered 700 short links to be errors, but rather relation types with a local 701 scope (i.e., their meaning is specific and perhaps private to that 702 document). 704 HTML also defines several attributes on links that can be see as 705 target attributes, including "media", "hreflang", "type" and "sizes". 707 Finally, the HTML specification gives a special meaning when the 708 "alternate" and "stylesheet" relation types coincide in the same 709 link. Such links ought to be serialised in the Link header field 710 using a single list of relation-types (e.g., rel="alternate 711 stylesheet") to preserve this relationship. 713 Appendix B. Link Serialisation in Atom 715 Atom [RFC4287] is a link serialisation that conveys links in the 716 atom:link element, with the "href" attribute indicating the link 717 target and the "rel" attribute containing the relation type. The 718 context of the link is either a feed locator or an entry ID, 719 depending on where it appears; generally, feed-level links are 720 obvious candidates for transmission as a Link header field. 722 When serialising an atom:link into a Link header field, it is 723 necessary to convert link targets (if used) to URIs. 725 Atom defines extension relation types in terms of IRIs. This 726 specification re-defines them as URIs, to simplify and reduce errors 727 in their comparison. 729 Atom allows registered link relation types to be serialised as 730 absolute URIs using a prefix, "http://www.iana.org/assignments/ 731 relation/". This prefix is specific to the Atom serialisation. 733 Furthermore, link relation types are always compared in a case- 734 sensitive fashion; therefore, registered link relation types SHOULD 735 be converted to their registered form (usually, lowercase) when 736 serialised in an Atom document. 738 Note also that while the Link header field allows multiple relations 739 to be serialised in a single link, atom:link does not. In this case, 740 a single link-value may map to several atom:link elements. 742 As with HTML, atom:link defines some attributes that are not 743 explicitly mirrored in the Link header field syntax, but they can 744 also be used as link-extensions to maintain fidelity. 746 Appendix C. Changes from RFC5988 748 This specification has the following differences from its 749 predecessor, RFC5988: 751 o The initial relation type registrations were removed, since 752 they've already been registered by 5988. 754 o The introduction has been shortened. 756 o The Link Relation Application Data Registry has been removed. 758 o Incorporated errata. 760 o Updated references. 762 o Link cardinality was clarified. 764 o Terminology was changed from "target IRI" and "context IRI" to 765 "link target" and "link context" respectively. 767 o Made assigning a URI to registered relation types application- 768 specific. 770 o Removed misleading statement that the link header field is 771 semantically equivalent to HTML and Atom links. 773 o More carefully defined how the Experts and IANA should interact. 775 o More carefully defined and used "link serialisations" and "link 776 applications." 778 o Clarified the cardinality of target attributes (generically and 779 for "type"). 781 o Corrected the default link context for the Link header field, to 782 be dependent upon the identity of the representation (as per 783 RFC7231). 785 Author's Address 787 Mark Nottingham 789 EMail: mnot@mnot.net 790 URI: http://www.mnot.net/