idnits 2.17.1 draft-snell-atompub-feature-06.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 631. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 642. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 649. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 655. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (August 19, 2007) is 6067 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'REC-xml' is mentioned on line 245, but not defined ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Downref: Normative reference to an Experimental RFC: RFC 4946 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 J. Snell 3 Internet-Draft August 19, 2007 4 Intended status: Standards Track 5 Expires: February 20, 2008 7 Atom Publishing Protocol Features Extension 8 draft-snell-atompub-feature-06.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on February 20, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document introduces extensions to the Atom Publishing Protocol 42 service document format for expressing metadata about the behaviors, 43 functions and capabilities supported by an Atom Publishing Protocol 44 collection. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 50 3. The f:feature element . . . . . . . . . . . . . . . . . . . . 4 51 3.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 6 52 4. The f:type element . . . . . . . . . . . . . . . . . . . . . . 6 53 4.1. An example f:feature using the f:type element . . . . . . 7 54 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 55 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 56 6.1. Registry of Atom Publishing Features . . . . . . . . . . . 7 57 6.1.1. Initial Assignments . . . . . . . . . . . . . . . . . 8 58 7. Normative References . . . . . . . . . . . . . . . . . . . . . 13 59 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 61 Intellectual Property and Copyright Statements . . . . . . . . . . 16 63 1. Introduction 65 This document introduces extensions for the Atom Publishing Protocol 66 service document format for expressing metadata about the behaviors, 67 functions and capabilities supported by an Atom Publishing Protocol 68 collection. 70 2. Notational Conventions 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in BCP 14, [RFC2119]. 76 This specification uses XML Namespaces [W3C.REC-xml-names-19990114] 77 to uniquely identify XML element names. It uses the following 78 namespace prefix for the indicated namespace URI; 80 "f": "http://purl.org/atompub/features/1.0" 82 This specification uses terms from the XML Infoset 83 [W3C.REC-xml-infoset-20040204]. However, this specification uses a 84 shorthand; the phrase "Information Item" is omitted when naming 85 Element Information Items. Therefore, when this specification uses 86 the terms "element" and "attribute" it is referring, respectively, to 87 the Element and Attribute Information Items in Infoset terms. 89 This specification uses the terms "atomUri" and 90 "atomCommonAttributes" from the non-normative RELAX NG Compact schema 91 included in [RFC4287]. Where used, these serve the same purpose and 92 have the same meaning as their use in [RFC4287]. 94 Atom allows the use of IRIs [RFC3987]. Every URI [RFC3986] is also 95 an IRI, so a URI may be used wherever below an IRI is named. There 96 are two special considerations: (1) when an IRI that is not also a 97 URI is given for dereferencing, it MUST be mapped to a URI using the 98 steps in Section 3.1 of [RFC3987] and (2) when an IRI is serving as 99 an identifier, it MUST NOT be so mapped. 101 Any element defined by this specification MAY have an xml:base 102 attribute [W3C.REC-xmlbase-20010627]. When xml:base is used, it 103 serves the function described in section 5.1.1 of [RFC3986], 104 establishing the base URI (or IRI) for resolving any relative 105 references found within the effective scope of the xml:base 106 attribute. 108 Any element defined by this specification MAY have an xml:lang 109 attribute, whose content indicates the natural language for the 110 element and its descendents. The language context is only 111 significant for elements and attributes declared to be "Language- 112 Sensitive". Requirements regarding the content and interpretation of 113 xml:lang are specified in XML 1.0 [W3C.REC-xml-20040204], Section 114 2.12. 116 3. The f:feature element 118 A feature is an abstract behavior, function and capability supported 119 by an Atom Publishing Protocol collection. Examples of features that 120 might be supported by an Atom publishing server include support for 121 draft entries, scheduled publication of entries, use of a particular 122 set of Atom format extensions, use of a particular authentication 123 scheme, and so on. The f:feature element can be used in an app: 124 collection element to indicate that the collection supports the 125 feature specified and may require that a client wishing to use the 126 endpoint use that feature. Features are identified using permanent, 127 universally unique IRI's. 129 namespace f = "http://purl.org/atompub/features/1.0" 131 feature = element f:feature { 132 atomCommonAttributes, 133 attribute ref { atomUri }, 134 attribute status { 'supported' | 'required' | 'unsupported'}?, 135 attribute href { atomUri }?, 136 attribute label { text }?, 137 (anyElement)* 138 } 140 anyElement = element * - f:* { 141 (attribute * { text } 142 | text 143 | anyElement)* 144 } 146 The ref attribute specifies a globally unique IRI identifying a 147 feature supported by a collection. The value of the ref attribute 148 MUST be compared on a case-sensitive, character-by-character basis. 149 Relative references MUST NOT be used. 151 The status attribute indicates a collections level of support for the 152 identified feature. The value of the attribute can be "supported", 153 "required" or "unsupported". If not specified, the value is assumed 154 to be "supported". 156 o The value "supported" indicates that the server supports the 157 identified feature. Clients MAY utilize the feature when 158 interacting with the collection. 159 o The value "required" indicates that server supports the identified 160 feature. Clients MUST utilize the feature when interacting with 161 the collection. 162 o The value "unsupported" indicates that the server explicitly does 163 not support a feature. Clients SHOULD NOT utilize the feature 164 when interacting with the collection. 166 An optional href attribute MAY be used to specify the URI of a human- 167 readable description of the feature. Relative references MAY be 168 used. 170 The optional label attribute MAY be used to specify a human-readable 171 label for the feature. The value of the label attribute is Language- 172 Sensitive as defined by Section 2 of [RFC4287]. 174 The f:feature element MAY contain child elements and attributes other 175 than those defined in this specification. Such "foreign markup" are 176 considered to be metadata applicable to the feature identified by the 177 f:feature element. Software agents MUST NOT stop processing or 178 signal an error or change their behavior as a result of encountering 179 such foreign markup. 181 An app:collection element MAY contain zero or more f:feature elements 182 but MUST NOT contain more than one with the same ref attribute value. 183 The order in which f:feature elements appear within the app: 184 collection element is insignificant. 186 The f:feature element MAY contain attributes included as part of the 187 atomCommonAttributes production defined by Section 2 of [RFC4287] or 188 any update thereof. When used on an f:feature element, such 189 attributes serve the same purpose described in [RFC4287] or their 190 corresponding specifications. 192 3.1. Example 194 The following is an example of a collection supporting one 195 hypothetical required feature, one unsupported feature, and a number 196 of supported features. 198 202 203 My Workspace 204 205 My Atom Collection 206 application/atom+xml;type=entry 207 209 211 213 215 218 222 223 224 226 4. The f:type element 228 The content of an f:type element is a media-range as defined in 229 [RFC2616]. The media range specifies a type of content that can be 230 included in an atom:content element or referenced by the atom:content 231 src attribute. 233 type = 234 element f:type { 235 atomCommonAttributes, 236 ( text? ) 237 } 239 The f:type element is similar to the HTTP Accept request-header 240 [RFC2616]. Media type parameters are allowed within f:type, but 241 f:type has no notion of preference - "accept-params" or "q" 242 arguments, as specified in Section 14.1 of [RFC2616] are not 243 significant. 245 White space (as defined in [REC-xml]) around the f:type element's 246 media-range is insignificant and MUST be ignored. 248 Any number of f:type elements MAY appear as children of an f:feature 249 element whose ref attribute identifies the "XML Content", "Binary 250 Content" or "Reference Content" features as defined in Section 6.1.1. 251 When used with these features, the f:type elements specify the range 252 of media types that can be specified in the atom:content elements 253 type attribute. If no f:type element is present, clients SHOULD 254 treat this as equivalent to an f:type element with the content "*/*". 256 The order of f:type elements within a f:feature element is 257 insignificant. 259 4.1. An example f:feature using the f:type element 261 263 image/jpg 264 image/png 265 image/gif 266 text/* 267 269 5. Security Considerations 271 Specific features supported by a collection may introduce security 272 considerations and concerns beyond those discussed by the Atom 273 Publishing Protocol and Atom Syndication Format specifications. 274 Implementors must refer to the specifications and description of each 275 feature to determine the security considerations relevant to each. 277 6. IANA Considerations 279 6.1. Registry of Atom Publishing Features 281 The Registry of Atom Publishing Features is maintained by IANA and 282 contains information about known features that can be supported by 283 Atom Publishing Protocol implementations. New assignments are 284 subject to IESG approval, as outlined in [RFC2434]. Requests should 285 be made by email to IANA, which will then forward the request to the 286 IESG, requesting approval. The request should use the following 287 template: 289 o Ref: (A globally unique IRI identifying the feature) 290 o Label: (A human-readable label for the feature) 291 o Description: (A human-readable description of the feature) 292 o Href: (A URI referencing a document containing a detailed 293 definition of the feature) 294 o Security Considerations: 296 6.1.1. Initial Assignments 298 The Registry of Features initially contains the following 299 assignments: 301 6.1.1.1. Drafts 303 o Ref: http://www.w3.org/2007/app/drafts 304 o Label: Drafts 305 o Description: The "Drafts" feature indicates that a collection 306 supports the use of the app:draft control element as defined in 307 section 13.1.1 of [I-D.ietf-atompub-protocol]. 309 6.1.1.2. XHTML Content 311 o Ref: http://www.w3.org/2007/app/xhtml-content 312 o Label: XHTML Content 313 o Description: The "XHTML Content" feature indicates that a server 314 will accept the use of an XHTML value within the atom:content 315 element. 317 6.1.1.3. HTML Content 319 o Ref: http://www.w3.org/2007/app/html-content 320 o Label: HTML Content 321 o Description: The "HTML Content" feature indicates that a server 322 will accept the use of an escaped HTML value within the atom: 323 content element. 325 6.1.1.4. Text Content 327 o Ref: http://www.w3.org/2007/app/text-content 328 o Label: Text Content 329 o Description: The "Text Content" feature indicates that a server 330 will accept the use of a plain text value within the atom:content 331 element. 333 6.1.1.5. XML Content 335 o Ref: http://www.w3.org/2007/app/xml-content 336 o Label: XML Content 337 o Description: The "XML Content" feature indicates that a server 338 will accept the use of well-formed XML content within the atom: 339 content element. 341 6.1.1.6. Binary Content 343 o Ref: http://www.w3.org/2007/app/xhtml-content 344 o Label: Binary Content 345 o Description: The "Binary Content" feature indicates that a server 346 will accept Base-64 encoded binary data within the atom:content 347 element. 349 6.1.1.7. Referenced Content 351 o Ref: http://www.w3.org/2007/app/ref-content 352 o Label: XHTML Content 353 o Description: The "Referenced Content" feature indicates that a 354 server will accept atom:content elements that use the src 355 attribute to reference external content resources. 357 6.1.1.8. XHTML Title 359 o Ref: http://www.w3.org/2007/app/xhtml-title 360 o Label: XHTML Title 361 o Description: The "XHTML Title" feature indicates that a server 362 will accept the use of an XHTML value within the atom:title 363 element. 365 6.1.1.9. HTML Title 367 o Ref: http://www.w3.org/2007/app/html-title 368 o Label: HTML Title 369 o Description: The "HTML Content" feature indicates that a server 370 will accept the use of an escaped HTML value within the atom:title 371 element. 373 6.1.1.10. Text Title 374 o Ref: http://www.w3.org/2007/app/text-title 375 o Label: Text Title 376 o Description: The "Text Content" feature indicates that a server 377 will accept the use of a plain text value within the atom:title 378 element. 380 6.1.1.11. XHTML Summary 382 o Ref: http://www.w3.org/2007/app/xhtml-summary 383 o Label: XHTML Summary 384 o Description: The "XHTML Summary" feature indicates that a server 385 will accept the use of an XHTML value within the atom:summary 386 element. 388 6.1.1.12. HTML Summary 390 o Ref: http://www.w3.org/2007/app/html-summary 391 o Label: HTML Summary 392 o Description: The "HTML Summary" feature indicates that a server 393 will accept the use of an escaped HTML value within the atom: 394 summary element. 396 6.1.1.13. Text Summary 398 o Ref: http://www.w3.org/2007/app/text-summary 399 o Label: Text Summary 400 o Description: The "Text Summary" feature indicates that a server 401 will accept the use of a plain text value within the atom:summary 402 element. 404 6.1.1.14. Auto Summary 406 o Ref: http://www.w3.org/2007/app/auto-summary 407 o Label: Auto Summary 408 o Description: The "Auto Summary" feature indicates that a server 409 will autogenerate the value of the atom:summary element and will 410 either reject or ignore attempts by the client to modify the value 411 of atom:summary. 413 6.1.1.15. XHTML Rights 415 o Ref: http://www.w3.org/2007/app/xhtml-rights 416 o Label: XHTML Rights 417 o Description: The "XHTML Rights" feature indicates that a server 418 will accept the use of an XHTML value within the atom:rights 419 element. 421 6.1.1.16. HTML Rights 423 o Ref: http://www.w3.org/2007/app/html-rights 424 o Label: HTML Rights 425 o Description: The "HTML Rights" feature indicates that a server 426 will accept the use of an escaped HTML value within the atom: 427 rights element. 429 6.1.1.17. Text Rights 431 o Ref: http://www.w3.org/2007/app/text-rights 432 o Label: Text Rights 433 o Description: The "Text Rights" feature indicates that a server 434 will accept the use of a plain text value within the atom:rights 435 element. 437 6.1.1.18. Authenticated Author 439 o Ref: http://www.w3.org/2007/app/auth-author 440 o Label: Authenticated Author 441 o Description: The "Authenticated Author" feature indicates that a 442 server will use the authenticated identity of the client to 443 determine the values to use within the atom:author element. 444 Attempts by a client to manually set or modify the author 445 information will either be rejected or ignored by the server. 447 6.1.1.19. Slug 449 o Ref: http://www.w3.org/2007/app/slug 450 o Label: Slug 451 o Description: The "Slug" feature indicates that a server will use 452 the Slug request header defined in section 9.7 of 453 [I-D.ietf-atompub-protocol] to set the URI of newly created 454 resources. 456 6.1.1.20. Multiple Categories 458 o Ref: http://www.w3.org/2007/app/multiple-categories 459 o Label: Multiple Categories 460 o Description: The "Multiple Categories" feature indicates that a 461 server will accept entries that contain multiple atom:category 462 elements. 464 6.1.1.21. Multiple Authors 466 o Ref: http://www.w3.org/2007/app/multiple-authors 467 o Label: Multiple Authors 468 o Description: The "Multiple Authors" feature indicates that a 469 server will accept and preserve multiple atom:author elements 470 contained by an entry. 472 6.1.1.22. Multiple Contributors 474 o Ref: http://www.w3.org/2007/app/contributors 475 o Label: Multiple Contributors 476 o Description: The "Multiple Contributors" feature indicates that a 477 server will accept and preserve atom:contributor elements 478 contained by an entry. 480 6.1.1.23. Preserve Infoset 482 Label: Preserve Infoset 484 Description: The "Preserve Infoset" feature indicates that a server 485 will preserve the complete XML Infoset [W3C.REC-xml-infoset-20040204] 486 of entries POST or PUT to a collection. 488 6.1.1.24. Preserve IDs 490 o Ref: http://www.w3.org/2007/app/preserve-id 491 o Label: Preserve IDs 492 o Description: The "Preserve IDs" feature indicates that a server 493 will preserve the value of atom:id elements as provided by a 494 client. 496 6.1.1.25. Preserve Dates 498 o Ref: http://www.w3.org/2007/app/preserve-updated 499 o Label: Preserve Dates 500 o Description: The "Preserve Dates" feature indicates that a server 501 will preserve the value of the atom:updated and atom:published 502 elements as provided by a client. 504 6.1.1.26. Preserve Extensions 506 o Ref: http://www.w3.org/2007/app/preserve-extensions 507 o Label: Preserve Extensions 508 o Description: The "Preserve Extensions" feature indicates that a 509 server will preserve unknown foreign markup contained within an 510 entry. 512 6.1.1.27. Preserve Links 514 o Ref: http://www.w3.org/2007/app/preserve-links 515 o Label: Preserve Links 516 o Description: The "Preserve Links" feature indicates that a server 517 will preserve all atom:link elements contained within an entry. 519 6.1.1.28. Preserve Rights 521 o Ref: http://www.w3.org/2007/app/preserve-rights 522 o Label: Preserve Rights 523 o Description: The "Preserve Rights" feature indicates that a server 524 will preserve all atom:rights elements and License Links [RFC4946] 525 contained within an entry. 527 6.1.1.29. Threading 529 o Ref: http://purl.org/syndication/thread/1.0 530 o Label: Threading 531 o Description: The Feed Thread feature indicates that the APP server 532 accepts entries that contain the in-reply-to element as defined by 533 [RFC4685]. 535 6.1.1.30. Scheduled Publishing 537 o Ref: http://www.w3.org/2007/app/scheduled-publishing 538 o Label: Scheduled Publishing 539 o Description: The "Scheduled Publishing" feature indicates that a 540 collection allows clients to set the value of an entries atom: 541 published element to some future point in time after which the 542 entry will be made publicly visible. Prior to that time, the 543 entry will be considered to be in a draft state and SHOULD contain 544 an app:draft control element with a value of "yes". 546 7. Normative References 548 [I-D.ietf-atompub-protocol] 549 Hora, B. and J. Gregorio, "The Atom Publishing Protocol", 550 draft-ietf-atompub-protocol-17 (work in progress), 551 July 2007. 553 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 554 Requirement Levels", BCP 14, RFC 2119, March 1997. 556 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 557 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 558 October 1998. 560 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 561 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 562 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 564 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 565 Resource Identifier (URI): Generic Syntax", STD 66, 566 RFC 3986, January 2005. 568 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 569 Identifiers (IRIs)", RFC 3987, January 2005. 571 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 572 Syndication Format", RFC 4287, December 2005. 574 [RFC4685] Snell, J., "Atom Threading Extensions", RFC 4685, 575 September 2006. 577 [RFC4946] Snell, J., "Atom License Extension", RFC 4946, July 2007. 579 [W3C.REC-xml-20040204] 580 Maler, E., Sperberg-McQueen, C., Paoli, J., Yergeau, F., 581 and T. Bray, "Extensible Markup Language (XML) 1.0 (Third 582 Edition)", World Wide Web Consortium FirstEdition REC-xml- 583 20040204, February 2004, 584 . 586 [W3C.REC-xml-infoset-20040204] 587 Tobin, R. and J. Cowan, "XML Information Set (Second 588 Edition)", World Wide Web Consortium Recommendation REC- 589 xml-infoset-20040204, February 2004, 590 . 592 [W3C.REC-xml-names-19990114] 593 Hollander, D., Bray, T., and A. Layman, "Namespaces in 594 XML", World Wide Web Consortium FirstEdition REC-xml- 595 names-19990114, January 1999, 596 . 598 [W3C.REC-xmlbase-20010627] 599 Marsh, J., "XML Base", World Wide Web Consortium 600 Recommendation REC-xmlbase-20010627, June 2001, 601 . 603 Appendix A. Acknowledgements 605 The author acknowledges the feedback from the other members of the 606 IETF Atom Publishing working group during the development of this 607 specification. 609 Author's Address 611 James M Snell 613 Phone: 614 Email: jasnell@gmail.com 615 URI: http://snellspace.com 617 Full Copyright Statement 619 Copyright (C) The IETF Trust (2007). 621 This document is subject to the rights, licenses and restrictions 622 contained in BCP 78, and except as set forth therein, the authors 623 retain all their rights. 625 This document and the information contained herein are provided on an 626 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 627 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 628 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 629 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 630 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 631 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 633 Intellectual Property 635 The IETF takes no position regarding the validity or scope of any 636 Intellectual Property Rights or other rights that might be claimed to 637 pertain to the implementation or use of the technology described in 638 this document or the extent to which any license under such rights 639 might or might not be available; nor does it represent that it has 640 made any independent effort to identify any such rights. Information 641 on the procedures with respect to rights in RFC documents can be 642 found in BCP 78 and BCP 79. 644 Copies of IPR disclosures made to the IETF Secretariat and any 645 assurances of licenses to be made available, or the result of an 646 attempt made to obtain a general license or permission for the use of 647 such proprietary rights by implementers or users of this 648 specification can be obtained from the IETF on-line IPR repository at 649 http://www.ietf.org/ipr. 651 The IETF invites any interested party to bring to its attention any 652 copyrights, patents or patent applications, or other proprietary 653 rights that may cover technology that may be required to implement 654 this standard. Please address the information to the IETF at 655 ietf-ipr@ietf.org. 657 Acknowledgment 659 Funding for the RFC Editor function is provided by the IETF 660 Administrative Support Activity (IASA).