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.