Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3920

Extensible Messaging and Presence Protocol (XMPP): Core

Pages: 30
Obsoleted by:  6120
Updated by:  6122
Part 4 of 4 – Pages 75 to 30
First   Prev   None

ToP   noToC   RFC3920 - Page 75   prevText

Appendix A. Nodeprep

A.1. Introduction

This appendix defines the "Nodeprep" profile of [STRINGPREP]. As such, it specifies processing rules that will enable users to enter internationalized node identifiers in the Extensible Messaging and Presence Protocol (XMPP) and have the highest chance of getting the content of the strings correct. (An XMPP node identifier is the optional portion of an XMPP address that precedes a domain identifier and the '@' separator; it is often but not exclusively associated with an instant messaging username.) These processing rules are intended only for XMPP node identifiers and are not intended for arbitrary text or any other aspect of an XMPP address. This profile defines the following, as required by [STRINGPREP]: o The intended applicability of the profile: internationalized node identifiers within XMPP o The character repertoire that is the input and output to stringprep: Unicode 3.2, specified in Section 2 of this Appendix o The mappings used: specified in Section 3 o The Unicode normalization used: specified in Section 4 o The characters that are prohibited as output: specified in Section 5 o Bidirectional character handling: specified in Section 6

A.2. Character Repertoire

This profile uses Unicode 3.2 with the list of unassigned code points being Table A.1, both defined in Appendix A of [STRINGPREP].

A.3. Mapping

This profile specifies mapping using the following tables from [STRINGPREP]: Table B.1 Table B.2

A.4. Normalization

This profile specifies the use of Unicode normalization form KC, as described in [STRINGPREP].
ToP   noToC   RFC3920 - Page 76

A.5. Prohibited Output

This profile specifies the prohibition of using the following tables from [STRINGPREP]. Table C.1.1 Table C.1.2 Table C.2.1 Table C.2.2 Table C.3 Table C.4 Table C.5 Table C.6 Table C.7 Table C.8 Table C.9 In addition, the following Unicode characters are also prohibited: #x22 (") #x26 (&) #x27 (') #x2F (/) #x3A (:) #x3C (<) #x3E (>) #x40 (@)

A.6. Bidirectional Characters

This profile specifies the checking of bidirectional strings, as described in Section 6 of [STRINGPREP].

Appendix B. Resourceprep

B.1. Introduction

This appendix defines the "Resourceprep" profile of [STRINGPREP]. As such, it specifies processing rules that will enable users to enter internationalized resource identifiers in the Extensible Messaging and Presence Protocol (XMPP) and have the highest chance of getting the content of the strings correct. (An XMPP resource identifier is the optional portion of an XMPP address that follows a domain identifier and the '/' separator; it is often but not exclusively associated with an instant messaging session name.) These processing rules are intended only for XMPP resource identifiers and are not intended for arbitrary text or any other aspect of an XMPP address.
ToP   noToC   RFC3920 - Page 77
   This profile defines the following, as required by [STRINGPREP]:

   o  The intended applicability of the profile: internationalized
      resource identifiers within XMPP

   o  The character repertoire that is the input and output to
      stringprep: Unicode 3.2, specified in Section 2 of this Appendix

   o  The mappings used: specified in Section 3

   o  The Unicode normalization used: specified in Section 4

   o  The characters that are prohibited as output: specified in Section
      5

   o  Bidirectional character handling: specified in Section 6

B.2. Character Repertoire

This profile uses Unicode 3.2 with the list of unassigned code points being Table A.1, both defined in Appendix A of [STRINGPREP].

B.3. Mapping

This profile specifies mapping using the following tables from [STRINGPREP]: Table B.1

B.4. Normalization

This profile specifies using Unicode normalization form KC, as described in [STRINGPREP].
ToP   noToC   RFC3920 - Page 78

B.5. Prohibited Output

