idnits 2.17.1 draft-nottingham-http-link-header-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 322. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 299. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 306. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 312. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 16, 2006) is 6523 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) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2068 (Obsoleted by RFC 2616) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft June 16, 2006 4 Expires: December 18, 2006 6 HTTP Header Linking 7 draft-nottingham-http-link-header-00 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 18, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This specification clarifies the status of the Link HTTP header and 41 introduces the complimentary Profile and Link-Template HTTP headers. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 47 3. The Link Header Field . . . . . . . . . . . . . . . . . . . . . 3 48 4. The Profile Header Field . . . . . . . . . . . . . . . . . . . 4 49 5. The Link-Template Header Field . . . . . . . . . . . . . . . . 5 50 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 51 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 52 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 53 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 54 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 55 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 7 56 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 57 Intellectual Property and Copyright Statements . . . . . . . . . . 9 59 1. Introduction 61 A means of indicating the relationships between documents on the Web 62 has been available for some time in HTML, and was considered as a 63 HTTP header in [RFC2068], but removed from [RFC2616], due to a lack 64 of implementation experience. 66 There have since surfaced many cases where a means of including this 67 information in HTTP headers has proved useful. However, because it 68 was removed, the status of the Link header is unclear, leading some 69 to consider minting new application-specific HTTP headers instead of 70 reusing it. 72 Additionally, the complementary "profile" mechanism -- which is often 73 used to disambiguate link relationship types -- is not available as a 74 HTTP header. 76 This specification seeks to address these shortcomings. It also 77 introduces a new header, Link-Template, that allows the structure of 78 links to be described. 80 2. Notational Conventions 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in BCP 14, [RFC2119], as 85 scoped to those conformance targets. 87 This specification uses the Augmented Backus-Naur Form (ABNF) 88 notation of [RFC2616], and explicitly includes the following rules 89 from it: quoted-string, token, SP (space), ALPHA (letters), DIGIT 90 (decimal digit). Additionally, the following rules are included from 91 [RFC3986]: URI-Reference, reserved, unreserved. 93 3. The Link Header Field 95 The Link entity-header field provides a means for describing a 96 relationship between two resources, generally between the requested 97 resource and some other resource. An entity MAY include multiple 98 Link values. Links at the metainformation level typically indicate 99 relationships like hierarchical structure and navigation paths. The 100 Link field is semantically equivalent to the element in HTML. 102 Link = "Link" ":" #("<" URI-Reference ">" 103 *( ";" link-param ) ) 105 link-param = ( ( "rel" "=" relationship ) 106 | ( "rev" "=" relationship ) 107 | ( "title" "=" quoted-string ) 108 | ( "anchor" "=" <"> URI-Reference <"> ) 109 | ( link-extension ) ) 111 link-extension = token [ "=" ( token | quoted-string ) ] 113 relationship = sgml-name 114 | ( <"> sgml-name *( SP sgml-name) <"> ) 116 sgml-name = ALPHA *( ALPHA | DIGIT | "." | "-" ) 118 Relationship values are case-insensitive and MAY be extended within 119 the constraints of the sgml-name syntax. The title parameter MAY be 120 used to label the destination of a link such that it can be used as 121 identification within a human-readable menu. The anchor parameter 122 MAY be used to indicate a source anchor other than the entire current 123 resource, such as a fragment of this resource or a third resource. 125 Examples of usage include: 127 Link: ; rel="Previous" 128 Link: ; rev="Made"; title="Tim Berners-Lee" 130 The first example indicates that chapter2 is previous to this 131 resource in a logical navigation path. The second indicates that the 132 person responsible for making the resource available is identified by 133 the given e-mail address. 135 4. The Profile Header Field 137 The Profile entity-header field provides a means to indicate the meta 138 data profile of the entity. Commonly, it is used to disambiguate the 139 meaning of relationships in links. 141 Note that this URI MAY be used as either an identifier (e.g., to 142 uniquely identify links, without dereferencing the URI), or as a link 143 that is intended to be dereferenced. 145 The Profile field is semantically equivalent to the profile attribute 146 of the HEAD element in HTML [W3C.REC-html401-19991224]. Note, 147 however, that its use is not limited to HTML entities. 149 Profile = "Profile" ":" #("<" URI-Reference ">") 151 For example: 153 Profile: 154 Profile: , 156 5. The Link-Template Header Field 158 The Link-Template entity-header field provides a means for describing 159 the structure of a link between two resources, so that new links can 160 be generated. 162 It does so through by allowing brace ("{}") -delimited strings to be 163 interposed throughout a URI reference. These correspond to variables 164 which, after being replaced with content in a relation-specified 165 manner, are semantically equivalent to the corresponding Link header. 167 For example, 169 Link-Template: ; rel="home" 171 This link indicates that the "home" link relation can be constructed 172 if the userid variable is known; if it were known to be "bob", this 173 header would be considered equivalent to 175 Link: ; rel="home" 177 This specification does not define when or how template variables are 178 interposed into link templates. Link relations that wish to allow 179 templating SHOULD specify such details. 181 This specification does not define the correct behaviour in the face 182 of a conflict between a Link-Template header and a Link header with 183 the same relation. Link relations allowing templating SHOULD specify 184 their relative precedence. 186 Applications SHOULD NOT use link relations that do not explicitly 187 allow such templating in the Link-Template header. 189 Link-Template = "Link-Template" ":" #("<" template ">" 190 *( ";" link-param ) ) 192 template = *( uri-char | template-var ) 194 template-var = "{" 1*( uri-char ) "}" 195 uri-char = ( reserved | unreserved ) 197 6. IANA Considerations 199 This specification requires registration of two Message Header Fields 200 for HTTP [RFC3864]. Note that "Link" is already present in the 201 registry; this registration only updates its specification document. 203 Header field: Link 204 Applicable protocol: http 205 Status: standard 206 Author/change controller: 207 IETF (iesg@ietf.org) 208 Internet Engineering Task Force 209 Specification document(s): 210 [ this document ] 212 Header field: Profile 213 Applicable protocol: http 214 Status: standard 215 Author/change controller: 216 IETF (iesg@ietf.org) 217 Internet Engineering Task Force 218 Specification document(s): 219 [ this document ] 221 Header field: Link-Template 222 Applicable protocol: http 223 Status: standard 224 Author/change controller: 225 IETF (iesg@ietf.org) 226 Internet Engineering Task Force 227 Specification document(s): 228 [ this document ] 230 7. Security Considerations 232 The content of both the Link and Profile headers are not secure, 233 private or integrity-guaranteed, and due caution should be excercised 234 when using them. 236 Applications that take advantage of these mechanisms should consider 237 the attack vectors opened by automatically following, trusting, or 238 otherwise using links gathered from HTTP headers. 240 8. References 242 8.1. Normative References 244 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 245 Requirement Levels", BCP 14, RFC 2119, March 1997. 247 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 248 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 249 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 251 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 252 Procedures for Message Header Fields", BCP 90, RFC 3864, 253 September 2004. 255 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 256 Resource Identifier (URI): Generic Syntax", STD 66, 257 RFC 3986, January 2005. 259 [W3C.REC-html401-19991224] 260 Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01 261 Specification", W3C REC REC-html401-19991224, 262 December 1999. 264 8.2. Informative References 266 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 267 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 268 RFC 2068, January 1997. 270 Appendix A. Acknowledgements 272 This specification lifts the definition of the Link header from 273 RFC2068; credit for it belongs entirely to the authors of and 274 contributors to that document. 276 The semantics and much of the syntax of the Profile header was 277 defined by HTML 4.01; credit for them belongs to the authors of and 278 contributors to that document. 280 Joe Gregorio, Marc Hadley and David Orchard contributed to the design 281 of the Link-Template mechanism. 283 Author's Address 285 Mark Nottingham 287 Email: mnot@pobox.com 288 URI: http://www.mnot.net/ 290 Intellectual Property Statement 292 The IETF takes no position regarding the validity or scope of any 293 Intellectual Property Rights or other rights that might be claimed to 294 pertain to the implementation or use of the technology described in 295 this document or the extent to which any license under such rights 296 might or might not be available; nor does it represent that it has 297 made any independent effort to identify any such rights. Information 298 on the procedures with respect to rights in RFC documents can be 299 found in BCP 78 and BCP 79. 301 Copies of IPR disclosures made to the IETF Secretariat and any 302 assurances of licenses to be made available, or the result of an 303 attempt made to obtain a general license or permission for the use of 304 such proprietary rights by implementers or users of this 305 specification can be obtained from the IETF on-line IPR repository at 306 http://www.ietf.org/ipr. 308 The IETF invites any interested party to bring to its attention any 309 copyrights, patents or patent applications, or other proprietary 310 rights that may cover technology that may be required to implement 311 this standard. Please address the information to the IETF at 312 ietf-ipr@ietf.org. 314 Disclaimer of Validity 316 This document and the information contained herein are provided on an 317 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 318 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 319 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 320 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 321 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 322 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 324 Copyright Statement 326 Copyright (C) The Internet Society (2006). This document is subject 327 to the rights, licenses and restrictions contained in BCP 78, and 328 except as set forth therein, the authors retain all their rights. 330 Acknowledgment 332 Funding for the RFC Editor function is currently provided by the 333 Internet Society.