idnits 2.17.1
draft-nottingham-http-link-header-03.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 16.
-- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on
line 612.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 623.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 630.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 636.
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 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 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 (December 1, 2008) is 5625 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 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 (~~), 1 warning (==), 9 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group M. Nottingham
3 Internet-Draft December 1, 2008
4 Updates: 4287 (if approved)
5 Intended status: Standards Track
6 Expires: June 4, 2009
8 Link Relations and HTTP Header Linking
9 draft-nottingham-http-link-header-03
11 Status of this Memo
13 By submitting this Internet-Draft, each author represents that any
14 applicable patent or other IPR claims of which he or she is aware
15 have been or will be disclosed, and any of which he or she becomes
16 aware will be disclosed, in accordance with Section 6 of BCP 79.
18 Internet-Drafts are working documents of the Internet Engineering
19 Task Force (IETF), its areas, and its working groups. Note that
20 other groups may also distribute working documents as Internet-
21 Drafts.
23 Internet-Drafts are draft documents valid for a maximum of six months
24 and may be updated, replaced, or obsoleted by other documents at any
25 time. It is inappropriate to use Internet-Drafts as reference
26 material or to cite them other than as "work in progress."
28 The list of current Internet-Drafts can be accessed at
29 http://www.ietf.org/ietf/1id-abstracts.txt.
31 The list of Internet-Draft Shadow Directories can be accessed at
32 http://www.ietf.org/shadow.html.
34 This Internet-Draft will expire on June 4, 2009.
36 Abstract
38 This document specifies relation types for Web links, and defines a
39 registry for them. It also defines how to send such links in HTTP
40 headers with the Link header-field.
42 Table of Contents
44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
45 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3
46 3. Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
47 4. Link Relation Types . . . . . . . . . . . . . . . . . . . . . 4
48 5. The Link Header Field . . . . . . . . . . . . . . . . . . . . 5
49 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
50 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
51 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
52 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
53 8.2. Informative References . . . . . . . . . . . . . . . . . . 11
54 Appendix A. Notes on Using the Link Header with HTML . . . . . . 11
55 Appendix B. Notes on Using the Link Header with Atom . . . . . . 12
56 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 13
57 Appendix D. Document history . . . . . . . . . . . . . . . . . . 13
58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
59 Intellectual Property and Copyright Statements . . . . . . . . . . 15
61 1. Introduction
63 A means of indicating the relationships between documents on the Web,
64 as well as indicating the type of those relationships, has been
65 available for some time in HTML [W3C.REC-html401-19991224], and more
66 recently in Atom [RFC4287]. These mechanisms, although conceptually
67 similar, are separate. However, links between resources need not be
68 format-specific; it can be useful to have typed links that are
69 independent of the format, especially when a resource has
70 representations in multiple formats.
72 This document defines typed link relations, independent of the
73 context they occur in. It does so by clarifying the status of the
74 link relation registry established by Atom, and registering in it the
75 relations that are defined by HTML.
77 Furthermore, an HTTP header-field for conveying typed links was
78 defined in [RFC2068], but removed from [RFC2616], due to a lack of
79 implementation experience. Since then, several use cases for doing
80 so have surfaced. However, because it was removed, the status of the
81 Link header is unclear, leading some to consider minting new
82 application-specific HTTP headers instead of reusing it. This
83 document addresses this by re-specifying the Link header with updated
84 but backwards-compatible syntax.
86 [[ Feedback is welcome on the ietf-http-wg@w3.org mailing list,
87 although this is NOT a work item of the HTTPBIS WG. ]]
89 2. Notational Conventions
91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
93 document are to be interpreted as described in BCP 14, [RFC2119], as
94 scoped to those conformance targets.
96 This document uses the Augmented Backus-Naur Form (ABNF) notation of
97 [RFC2616], and explicitly includes the following rules from it:
98 quoted-string, token, SP (space). Additionally, the following rules
99 are included from [RFC3986]: URI and URI-Reference, and from
100 [RFC4288]: type-name.
102 3. Links
104 In the context of this specification, a link is comprised of:
106 o A target URI ([RFC3986]), and
107 o A context of use, and
108 o A link relation type (Section 4), and
109 o A link direction (outbound or inbound).
111 A link can be viewed as a statement of the form "(subject) has a
112 (relation type) at (object)", where for an outbound link the subject
113 is the context of use and the object is the resource identified by
114 the target URI, and for an inbound link the subject is the resource
115 identified by the target URI and the object is the context of use.
117 This specification does not define a general syntax for expressing
118 links, nor the specific context for a given link; it is expected that
119 applications of link relations will specify both aspects. One such
120 application is communication of links through HTTP headers, specified
121 in Section 5.
123 Such applications may further constrain or extend links (e.g.,
124 associating a media type hint, only allowing links in one direction).
126 4. Link Relation Types
128 A link relation type identifies the semantics of a link. For
129 example, an outbound link with the relation type "copyright"
130 indicates that the resource identified is a statement of the
131 copyright terms applying to the current context of the link.
133 Relation types are not to be confused with media types [RFC4288];
134 they do not identify the format of the representation that results
135 when the link is dereferenced. Rather, they only describe how the
136 current context is related to another resource.
138 As such, relation types are not format-specific, and MUST NOT specify
139 a particular format or media type that they are to be used with.
140 Likewise, a relation type SHOULD NOT specify what its context of its
141 use is.
143 Relation types are URIs. Although specific applications of links may
144 specify the use of URI-References, they must also indicate how to
145 resolve them to absolute URIs.
147 Although anyone may mint a URI to be used as a relation type, it is
148 expected that a few standard types will predominate. To facilitate
149 this, Section 6.2 establishes an IANA registry of relation types that
150 share a common base URI.
152 5. The Link Header Field
154 The Link entity-header field provides a means for conveying one or
155 more links in HTTP headers. It is semantically equivalent to the
156 element in HTML, as well as the atom:link feed-level element
157 in Atom [RFC4287].
159 Link = "Link" ":" #link-value
160 link-value = "<" URI-Reference ">" *( ";" link-param ) )
161 link-param = ( ( "rel" "=" relation-type )
162 | ( "rev" "=" relation-type )
163 | ( "type" "=" type-name )
164 | ( "title" "=" quoted-string )
165 | ( link-extension ) )
166 link-extension = token [ "=" ( token | quoted-string ) ]
167 relation-type = URI-Reference |
168 <"> URI-Reference *( SP URI-Reference) <">
170 For example:
172 Link: ; rel="previous";
173 title="previous chapter"
175 indicates that chapter2 is previous to this resource in a logical
176 navigation path.
178 Each link-value conveys one target URI inside angle brackets ("<>").
179 If it is relative, it MUST be resolved as per [RFC3986]. Note that
180 because it is conveyed in a header, base URIs from content are not
181 applied to it.
183 The context of links conveyed in the Link header field is the
184 representation that the header is part of.
186 Each link-value MUST have at least one "rel" or "rev" parameter whose
187 value indicates the relation type. If the "rel" parameter is used,
188 it indicates that the link's direction for that relation type is
189 outbound; if the "rev" parameter is used, the given relation type's
190 direction is inbound.
192 If the relation-type is a relative URI, its base URI MUST be
193 considered to be "http://www.iana.org/assignments/relation/", and the
194 corresponding value MUST be present in the link relation registry.
196 Relation-types that include a semicolon (";") or comma (",") MUST be
197 quoted.
199 The title parameter MAY be used to label the destination of a link
200 such that it can be used as identification within a human-readable
201 menu.
203 Note that link-values may contain multiple relations; for example
205 Link: ; rel="index start";
206 rel="http://example.net/relation/other";
207 rev=copyright
209 Here, the link "http://example.org/" has outbound links of the types
210 "http://www.iana.org/assignments/relation/index",
211 "http://www.iana.org/assignments/relation/start", and
212 "http://example.net/relation/other", as well as an inbound link of
213 type "http://www.iana.org/assignments/relation/copyright".
215 6. IANA Considerations
217 6.1. Link Header Registration
219 This specification updates the Message Header Registry entry for
220 "Link" in HTTP [RFC3864] to refer to this document.
222 Header field: Link
223 Applicable protocol: http
224 Status: standard
225 Author/change controller:
226 IETF (iesg@ietf.org)
227 Internet Engineering Task Force
228 Specification document(s):
229 [ this document ]
231 6.2. Link Relation Type Registry
233 This specification establishes the Link Relation Type Registry,
234 located at , and updates
235 Atom [RFC4287] to refer to it in place of the "Registry of Link
236 Relations".
238 The semantics of relation types is described in Section 4. This
239 registry is intended to contain widely-used, standard relation types
240 so that they may be used in "short form" (i.e., as a relative URI) in
241 applications that allow this.
243 Registered relation types have an implicit base URI of
244 , and their name SHOULD be
245 limited to the sgml-name rule for simplicity and backwards-
246 compatibility.
248 sgml-name = ALPHA *( ALPHA | DIGIT | "." | "-" )
250 Names that differ only in case (e.g., "Foo" and "foo") MUST NOT be
251 registered.
253 New relation types can be registered by IETF Review, as outlined in
254 [RFC5226]. Specifications of new values should use the following
255 template:
257 o Relation Name:
258 o Description:
259 o Reference:
261 The Link Relation Type registry's initial contents are:
263 o Relation Name: alternate
264 o Description: Designates a substitute for the link's context.
265 o Reference: [W3C.REC-html401-19991224]
267 o Relation Name: appendix
268 o Description: Refers to an appendix.
269 o Reference: [W3C.REC-html401-19991224]
271 o Relation Name: bookmark
272 o Description: Refers to a bookmark or entry point.
273 o Reference: [W3C.REC-html401-19991224]
275 o Relation Name: chapter
276 o Description: Refers to a chapter in a collection of resources.
277 o Reference: [W3C.REC-html401-19991224]
279 o Relation Name: contents
280 o Description: Refers to a table of contents.
281 o Reference: [W3C.REC-html401-19991224]
283 o Relation Name: copyright
284 o Description: Refers to a copyright statement that applies to the
285 link's context.
286 o Reference: [W3C.REC-html401-19991224]
288 o Relation Name: current
289 o Description: Refers to a resource containing the most recent
290 item(s) in a collection of resources.
291 o Reference: [RFC5005]
293 o Relation Name: edit
294 o Description: Refers to a resource that can be used to edit the
295 link's context.
296 o Reference: [RFC5023]
298 o Relation Name: edit-media
299 o Description: Refers to a resource that can be used to edit media
300 associated with the link's context.
301 o Reference: [RFC5023]
303 o Relation Name: enclosure
304 o Description: Identifies a related resource that is potentially
305 large and might require special handling.
306 o Reference: [RFC4287]
308 o Relation Name: first
309 o Description: A URI that refers to the furthest preceding resource
310 in a series of resources.
311 o Reference:
313 o Relation Name: glossary
314 o Description: Refers to a glossary of terms.
315 o Reference: [W3C.REC-html401-19991224]
317 o Relation Name: help
318 o Description: Refers to a resource offering help (more information,
319 links to other sources information, etc.)
320 o Reference: [W3C.REC-html401-19991224]
322 o Relation Name: index
323 o Description: Refers to an index.
324 o Reference: [W3C.REC-html401-19991224]
326 o Relation Name: last
327 o Description: A URI that refers to the furthest following resource
328 in a series of resources.
329 o Reference:
331 o Relation Name: license
332 o Description: Refers to a license associated with the link's
333 context.
334 o Reference: [RFC4946]
336 o Relation Name: next
337 o Description: Refers to the next resource in a ordered series of
338 resources.
339 o Reference: [W3C.REC-html401-19991224]
340 o Relation Name: next-archive
341 o Description: Refers to the immediately following archive resource.
342 o Reference: [RFC5005]
344 o Relation Name: payment
345 o Description: indicates a resource where payment is accepted.
346 o Reference:
347
349 o Relation Name: prev
350 o Description: Refers to the previous resource in an ordered series
351 of resources. Synonym for "previous".
352 o Reference: [W3C.REC-html401-19991224]
354 o Relation Name: previous
355 o Description: Refers to the previous resource in an ordered series
356 of resources. Synonym for "prev".
357 o Reference: [W3C.REC-html401-19991224]
359 o Relation Name: prev-archive
360 o Description: Refers to the immediately preceding archive resource.
361 o Reference: [RFC5005]
363 o Relation Name: related
364 o Description: Identifies a related resource.
365 o Reference: [RFC4287]
367 o Relation Name: replies
368 o Description: Identifies a resource that is a reply to the context
369 of the link.
370 o Reference: [RFC4685]
372 o Relation Name: section
373 o Description: Refers to a section in a collection of resources.
374 o Reference: [W3C.REC-html401-19991224]
376 o Relation Name: self
377 o Description: Conveys an identifier for the link's context.
378 o Reference: [RFC4287]
380 o Relation Name: start
381 o Description: Refers to the first resource in a collection of
382 resources.
383 o Reference: [W3C.REC-html401-19991224]
385 o Relation Name: stylesheet
386 o Description: Refers to an external style sheet.
387 o Reference: [W3C.REC-html401-19991224]
389 o Relation Name: subsection
390 o Description: Refers to a resource serving as a subsection in a
391 collection of resources.
392 o Reference: [W3C.REC-html401-19991224]
394 o Relation Name: via
395 o Description: Identifies a resource that is the source of the
396 information in the link's context.
397 o Reference: [RFC4287]
399 7. Security Considerations
401 The content of the Link header-field is not secure, private or
402 integrity-guaranteed, and due caution should be exercised when using
403 it.
405 Applications that take advantage of typed links should consider the
406 attack vectors opened by automatically following, trusting, or
407 otherwise using links gathered from HTTP headers.
409 8. References
411 8.1. Normative References
413 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
414 Requirement Levels", BCP 14, RFC 2119, March 1997.
416 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
417 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
418 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
420 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
421 Procedures for Message Header Fields", BCP 90, RFC 3864,
422 September 2004.
424 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
425 Resource Identifier (URI): Generic Syntax", STD 66,
426 RFC 3986, January 2005.
428 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
429 Registration Procedures", BCP 13, RFC 4288, December 2005.
431 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
432 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
433 May 2008.
435 8.2. Informative References
437 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
438 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
439 RFC 2068, January 1997.
441 [RFC4287] Nottingham, M. and R. Sayre, "The Atom Syndication
442 Format", RFC 4287, December 2005.
444 [RFC4685] Snell, J., "Atom Threading Extensions", RFC 4685,
445 September 2006.
447 [RFC4946] Snell, J., "Atom License Extension", RFC 4946, July 2007.
449 [RFC5005] Nottingham, M., "Feed Paging and Archiving", RFC 5005,
450 September 2007.
452 [RFC5023] Gregorio, J. and B. de hOra, "The Atom Publishing
453 Protocol", RFC 5023, October 2007.
455 [W3C.REC-html401-19991224]
456 Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01
457 Specification", W3C REC REC-html401-19991224,
458 December 1999.
460 Appendix A. Notes on Using the Link Header with HTML
462 HTML motivated the original syntax of the Link header, and many of
463 the design decisions in this document are driven by a desire to stay
464 compatible with these uses.
466 In HTML4, the link element can be mapped to links as specified here
467 by using the "href" attribute for the target URI, and "rel" and rev"
468 to convey both the relation type and its direction, as in the Link
469 header. The context of the link is generally the entire HTML
470 document.
472 All of the link relations defined by HTML4 have been included in the
473 link relation registry, so they can be used without modification.
474 However, extension link relations work differently in HTML4 and the
475 Link header; the former uses a document-wide "profile" URI to scope
476 the relations, while the latter allows the use of full URIs on
477 individual relations.
479 Therefore, when using the profile mechanism in HTML4, it is necessary
480 to map the profiled link relations to URIs when expressed in Link
481 headers. For example, in HTML:
483
484
485
486
487 [...]
489 could be represented as a header like this;
491 Link: ; rel="http://example.com/profile1/foo"
493 Profile authors should note this when creating profile URIs; it may
494 be desirable to use URIs that end in a delimiter (e.g., "/" or "#"),
495 to make extracting the specific relation in use easier.
497 HTML defines link relation values as case-insensitive, while the Link
498 header's syntax does not. Therefore, it is important to case-
499 normalise relation values in HTML before comparing or converting them
500 to Link headers.
502 HTML also defines several attributes on links that are not explicitly
503 defined by the Link header. Although most of these are believed to
504 be defunct, they can be used as link-extensions.
506 Appendix B. Notes on Using the Link Header with Atom
508 Atom conveys links in the atom:link element, with the "href"
509 attribute indicating the target URI and the "rel" attribute
510 containing the relation type. The context of the link is either a
511 feed or an entry, depending on where it appears; generally, feed-
512 level links are candidates for transmission as a Link header. Since
513 atom:link only specifies "rel", only outbound links are allowed by
514 non-extended Atom syntax.
516 When serialising an atom:link into a Link header, it is necessary to
517 convert IRIs (if used) to URIs. Additionally, since the base URI for
518 link relations in Link headers is fixed, extension relation types
519 (i.e,. those not in the registry) must be represented as absolute
520 URIs.
522 Note also that while the Link header allows multiple relations to be
523 associated with a single link, atom:link does not. In this case, a
524 single link-value may map to several atom:link elements.
526 As with HTML, atom:link defines some attributes that are not
527 explicitly mirrored in the Link header syntax, but they may also be
528 used as link-extensions.
530 Appendix C. Acknowledgements
532 This specification lifts the idea and definition for the Link header
533 from RFC2068; credit for it belongs entirely to the authors of and
534 contributors to that document. The link relation registrations
535 themselves are sourced from several documents; see the applicable
536 references.
538 The author would like to thank the many people who commented upon,
539 encouraged and gave feedback to this draft, especially including
540 Frank Ellermann and Julian Reschke.
542 Appendix D. Document history
544 [[ to be removed by the RFC editor before publication as an RFC. ]]
546 -03
548 o Inverted focus from Link headers to link relations.
549 o Specified was a link relation type is.
550 o Based on discussion, re-added 'rev'.
551 o Changed IESG Approval to IETF Consensus for relation registrations
552 (i.e., require a document).
553 o Updated RFC2434 reference to RFC5226.
554 o Registered relations SHOULD conform to sgml-name.
555 o Cautioned against confusing relation types with media types.
557 -02
559 o Dropped XLink language.
560 o Removed 'made' example.
561 o Removed 'rev'. Can still be used as an extension.
562 o Added HTML reference to introduction.
563 o Required relationship values that have a ; or , to be quoted.
564 o Changed base URI for relation values.
565 o Noted registry location.
566 o Added advisory text about HTML profile URIs.
567 o Disallowed registration of relations that only differ in case.
569 o Clarified language about IRIs in Atom.
570 o Added descriptions for 'first', 'last', and 'payment', referring
571 to current IANA registry entries, as these were sourced from
572 e-mail. Will this cause self-referential implosion?
573 o Explicitly updates RFC4287.
574 o Added 'type' parameter.
575 o Removed unnecessary advice about non-HTML relations in HTML
576 section.
578 -01
580 o Changed syntax of link-relation to one or more URI; dropped
581 Profile.
582 o Dropped anchor parameter; can still be an extension.
583 o Removed Link-Template header; can be specified by templates spec
584 or elsewhere.
585 o Straw-man for link relation registry.
587 -00
589 o Initial draft; normative text lifted from RFC2068.
591 Author's Address
593 Mark Nottingham
595 Email: mnot@mnot.net
596 URI: http://www.mnot.net/
598 Full Copyright Statement
600 Copyright (C) The IETF Trust (2008).
602 This document is subject to the rights, licenses and restrictions
603 contained in BCP 78, and except as set forth therein, the authors
604 retain all their rights.
606 This document and the information contained herein are provided on an
607 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
608 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
609 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
610 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
611 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
612 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
614 Intellectual Property
616 The IETF takes no position regarding the validity or scope of any
617 Intellectual Property Rights or other rights that might be claimed to
618 pertain to the implementation or use of the technology described in
619 this document or the extent to which any license under such rights
620 might or might not be available; nor does it represent that it has
621 made any independent effort to identify any such rights. Information
622 on the procedures with respect to rights in RFC documents can be
623 found in BCP 78 and BCP 79.
625 Copies of IPR disclosures made to the IETF Secretariat and any
626 assurances of licenses to be made available, or the result of an
627 attempt made to obtain a general license or permission for the use of
628 such proprietary rights by implementers or users of this
629 specification can be obtained from the IETF on-line IPR repository at
630 http://www.ietf.org/ipr.
632 The IETF invites any interested party to bring to its attention any
633 copyrights, patents or patent applications, or other proprietary
634 rights that may cover technology that may be required to implement
635 this standard. Please address the information to the IETF at
636 ietf-ipr@ietf.org.