This profile specifies prohibiting use of the following tables from [STRINGPREP]. Table C.1.2 Table C.2.1 Table C.2.2 Table C.3 Table C.4 Table C.5 Table C.6 Table C.7 Table C.8 Table C.9

B.6. Bidirectional Characters

This profile specifies checking bidirectional strings as described in Section 6 of [STRINGPREP].

Appendix C. XML Schemas

The following XML schemas are descriptive, not normative. For schemas defining the 'jabber:client' and 'jabber:server' namespaces, refer to [XMPP-IM].

C.1. Streams namespace

<?xml version='1.0' encoding='UTF-8'?> <xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema' targetNamespace='http://etherx.jabber.org/streams' xmlns='http://etherx.jabber.org/streams' elementFormDefault='unqualified'> <xs:element name='stream'> <xs:complexType> <xs:sequence xmlns:client='jabber:client' xmlns:server='jabber:server' xmlns:db='jabber:server:dialback'> <xs:element ref='features' minOccurs='0' maxOccurs='1'/> <xs:any namespace='urn:ietf:params:xml:ns:xmpp-tls' minOccurs='0' maxOccurs='unbounded'/> <xs:any namespace='urn:ietf:params:xml:ns:xmpp-sasl' minOccurs='0'
ToP   noToC   RFC3920 - Page 79
                   maxOccurs='unbounded'/>
           <xs:choice minOccurs='0' maxOccurs='1'>
             <xs:choice minOccurs='0' maxOccurs='unbounded'>
               <xs:element ref='client:message'/>
               <xs:element ref='client:presence'/>
               <xs:element ref='client:iq'/>
             </xs:choice>
             <xs:choice minOccurs='0' maxOccurs='unbounded'>
               <xs:element ref='server:message'/>
               <xs:element ref='server:presence'/>
               <xs:element ref='server:iq'/>
               <xs:element ref='db:result'/>
               <xs:element ref='db:verify'/>
             </xs:choice>
           </xs:choice>
           <xs:element ref='error' minOccurs='0' maxOccurs='1'/>
         </xs:sequence>
         <xs:attribute name='from' type='xs:string' use='optional'/>
         <xs:attribute name='id' type='xs:NMTOKEN' use='optional'/>
         <xs:attribute name='to' type='xs:string' use='optional'/>
         <xs:attribute name='version' type='xs:decimal' use='optional'/>
         <xs:attribute ref='xml:lang' use='optional'/>
       </xs:complexType>
     </xs:element>

     <xs:element name='features'>
       <xs:complexType>
         <xs:all xmlns:tls='urn:ietf:params:xml:ns:xmpp-tls'
                 xmlns:sasl='urn:ietf:params:xml:ns:xmpp-sasl'
                 xmlns:bind='urn:ietf:params:xml:ns:xmpp-bind'
                 xmlns:sess='urn:ietf:params:xml:ns:xmpp-session'>
           <xs:element ref='tls:starttls' minOccurs='0'/>
           <xs:element ref='sasl:mechanisms' minOccurs='0'/>
           <xs:element ref='bind:bind' minOccurs='0'/>
           <xs:element ref='sess:session' minOccurs='0'/>
         </xs:all>
       </xs:complexType>
     </xs:element>

     <xs:element name='error'>
       <xs:complexType>
         <xs:sequence  xmlns:err='urn:ietf:params:xml:ns:xmpp-streams'>
           <xs:group   ref='err:streamErrorGroup'/>
           <xs:element ref='err:text'
                       minOccurs='0'
                       maxOccurs='1'/>
         </xs:sequence>
       </xs:complexType>
ToP   noToC   RFC3920 - Page 80
     </xs:element>

   </xs:schema>

C.2. Stream error namespace

