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.