<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html lang="en"><head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/"><meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"><title>Metadata Retrieval Protocol</title><style type="text/css" title="Xml2Rfc (sans serif)">
a {
text-decoration: none;
}
a.smpl {
color: black;
}
a:hover {
text-decoration: underline;
}
a:active {
text-decoration: underline;
}
address {
margin-top: 1em;
margin-left: 2em;
font-style: normal;
}
body {
color: black;
font-family: verdana, helvetica, arial, sans-serif;
font-size: 10pt;
}
cite {
font-style: normal;
}
dd {
margin-right: 2em;
}
dl {
margin-left: 2em;
}
ul.empty {
list-style-type: none;
}
ul.empty li {
margin-top: .5em;
}
dl p {
margin-left: 0em;
}
dt {
margin-top: .5em;
}
h1 {
font-size: 14pt;
line-height: 21pt;
page-break-after: avoid;
}
h1.np {
page-break-before: always;
}
h1 a {
color: #333333;
}
h2 {
font-size: 12pt;
line-height: 15pt;
page-break-after: avoid;
}
h3, h4, h5, h6 {
font-size: 10pt;
page-break-after: avoid;
}
h2 a, h3 a, h4 a, h5 a, h6 a {
color: black;
}
img {
margin-left: 3em;
}
li {
margin-left: 2em;
margin-right: 2em;
}
ol {
margin-left: 2em;
margin-right: 2em;
}
ol p {
margin-left: 0em;
}
p {
margin-left: 2em;
margin-right: 2em;
}
pre {
margin-left: 3em;
background-color: lightyellow;
padding: .25em;
}
pre.text2 {
border-style: dotted;
border-width: 1px;
background-color: #f0f0f0;
width: 69em;
}
pre.inline {
background-color: white;
padding: 0em;
}
pre.text {
border-style: dotted;
border-width: 1px;
background-color: #f8f8f8;
width: 69em;
}
pre.drawing {
border-style: solid;
border-width: 1px;
background-color: #f8f8f8;
padding: 2em;
}
table {
margin-left: 2em;
}
table.header {
border-spacing: 1px;
width: 95%;
font-size: 10pt;
color: white;
}
td.top {
vertical-align: top;
}
td.topnowrap {
vertical-align: top;
white-space: nowrap;
}
table.header td {
background-color: gray;
width: 50%;
}
table.header a {
color: white;
}
td.reference {
vertical-align: top;
white-space: nowrap;
padding-right: 1em;
}
thead {
display:table-header-group;
}
ul.toc {
list-style: none;
margin-left: 1.5em;
margin-right: 0em;
padding-left: 0em;
}
li.tocline0 {
line-height: 150%;
font-weight: bold;
font-size: 10pt;
margin-left: 0em;
margin-right: 0em;
}
li.tocline1 {
line-height: normal;
font-weight: normal;
font-size: 9pt;
margin-left: 0em;
margin-right: 0em;
}
li.tocline2 {
font-size: 0pt;
}
ul p {
margin-left: 0em;
}
.comment {
background-color: yellow;
}
.center {
text-align: center;
}
.error {
color: red;
font-style: italic;
font-weight: bold;
}
.figure {
font-weight: bold;
text-align: center;
font-size: 9pt;
}
.filename {
color: #333333;
font-weight: bold;
font-size: 12pt;
line-height: 21pt;
text-align: center;
}
.fn {
font-weight: bold;
}
.hidden {
display: none;
}
.left {
text-align: left;
}
.right {
text-align: right;
}
.title {
color: #990000;
font-size: 18pt;
line-height: 18pt;
font-weight: bold;
text-align: center;
margin-top: 36pt;
}
.vcardline {
display: block;
}
.warning {
font-size: 14pt;
background-color: yellow;
}
@media print {
.noprint {
display: none;
}
a {
color: black;
text-decoration: none;
}
table.header {
width: 90%;
}
td.header {
width: 50%;
color: black;
background-color: white;
vertical-align: top;
font-size: 12pt;
}
ul.toc a::after {
content: leader('.') target-counter(attr(href), page);
}
a.iref {
content: target-counter(attr(href), page);
}
.print2col {
column-count: 2;
-moz-column-count: 2;
column-fill: auto;
}
}
@page {
@top-left {
content: "RFC ";
}
@top-right {
content: "May 2010";
}
@top-center {
content: "Metadata Retrieval Protocol";
}
@bottom-left {
content: "La Joie";
}
@bottom-center {
content: "Experimental";
}
@bottom-right {
content: "[Page " counter(page) "]";
}
}
@page:first {
@top-left {
content: normal;
}
@top-right {
content: normal;
}
@top-center {
content: normal;
}
}
</style><link rel="Contents" href="#rfc.toc"><link rel="Author" href="#rfc.authors"><link rel="Copyright" href="#rfc.copyright"><link rel="Chapter" title="1 Introduction" href="#rfc.section.1"><link rel="Chapter" title="2 Protocol Transport" href="#rfc.section.2"><link rel="Chapter" title="3 Addressing" href="#rfc.section.3"><link rel="Chapter" title="4 Content Negotiation" href="#rfc.section.4"><link rel="Chapter" title="5 Authentication" href="#rfc.section.5"><link rel="Chapter" title="6 Protocol Operations" href="#rfc.section.6"><link rel="Chapter" title="7 Effecient Retrieval and Caching" href="#rfc.section.7"><link rel="Chapter" title="8 Security Considerations" href="#rfc.section.8"><meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.517, 2010-03-31 18:24:38, XSLT vendor: libxslt http://xmlsoft.org/XSLT/"><link rel="schema.dct" href="http://purl.org/dc/terms/"><meta name="dct.creator" content="La Joie, C."><meta name="dct.identifier" content="urn:ietf:id:metadata-retrieval-protocol-03"><meta name="dct.issued" scheme="ISO8601" content="2010-05"><meta name="dct.abstract" content="This document specifies a simple REST-based application level protocol that provides the ability to request metadata about a particular service or application from a third party. The protocol itself is designed to be very simple but services responding to this protocol may perform complex information processing (e.g. aggregation of data from multiple sources, provide multiple representations of data, act as a trust-broker for asserted data) as a value add for its clients. In short this protocol can be thought of as a DNS-like protocol for service metadata."><meta name="description" content="This document specifies a simple REST-based application level protocol that provides the ability to request metadata about a particular service or application from a third party. The protocol itself is designed to be very simple but services responding to this protocol may perform complex information processing (e.g. aggregation of data from multiple sources, provide multiple representations of data, act as a trust-broker for asserted data) as a value add for its clients. In short this protocol can be thought of as a DNS-like protocol for service metadata."></head><body><table class="header"><tbody><tr><td class="left">Network Working Group</td><td class="right">C. La Joie</td></tr><tr><td class="left">Request for Comments: </td><td class="right">Itumi, LLC</td></tr><tr><td class="left">Intended status: Experimental</td><td class="right">May 2010</td></tr></tbody></table><p class="title">Metadata Retrieval Protocol<br><span class="filename">metadata-retrieval-protocol-03</span></p><h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1> <p>This document specifies a simple REST-based application level protocol that provides the ability to request metadata about a particular service or application from a third party. The protocol itself is designed to be very simple but services responding to this protocol may perform complex information processing (e.g. aggregation of data from multiple sources, provide multiple representations of data, act as a trust-broker for asserted data) as a value add for its clients. In short this protocol can be thought of as a DNS-like protocol for service metadata.</p> <h1><a id="rfc.status" href="#rfc.status">Status of this Memo</a></h1><p>This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.</p><hr class="noprint"><h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1><ul class="toc"><li class="tocline0">1. <a href="#rfc.section.1">Introduction</a><ul class="toc"><li class="tocline1">1.1 <a href="#rfc.section.1.1">Notation and Convention</a></li><li class="tocline1">1.2 <a href="#rfc.section.1.2">Terminology</a></li></ul></li><li class="tocline0">2. <a href="#rfc.section.2">Protocol Transport</a><ul class="toc"><li class="tocline1">2.1 <a href="#rfc.section.2.1">HTTP Version</a></li><li class="tocline1">2.2 <a href="#rfc.section.2.2">HTTP Method</a></li><li class="tocline1">2.3 <a href="#rfc.section.2.3">Request Headers</a></li><li class="tocline1">2.4 <a href="#rfc.section.2.4">Response Headers</a></li><li class="tocline1">2.5 <a href="#rfc.section.2.5">Content Encoding</a></li><li class="tocline1">2.6 <a href="#rfc.section.2.6">Status Codes</a></li></ul></li><li class="tocline0">3. <a href="#rfc.section.3">Addressing</a><ul class="toc"><li class="tocline1">3.1 <a href="#rfc.section.3.1">Base URL</a></li><li class="tocline1">3.2 <a href="#rfc.section.3.2">Identifiers</a><ul class="toc"><li class="tocline1">3.2.1 <a href="#rfc.section.3.2.1">Transforms</a></li></ul></li></ul></li><li class="tocline0">4. <a href="#rfc.section.4">Content Negotiation</a></li><li class="tocline0">5. <a href="#rfc.section.5">Authentication</a></li><li class="tocline0">6. <a href="#rfc.section.6">Protocol Operations</a><ul class="toc"><li class="tocline1">6.1 <a href="#rfc.section.6.1">Single-Entity Metadata Retrieval</a><ul class="toc"><li class="tocline1">6.1.1 <a href="#rfc.section.6.1.1">Request</a></li><li class="tocline1">6.1.2 <a href="#rfc.section.6.1.2">Response</a></li><li class="tocline1">6.1.3 <a href="#rfc.section.6.1.3">Example Request and Response</a></li></ul></li><li class="tocline1">6.2 <a href="#rfc.section.6.2">Multi-Entity Metadata Retrieval</a><ul class="toc"><li class="tocline1">6.2.1 <a href="#rfc.section.6.2.1">Request</a></li><li class="tocline1">6.2.2 <a href="#rfc.section.6.2.2">Response</a></li><li class="tocline1">6.2.3 <a href="#rfc.section.6.2.3">Example Request and Response</a></li></ul></li></ul></li><li class="tocline0">7. <a href="#rfc.section.7">Effecient Retrieval and Caching</a></li><li class="tocline0">8. <a href="#rfc.section.8">Security Considerations</a></li><li class="tocline0"><a href="#rfc.authors">Author's Address</a></li><li class="tocline0"><a href="#rfc.ipr">Intellectual Property and Copyright Statements</a></li></ul><ul class="toc"><li class="tocline0"><a href="#rfc.figure.1">Figure 1: Example Single-Entity Metadata Retrieval Request</a></li><li class="tocline0"><a href="#rfc.figure.2">Figure 2: Example Single-Entity Metadata Retrieval Response</a></li><li class="tocline0"><a href="#rfc.figure.3">Figure 3: Example Multi-Entity Metadata Retrieval Request</a></li><li class="tocline0"><a href="#rfc.figure.4">Figure 4: Example Multi-Entity Metadata Retrieval Response</a></li></ul><hr class="noprint"><h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> Introduction</h1><h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> Notation and Convention</h2><p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119.</p><h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> Terminology</h2><p id="rfc.section.1.2.p.1"> </p><ul class="empty"><li>entity - A single logical construct for which metadata may be asserted. Generally this is a network accessible service.</li><li>metadata - A machine readable description of certain entity characteristics. Generally metadata provides information such as end point references, service contact information, etc.</li></ul><hr class="noprint"><h1 id="rfc.section.2" class="np"><a href="#rfc.section.2">2.</a> Protocol Transport</h1><p id="rfc.section.2.p.1">The metadata retrieval protocol seeks to fully employ the features of the HTTP protocol. Additionally this specification makes mandatory some optional HTTP features.</p><h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> HTTP Version</h2><p id="rfc.section.2.1.p.1">Metadata retrieval protocol responders MUST use HTTP, version 1.1 (HTTP/1.1)</p><h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> HTTP Method</h2><p id="rfc.section.2.2.p.1">All metadata retrieval request MUST use the GET method.</p><h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a> Request Headers</h2><p id="rfc.section.2.3.p.1">All metadata retrieval requests MUST include the following HTTP headers: </p><ul class="empty"><li>Accept - this header MUST contain the content-type identifying the type, or form, of metadata to be retreived</li></ul><p id="rfc.section.2.3.p.2">All metadata retrieval requests SHOULD include the following HTTP headers: </p><ul class="empty"><li>Accept-Charset</li><li>Accept-Encoding</li><li>If-Modified-Since</li><li>If-None-Match</li></ul><h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a> Response Headers</h2><p id="rfc.section.2.4.p.1">All metadata retrieval responses MUST include the following headers: </p><ul class="empty"><li>Content-Type</li><li>ETag</li></ul><p id="rfc.section.2.4.p.2">All metadata retrieval responses SHOULD include the following headers: </p><ul class="empty"><li>Content-Length</li><li>Last-Modified</li></ul><h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a> Content Encoding</h2><p id="rfc.section.2.5.p.1">In order to decrease the impact of fetching data, possibly quite frequently, all responders MUST support the use of gzip content encoding.</p><h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a> Status Codes</h2><p id="rfc.section.2.6.p.1">This protocol uses the following HTTP status codes: </p><ul class="empty"><li>200 - standard respone code when returning requested metadata</li><li>304 - response code indicating requested metadata has not been updated since the last request</li><li>400 - response code indicating that the requester's request was malformed in some fashion</li><li>401 - response code indicating the request must be authenticated before requesting metadata</li><li>404 - indicates that the requested metadata could not be found. This MUST NOT be used in order to indicate a general service error.</li><li>405 - response code indiciating that a non-GET method was used</li><li>406 - response code indicating that metadata is not available in the request content-type</li><li>500 - standard response code when something goes wrong within the responder</li><li>501 - response code indiciating that a given identifier transformation is not supported</li><li>505 - response code indicating that HTTP/1.1 was not used</li></ul><hr class="noprint"><h1 id="rfc.section.3" class="np"><a href="#rfc.section.3">3.</a> Addressing</h1><h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> Base URL</h2><p id="rfc.section.3.1.p.1">Each retrieval request is performed by issuing an HTTP GET request to a particular URL. The final component of the paths to which requests are issued are defined by the requests defined herein. A base URL proceeds such paths. Such a base URL MUST contain at least the scheme and host name components. It MAY also include a port as well as a path. It MUST NOT include any fragments. If a path is included the path required by the particular retrieval request is appended to path in the base URL.</p><h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> Identifiers</h2><p id="rfc.section.3.2.p.1">The retrieval protocol messages use identifiers to reference metadata for single entities as well as collections of entities. The assignment of such identifiers to a particular metadata document (whether it represents a single entity or a collection of them) is the responsibility of the responder. An identifier MUST correspond to, at most, one unique document. However, a single unique document MAY have more than one identifier. If a metadata document already contains a well known identifier it is RECOMMENDED that the metadata aggregator uses such natural identifiers unless doing so would cause a collision with an existing entry.</p><h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a> Transforms</h3><p id="rfc.section.3.2.1.p.1">In some cases it may be adventagous to query for metadata using a transformed identifier. For example some network protocol will transmit hashed entity identifiers. This may be done to reduce the overall size of the identifier, escape special characters, obfuscate the identifier, or for various other reasons.</p><p id="rfc.section.3.2.1.p.2">A requester indicates a request for a tranformed identifier by prepending the identifier with '{' + transformation indicator + '}'. For example, the identifier </p><div id="rfc.figure.u.1"></div> <pre>http://example.org/service</pre> <p> transformed by means of MD5 hashing would become </p><div id="rfc.figure.u.2"></div> <pre>{md5}f3678248a29ab8e8e5b1b00bee4060e0</pre> <p id="rfc.section.3.2.1.p.3">The transformation indicator MUST be composed exclusively of printable ASCII character (0x21-0x7E) excluding '{' (0x7B) and '}' (0x7D). Such an identifier need only make sense in the context of the protocol which it is used. Responders MUST support the MD5 (tranformation identifier 'md5') and SHA1 (transformation identifier 'sha') hashing algorithms as identifier transformations.</p><hr class="noprint"><h1 id="rfc.section.4" class="np"><a href="#rfc.section.4">4.</a> Content Negotiation</h1><p id="rfc.section.4.p.1">As there may be many representations for a given piece of metadata agent-drive content negotation is used to ensure the proper representation is delivered to the requester. In addition to the required usage of the Accept header a response SHOULD also support the use of the Accept-Charset header.</p><hr class="noprint"><h1 id="rfc.section.5" class="np"><a href="#rfc.section.5">5.</a> Authentication</h1><p id="rfc.section.5.p.1">All responders which require client authentication to view retrieved entries MUST support the use of HTTP basic authentication. Responsed SHOULD also support the use of X.509 client certificate authentication.</p><hr class="noprint"><h1 id="rfc.section.6" class="np"><a href="#rfc.section.6">6.</a> Protocol Operations</h1><h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> Single-Entity Metadata Retrieval</h2><p id="rfc.section.6.1.p.1">This protocol message is used to retrieve a metadata document describing a single entity.</p><h3 id="rfc.section.6.1.1"><a href="#rfc.section.6.1.1">6.1.1</a> Request</h3><p id="rfc.section.6.1.1.p.1">A Single-Entity Metadata Retrieval request is performed by issuing an HTTP GET request. All Single-Entity Metadata Retrieval requests MUST use the URL format: </p><div id="rfc.figure.u.3"></div> <pre><base_url>/entity/{id}</pre> <p> where the ID uniquely identifies an entity metadata document. The ID MUST be properly URL encoded.</p><h3 id="rfc.section.6.1.2"><a href="#rfc.section.6.1.2">6.1.2</a> Response</h3><p id="rfc.section.6.1.2.p.1">The response to a Single-Entity Metadata Retrieval request MUST be a document that provides metadata for one, singular, entity in the format described by the request's Content-Type header.</p><h3 id="rfc.section.6.1.3"><a href="#rfc.section.6.1.3">6.1.3</a> Example Request and Response</h3><div id="rfc.figure.1"></div> <pre>
GET /service/entity/http%3A%2F%2Fexample.org%2Fidp HTTP/1.1
Host: metadata.example.org
Accept: application/samlmetadata+xml
Accept-encoding: deflate, gzip
</pre> <p class="figure">Figure 1: Example Single-Entity Metadata Retrieval Request</p><p> </p><div id="rfc.figure.2"></div> <pre>
HTTP/1.x 200 OK
Content-Type: application/samlmetadata+xml
ETag: abcdefg
Last-Modified: Thu, 15 Apr 2010 12:45:26 GMT
Content-Length: 1234
<EntityDescriptor entityID="http://example.org/idp">
....
</pre> <p class="figure">Figure 2: Example Single-Entity Metadata Retrieval Response</p><h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a> Multi-Entity Metadata Retrieval</h2><p id="rfc.section.6.2.p.1">This protocol message is used to retrieve a metadata document describing a collection of entities. The meaning of such a collection is out of scope for this document. Such collections may, for example, represent all entities participating in a particular community.</p><h3 id="rfc.section.6.2.1"><a href="#rfc.section.6.2.1">6.2.1</a> Request</h3><p id="rfc.section.6.2.1.p.1">A Multi-Entity Metadata Retrieval request is performed by issuing an HTTP GET request. All Multi-Entity Metadata Retrieval requests MUST use the URL format: </p><div id="rfc.figure.u.4"></div> <pre><base_url>/entity-collection/{id}</pre> <p> where the ID uniquely identifies a the metadata of a collection of entities.</p><p id="rfc.section.6.2.1.p.2">All other IDs beginning with the at symbol ('@') are reserved. The collection name '@all' MUST correspond to the complete collection of metadata that the requester is entitled to view.</p><h3 id="rfc.section.6.2.2"><a href="#rfc.section.6.2.2">6.2.2</a> Response</h3><p id="rfc.section.6.2.2.p.1">The response to a Multi-Entity Metadata Retrieval request MUST be a document that describes a collection of entities. In the event that the collection exists, but is empty, an HTTP status code of 200 should be returned with an empty body.</p><h3 id="rfc.section.6.2.3"><a href="#rfc.section.6.2.3">6.2.3</a> Example Request and Response</h3><div id="rfc.figure.3"></div> <pre>
GET /service/entity-collection/euentities HTTP/1.1
Host: metadata.example.org
Accept: application/samlmetadata+xml
Accept-encoding: deflate, gzip
</pre> <p class="figure">Figure 3: Example Multi-Entity Metadata Retrieval Request</p><p> </p><div id="rfc.figure.4"></div> <pre>
HTTP/1.x 200 OK
Content-Type: application/samlmetadata+xml
ETag: abcdefg
Last-Modified: Thu, 15 Apr 2010 12:45:26 GMT
Content-Length: 1234
<EntitiesDescriptor>
....
</pre> <p class="figure">Figure 4: Example Multi-Entity Metadata Retrieval Response</p><hr class="noprint"><h1 id="rfc.section.7" class="np"><a href="#rfc.section.7">7.</a> Effecient Retrieval and Caching</h1><p id="rfc.section.7.p.1">As should be apparent from the required request/response headers this protocol encourages the user of content compression and caching.</p><p id="rfc.section.7.p.2">Requester's SHOULD support, and advertise support for, gzip compression unless such usage would put exceptional demands on constrained environments.</p><p id="rfc.section.7.p.3">In addition to normal, validation model, HTTP caching requester's SHOULD maintain a negative-response cache, that is cache the fact that a particular single- or multi-entity retrieval request indicated that no metadata was available for the given identifier.</p><hr class="noprint"><h1 id="rfc.section.8" class="np"><a href="#rfc.section.8">8.</a> Security Considerations</h1><p id="rfc.section.8.p.1">As metadata often contains information necessary for the secure operation of interacting services it is RECOMMENDED that some form of content integrity checking be performed. This may include the use of SSL/TLS at the transport layer, digital signatures present within the metadata document, or any other such mechanism.</p><hr class="noprint"><div class="avoidbreak"><h1 id="rfc.authors" class="np"><a href="#rfc.authors">Author's Address</a></h1><address class="vcard"><span class="vcardline"><span class="fn">Chad La Joie</span><span class="n hidden"><span class="family-name">La Joie</span><span class="given-name">Chad</span></span></span><span class="org vcardline">Itumi, LLC</span><span class="vcardline">EMail: <a href="mailto:lajoie@itumi.biz"><span class="email">lajoie@itumi.biz</span></a></span></address></div><h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1><p>Copyright © The Internet Society (2010). All Rights Reserved.</p><p>This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.</p><p>The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.</p><p>This document and the information contained herein is provided on an “AS IS” basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.</p><hr class="noprint"><h1 class="np"><a id="rfc.ipr" href="#rfc.ipr">Intellectual Property</a></h1><p>The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.</p><p>The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.</p></body></html>