<?xml version='1.0' encoding='UTF-8'?> <xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema' targetNamespace='urn:ietf:params:xml:ns:xmpp-streams' xmlns='urn:ietf:params:xml:ns:xmpp-streams' elementFormDefault='qualified'> <xs:element name='bad-format' type='empty'/> <xs:element name='bad-namespace-prefix' type='empty'/> <xs:element name='conflict' type='empty'/> <xs:element name='connection-timeout' type='empty'/> <xs:element name='host-gone' type='empty'/> <xs:element name='host-unknown' type='empty'/> <xs:element name='improper-addressing' type='empty'/> <xs:element name='internal-server-error' type='empty'/> <xs:element name='invalid-from' type='empty'/> <xs:element name='invalid-id' type='empty'/> <xs:element name='invalid-namespace' type='empty'/> <xs:element name='invalid-xml' type='empty'/> <xs:element name='not-authorized' type='empty'/> <xs:element name='policy-violation' type='empty'/> <xs:element name='remote-connection-failed' type='empty'/> <xs:element name='resource-constraint' type='empty'/> <xs:element name='restricted-xml' type='empty'/> <xs:element name='see-other-host' type='xs:string'/> <xs:element name='system-shutdown' type='empty'/> <xs:element name='undefined-condition' type='empty'/> <xs:element name='unsupported-encoding' type='empty'/> <xs:element name='unsupported-stanza-type' type='empty'/> <xs:element name='unsupported-version' type='empty'/> <xs:element name='xml-not-well-formed' type='empty'/> <xs:group name='streamErrorGroup'> <xs:choice> <xs:element ref='bad-format'/> <xs:element ref='bad-namespace-prefix'/> <xs:element ref='conflict'/> <xs:element ref='connection-timeout'/> <xs:element ref='host-gone'/> <xs:element ref='host-unknown'/> <xs:element ref='improper-addressing'/>
ToP   noToC   RFC3920 - Page 81
         <xs:element ref='internal-server-error'/>
         <xs:element ref='invalid-from'/>
         <xs:element ref='invalid-id'/>
         <xs:element ref='invalid-namespace'/>
         <xs:element ref='invalid-xml'/>
         <xs:element ref='not-authorized'/>
         <xs:element ref='policy-violation'/>
         <xs:element ref='remote-connection-failed'/>
         <xs:element ref='resource-constraint'/>
         <xs:element ref='restricted-xml'/>
         <xs:element ref='see-other-host'/>
         <xs:element ref='system-shutdown'/>
         <xs:element ref='undefined-condition'/>
         <xs:element ref='unsupported-encoding'/>
         <xs:element ref='unsupported-stanza-type'/>
         <xs:element ref='unsupported-version'/>
         <xs:element ref='xml-not-well-formed'/>
       </xs:choice>
     </xs:group>

     <xs:element name='text'>
       <xs:complexType>
         <xs:simpleContent>
           <xs:extension base='xs:string'>
             <xs:attribute ref='xml:lang' use='optional'/>
           </xs:extension>
         </xs:simpleContent>
       </xs:complexType>
     </xs:element>

     <xs:simpleType name='empty'>
       <xs:restriction base='xs:string'>
         <xs:enumeration value=''/>
       </xs:restriction>
     </xs:simpleType>

   </xs:schema>

C.3. TLS namespace

<?xml version='1.0' encoding='UTF-8'?> <xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema' targetNamespace='urn:ietf:params:xml:ns:xmpp-tls' xmlns='urn:ietf:params:xml:ns:xmpp-tls' elementFormDefault='qualified'>
ToP   noToC   RFC3920 - Page 82
     <xs:element name='starttls'>
       <xs:complexType>
         <xs:sequence>
           <xs:element
               name='required'
               minOccurs='0'
               maxOccurs='1'
               type='empty'/>
         </xs:sequence>
       </xs:complexType>
     </xs:element>

     <xs:element name='proceed' type='empty'/>
     <xs:element name='failure' type='empty'/>

     <xs:simpleType name='empty'>
       <xs:restriction base='xs:string'>
         <xs:enumeration value=''/>
       </xs:restriction>
     </xs:simpleType>

   </xs:schema>

C.4. SASL namespace

<?xml version='1.0' encoding='UTF-8'?> <xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema' targetNamespace='urn:ietf:params:xml:ns:xmpp-sasl' xmlns='urn:ietf:params:xml:ns:xmpp-sasl' elementFormDefault='qualified'> <xs:element name='mechanisms'> <xs:complexType> <xs:sequence> <xs:element name='mechanism' maxOccurs='unbounded' type='xs:string'/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name='auth'> <xs:complexType> <xs:simpleContent> <xs:extension base='empty'> <xs:attribute name='mechanism'
ToP   noToC   RFC3920 - Page 83
                           type='xs:string'
                           use='optional'/>
           </xs:extension>
         </xs:simpleContent>
       </xs:complexType>
     </xs:element>

     <xs:element name='challenge' type='xs:string'/>
     <xs:element name='response' type='xs:string'/>
     <xs:element name='abort' type='empty'/>
     <xs:element name='success' type='empty'/>

     <xs:element name='failure'>
       <xs:complexType>
         <xs:choice minOccurs='0'>
           <xs:element name='aborted' type='empty'/>
           <xs:element name='incorrect-encoding' type='empty'/>
           <xs:element name='invalid-authzid' type='empty'/>
           <xs:element name='invalid-mechanism' type='empty'/>
           <xs:element name='mechanism-too-weak' type='empty'/>
           <xs:element name='not-authorized' type='empty'/>
           <xs:element name='temporary-auth-failure' type='empty'/>
         </xs:choice>
       </xs:complexType>
     </xs:element>
     <xs:simpleType name='empty'>
       <xs:restriction base='xs:string'>
         <xs:enumeration value=''/>
       </xs:restriction>
     </xs:simpleType>

   </xs:schema>

C.5. Resource binding namespace

<?xml version='1.0' encoding='UTF-8'?> <xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema' targetNamespace='urn:ietf:params:xml:ns:xmpp-bind' xmlns='urn:ietf:params:xml:ns:xmpp-bind' elementFormDefault='qualified'> <xs:element name='bind'> <xs:complexType> <xs:choice minOccurs='0' maxOccurs='1'> <xs:element name='resource' type='xs:string'/> <xs:element name='jid' type='xs:string'/>
ToP   noToC   RFC3920 - Page 84
         </xs:choice>
       </xs:complexType>
     </xs:element>

   </xs:schema>

C.6. Dialback namespace

<?xml version='1.0' encoding='UTF-8'?> <xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema' targetNamespace='jabber:server:dialback' xmlns='jabber:server:dialback' elementFormDefault='qualified'> <xs:element name='result'> <xs:complexType> <xs:simpleContent> <xs:extension base='xs:token'> <xs:attribute name='from' type='xs:string' use='required'/> <xs:attribute name='to' type='xs:string' use='required'/> <xs:attribute name='type' use='optional'> <xs:simpleType> <xs:restriction base='xs:NCName'> <xs:enumeration value='invalid'/> <xs:enumeration value='valid'/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:element name='verify'> <xs:complexType> <xs:simpleContent> <xs:extension base='xs:token'> <xs:attribute name='from' type='xs:string' use='required'/> <xs:attribute name='id' type='xs:NMTOKEN' use='required'/> <xs:attribute name='to' type='xs:string' use='required'/> <xs:attribute name='type' use='optional'> <xs:simpleType> <xs:restriction base='xs:NCName'> <xs:enumeration value='invalid'/> <xs:enumeration value='valid'/> </xs:restriction>
ToP   noToC   RFC3920 - Page 85
               </xs:simpleType>
             </xs:attribute>
           </xs:extension>
         </xs:simpleContent>
       </xs:complexType>
     </xs:element>

   </xs:schema>

C.7. Stanza error namespace

<?xml version='1.0' encoding='UTF-8'?> <xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema' targetNamespace='urn:ietf:params:xml:ns:xmpp-stanzas' xmlns='urn:ietf:params:xml:ns:xmpp-stanzas' elementFormDefault='qualified'> <xs:element name='bad-request' type='empty'/> <xs:element name='conflict' type='empty'/> <xs:element name='feature-not-implemented' type='empty'/> <xs:element name='forbidden' type='empty'/> <xs:element name='gone' type='xs:string'/> <xs:element name='internal-server-error' type='empty'/> <xs:element name='item-not-found' type='empty'/> <xs:element name='jid-malformed' type='empty'/> <xs:element name='not-acceptable' type='empty'/> <xs:element name='not-allowed' type='empty'/> <xs:element name='payment-required' type='empty'/> <xs:element name='recipient-unavailable' type='empty'/> <xs:element name='redirect' type='xs:string'/> <xs:element name='registration-required' type='empty'/> <xs:element name='remote-server-not-found' type='empty'/> <xs:element name='remote-server-timeout' type='empty'/> <xs:element name='resource-constraint' type='empty'/> <xs:element name='service-unavailable' type='empty'/> <xs:element name='subscription-required' type='empty'/> <xs:element name='undefined-condition' type='empty'/> <xs:element name='unexpected-request' type='empty'/> <xs:group name='stanzaErrorGroup'> <xs:choice> <xs:element ref='bad-request'/> <xs:element ref='conflict'/> <xs:element ref='feature-not-implemented'/> <xs:element ref='forbidden'/> <xs:element ref='gone'/>
ToP   noToC   RFC3920 - Page 86
         <xs:element ref='internal-server-error'/>
         <xs:element ref='item-not-found'/>
         <xs:element ref='jid-malformed'/>
         <xs:element ref='not-acceptable'/>
         <xs:element ref='not-allowed'/>
         <xs:element ref='payment-required'/>
         <xs:element ref='recipient-unavailable'/>
         <xs:element ref='redirect'/>
         <xs:element ref='registration-required'/>
         <xs:element ref='remote-server-not-found'/>
         <xs:element ref='remote-server-timeout'/>
         <xs:element ref='resource-constraint'/>
         <xs:element ref='service-unavailable'/>
         <xs:element ref='subscription-required'/>
         <xs:element ref='undefined-condition'/>
         <xs:element ref='unexpected-request'/>
       </xs:choice>
     </xs:group>

     <xs:element name='text'>
       <xs:complexType>
         <xs:simpleContent>
           <xs:extension base='xs:string'>
             <xs:attribute ref='xml:lang' use='optional'/>
           </xs:extension>
         </xs:simpleContent>
       </xs:complexType>
     </xs:element>

     <xs:simpleType name='empty'>
       <xs:restriction base='xs:string'>
         <xs:enumeration value=''/>
       </xs:restriction>
     </xs:simpleType>

   </xs:schema>
ToP   noToC   RFC3920 - Page 87

Appendix D. Differences Between Core Jabber Protocols and XMPP

This section is non-normative. XMPP has been adapted from the protocols originally developed in the Jabber open-source community, which can be thought of as "XMPP 0.9". Because there exists a large installed base of Jabber implementations and deployments, it may be helpful to specify the key differences between the relevant Jabber protocols and XMPP in order to expedite and encourage upgrades of those implementations and deployments to XMPP. This section summarizes the core differences, while the corresponding section of [XMPP-IM] summarizes the differences that relate specifically to instant messaging and presence applications.

D.1. Channel Encryption

It was common practice in the Jabber community to use SSL for channel encryption on ports other than 5222 and 5269 (the convention is to use ports 5223 and 5270). XMPP uses TLS over the IANA-registered ports for channel encryption, as defined under Use of TLS (Section 5) herein.

D.2. Authentication

The client-server authentication protocol developed in the Jabber community used a basic IQ interaction qualified by the 'jabber:iq:auth' namespace (documentation of this protocol is contained in [JEP-0078], published by the Jabber Software Foundation [JSF]). XMPP uses SASL for authentication, as defined under Use of SASL (Section 6) herein. The Jabber community did not develop an authentication protocol for server-to-server communications, only the Server Dialback (Section 8) protocol to prevent server spoofing. XMPP supersedes Server Dialback with a true server-to-server authentication protocol, as defined under Use of SASL (Section 6) herein.

D.3. Resource Binding

Resource binding in the Jabber community was handled via the 'jabber:iq:auth' namespace (which was also used for client authentication with a server). XMPP defines a dedicated namespace for resource binding as well as the ability for a server to generate a resource identifier on behalf of a client, as defined under Resource Binding (Section 7).
ToP   noToC   RFC3920 - Page 88

D.4. JID Processing

JID processing was somewhat loosely defined by the Jabber community (documentation of forbidden characters and case handling is contained in [JEP-0029], published by the Jabber Software Foundation [JSF]). XMPP specifies the use of [NAMEPREP] for domain identifiers and supplements Nameprep with two additional [STRINGPREP] profiles for JID processing: Nodeprep (Appendix A) for node identifiers and Resourceprep (Appendix B) for resource identifiers.

D.5. Error Handling

Stream-related errors were handled in the Jabber community via XML character data text in a <stream:error/> element. In XMPP, stream-related errors are handled via an extensible mechanism defined under Stream Errors (Section 4.7) herein. Stanza-related errors were handled in the Jabber community via HTTP-style error codes. In XMPP, stanza-related errors are handled via an extensible mechanism defined under Stanza Errors (Section 9.3) herein. (Documentation of a mapping between Jabber and XMPP error handling mechanisms is contained in [JEP-0086], published by the Jabber Software Foundation [JSF].)

D.6. Internationalization

Although use of UTF-8 has always been standard practice within the Jabber community, the community did not define mechanisms for specifying the language of human-readable text provided in XML character data. XMPP specifies the use of the 'xml:lang' attribute in such contexts, as defined under Stream Attributes (Section 4.4) and xml:lang (Section 9.1.5) herein.

D.7. Stream Version Attribute

The Jabber community did not include a 'version' attribute in stream headers. XMPP specifies inclusion of that attribute as a way to signal support for the stream features (authentication, encryption, etc.) defined under Version Support (Section 4.4.1) herein.
ToP   noToC   RFC3920 - Page 89

Contributors

Most of the core aspects of the Extensible Messaging and Presence Protocol were developed originally within the Jabber open-source community in 1999. This community was founded by Jeremie Miller, who released source code for the initial version of the jabber server in January 1999. Major early contributors to the base protocol also included Ryan Eatmon, Peter Millard, Thomas Muldowney, and Dave Smith. Work by the XMPP Working Group has concentrated especially on security and internationalization; in these areas, protocols for the use of TLS and SASL were originally contributed by Rob Norris, and stringprep profiles were originally contributed by Joe Hildebrand. The error code syntax was suggested by Lisa Dusseault.

Acknowledgements

Thanks are due to a number of individuals in addition to the contributors listed. Although it is difficult to provide a complete list, the following individuals were particularly helpful in defining the protocols or in commenting on the specifications in this memo: Thomas Charron, Richard Dobson, Sam Hartman, Schuyler Heath, Jonathan Hogg, Cullen Jennings, Craig Kaes, Jacek Konieczny, Alexey Melnikov, Keith Minkler, Julian Missig, Pete Resnick, Marshall Rose, Alexey Shchepin, Jean-Louis Seguineau, Iain Shigeoka, Greg Troxel, and David Waite. Thanks also to members of the XMPP Working Group and the IETF community for comments and feedback provided throughout the life of this memo.

Author's Address

Peter Saint-Andre (editor) Jabber Software Foundation EMail: stpeter@jabber.org
ToP   noToC   RFC3920 - Page 90
Full Copyright Statement

   Copyright (C) The Internet Society (2004).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
   INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the IETF's procedures with respect to rights in IETF Documents can
   be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.