tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6120

 
 
 

Extensible Messaging and Presence Protocol (XMPP): Core

Part 8 of 9, p. 172 to 189
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 172 
15.  Conformance Requirements

   This section describes a protocol feature set that summarizes the
   conformance requirements of this specification.  This feature set is
   appropriate for use in software certification, interoperability
   testing, and implementation reports.  For each feature, this section
   provides the following information:

   o  A human-readable name

   o  An informational description

   o  A reference to the particular section of this document that
      normatively defines the feature

   o  Whether the feature applies to the Client role, the Server role,
      or both (where "N/A" signifies that the feature is not applicable
      to the specified role)

   o  Whether the feature MUST or SHOULD be implemented, where the
      capitalized terms are to be understood as described in [KEYWORDS]

   The feature set specified here attempts to adhere to the concepts and
   formats proposed by Larry Masinter within the IETF's NEWTRK Working
   Group in 2005, as captured in [INTEROP].  Although this feature set
   is more detailed than called for by [REPORTS], it provides a suitable
   basis for the generation of implementation reports to be submitted in
   support of advancing this specification from Proposed Standard to
   Draft Standard in accordance with [PROCESS].

   Feature:  bind-gen
   Description:  Generate a random resource on demand.
   Section:  Section 7.6
   Roles:  Client N/A, Server MUST.

   Feature:  bind-mtn
   Description:  Consider resource binding as mandatory-to-negotiate.
   Section:  Section 7.3.1
   Roles:  Client MUST, Server MUST.

Top      Up      ToC       Page 173 
   Feature:  bind-restart
   Description:  Do not restart the stream after negotiation of resource
      binding.
   Section:  Section 7.3.2
   Roles:  Client MUST, Server MUST.

   Feature:  bind-support
   Description:  Support binding of client resources to an authenticated
      stream.
   Section:  Section 7
   Roles:  Client MUST, Server MUST.

   Feature:  sasl-correlate
   Description:  When authenticating a stream peer using SASL, correlate
      the authentication identifier resulting from SASL negotiation with
      the 'from' address (if any) of the stream header it received from
      the peer.
   Section:  Section 6.4.6
   Roles:  Client SHOULD, Server SHOULD.

   Feature:  sasl-errors
   Description:  Support SASL errors during the negotiation process.
   Section:  Section 6.5
   Roles:  Client MUST, Server MUST.

   Feature:  sasl-mtn
   Description:  Consider SASL as mandatory-to-negotiate.
   Section:  Section 6.3.1
   Roles:  Client MUST, Server MUST.

   Feature:  sasl-restart
   Description:  Initiate or handle a stream restart after SASL
      negotiation.
   Section:  Section 6.3.2
   Roles:  Client MUST, Server MUST.

   Feature:  sasl-support
   Description:  Support the Simple Authentication and Security Layer
      for stream authentication.
   Section:  Section 6
   Roles:  Client MUST, Server MUST.

   Feature:  security-mti-auth-scram
   Description:  Support the SASL SCRAM mechanism for authentication
      only (this implies support for both the SCRAM-SHA-1 and
      SCRAM-SHA-1-PLUS variants).
   Section:  Section 13.8
   Roles:  Client MUST, Server MUST.

Top      Up      ToC       Page 174 
   Feature:  security-mti-both-external
   Description:  Support TLS with SASL EXTERNAL for confidentiality and
      authentication.
   Section:  Section 13.8
   Roles:  Client SHOULD, Server MUST.

   Feature:  security-mti-both-plain
   Description:  Support TLS using the TLS_RSA_WITH_AES_128_CBC_SHA
      ciphersuite plus the SASL PLAIN mechanism for confidentiality and
      authentication.
   Section:  Section 13.8
   Roles:  Client SHOULD, Server MAY.

   Feature:  security-mti-both-scram
   Description:  Support TLS using the TLS_RSA_WITH_AES_128_CBC_SHA
      ciphersuite plus the SCRAM-SHA-1 and SCRAM-SHA-1-PLUS variants of
      the SASL SCRAM mechanism for confidentiality and authentication.
   Section:  Section 13.8
   Roles:  Client MUST, Server MUST.

   Feature:  security-mti-confidentiality
   Description:  Support TLS using the TLS_RSA_WITH_AES_128_CBC_SHA
      ciphersuite for confidentiality only.
   Section:  Section 13.8
   Roles:  Client N/A, Server SHOULD.

   Feature:  stanza-attribute-from
   Description:  Support the common 'from' attribute for all stanza
      kinds.
   Section:  Section 8.1.2
   Roles:  Client MUST, Server MUST.

   Feature:  stanza-attribute-from-stamp
   Description:  Stamp or rewrite the 'from' address of all stanzas
      received from connected clients.
   Section:  Section 8.1.2.1
   Roles:  Client N/A, Server MUST.

   Feature:  stanza-attribute-from-validate
   Description:  Validate the 'from' address of all stanzas received
      from peer servers.
   Section:  Section 8.1.2.2
   Roles:  Client N/A, Server MUST.

   Feature:  stanza-attribute-id
   Description:  Support the common 'id' attribute for all stanza kinds.
   Section:  Section 8.1.3
   Roles:  Client MUST, Server MUST.

Top      Up      ToC       Page 175 
   Feature:  stanza-attribute-to
   Description:  Support the common 'to' attribute for all stanza kinds.
   Section:  Section 8.1.1
   Roles:  Client MUST, Server MUST.

   Feature:  stanza-attribute-to-validate
   Description:  Ensure that all stanzas received from peer servers
      include a 'to' address.
   Section:  Section 8.1.1
   Roles:  Client N/A, Server MUST.

   Feature:  stanza-attribute-type
   Description:  Support the common 'type' attribute for all stanza
      kinds.
   Section:  Section 8.1.4
   Roles:  Client MUST, Server MUST.

   Feature:  stanza-attribute-xmllang
   Description:  Support the common 'xml:lang' attribute for all stanza
      kinds.
   Section:  Section 8.1.5
   Roles:  Client MUST, Server MUST.

   Feature:  stanza-error
   Description:  Generate and handle stanzas of type "error" for all
      stanza kinds.
   Section:  Section 8.3
   Roles:  Client MUST, Server MUST.

   Feature:  stanza-error-child
   Description:  Ensure that stanzas of type "error" include an <error/>
      child element.
   Section:  Section 8.3
   Roles:  Client MUST, Server MUST.

   Feature:  stanza-error-id
   Description:  Ensure that stanzas of type "error" preserve the 'id'
      provided in the triggering stanza.
   Section:  Section 8.3
   Roles:  Client MUST, Server MUST.

   Feature:  stanza-error-reply
   Description:  Do not reply to a stanza of type "error" with another
      stanza of type "error".
   Section:  Section 8.3
   Roles:  Client MUST, Server MUST.

Top      Up      ToC       Page 176 
   Feature:  stanza-extension
   Description:  Correctly process XML data qualified by an unsupported
      XML namespace, where "correctly process" means to ignore that
      portion of the stanza in the case of a message or presence stanza
      and return an error in the case of an IQ stanza (for the intended
      recipient), and to route or deliver the stanza (for a routing
      entity such as a server).
   Section:  Section 8.4
   Roles:  Client MUST, Server MUST.

   Feature:  stanza-iq-child
   Description:  Include exactly one child element in an <iq/> stanza of
      type "get" or "set", zero or one child elements in an <iq/> stanza
      of type "result", and one or two child elements in an <iq/> stanza
      of type "error".
   Section:  Section 8.2.3
   Roles:  Client MUST, Server MUST.

   Feature:  stanza-iq-id
   Description:  Ensure that all <iq/> stanzas include an 'id'
      attribute.
   Section:  Section 8.2.3
   Roles:  Client MUST, Server MUST.

   Feature:  stanza-iq-reply
   Description:  Reply to an <iq/> stanza of type "get" or "set" with an
      <iq/> stanza of type "result" or "error".
   Section:  Section 8.2.3
   Roles:  Client MUST, Server MUST.

   Feature:  stanza-iq-type
   Description:  Ensure that all <iq/> stanzas include a 'type'
      attribute whose value is "get", "set", "result", or "error".
   Section:  Section 8.2.3
   Roles:  Client MUST, Server MUST.

   Feature:  stanza-kind-iq
   Description:  Support the <iq/> stanza.
   Section:  Section 8.2.3
   Roles:  Client MUST, Server MUST.

   Feature:  stanza-kind-message
   Description:  Support the <message/> stanza.
   Section:  Section 8.2.1
   Roles:  Client MUST, Server MUST.

Top      Up      ToC       Page 177 
   Feature:  stanza-kind-presence
   Description:  Support the <presence/> stanza.
   Section:  Section 8.2.2
   Roles:  Client MUST, Server MUST.

   Feature:  stream-attribute-initial-from
   Description:  Include a 'from' attribute in the initial stream
      header.
   Section:  Section 4.7.1
   Roles:  Client SHOULD, Server MUST.

   Feature:  stream-attribute-initial-lang
   Description:  Include an 'xml:lang' attribute in the initial stream
      header.
   Section:  Section 4.7.4
   Roles:  Client SHOULD, Server SHOULD.

   Feature:  stream-attribute-initial-to
   Description:  Include a 'to' attribute in the initial stream header.
   Section:  Section 4.7.2
   Roles:  Client MUST, Server MUST.

   Feature:  stream-attribute-response-from
   Description:  Include a 'from' attribute in the response stream
      header.
   Section:  Section 4.7.1
   Roles:  Client N/A, Server MUST.

   Feature:  stream-attribute-response-id
   Description:  Include an 'id' attribute in the response stream
      header.
   Section:  Section 4.7.3
   Roles:  Client N/A, Server MUST.

   Feature:  stream-attribute-response-id-unique
   Description:  Ensure that the 'id' attribute in the response stream
      header is unique within the context of the receiving entity.
   Section:  Section 4.7.3
   Roles:  Client N/A, Server MUST.

   Feature:  stream-attribute-response-to
   Description:  Include a 'to' attribute in the response stream header.
   Section:  Section 4.7.2
   Roles:  Client N/A, Server SHOULD.

Top      Up      ToC       Page 178 
   Feature:  stream-error-generate
   Description:  Generate a stream error (followed by a closing stream
      tag and termination of the TCP connection) upon detecting a
      stream-related error condition.
   Section:  Section 4.9
   Roles:  Client MUST, Server MUST.

   Feature:  stream-fqdn-resolution
   Description:  Resolve FQDNs before opening a TCP connection to the
      receiving entity.
   Section:  Section 3.2
   Roles:  Client MUST, Server MUST.

   Feature:  stream-negotiation-complete
   Description:  Do not consider the stream negotiation process to be
      complete until the receiving entity sends a stream features
      advertisement that is empty or that contains only voluntary-to-
      negotiate features.
   Section:  Section 4.3.5
   Roles:  Client MUST, Server MUST.

   Feature:  stream-negotiation-features
   Description:  Send stream features after sending a response stream
      header.
   Section:  Section 4.3.2
   Roles:  Client N/A, Server MUST.

   Feature:  stream-negotiation-restart
   Description:  Consider the previous stream to be replaced upon
      negotiation of a stream feature that necessitates a stream
      restart, and send or receive a new initial stream header after
      negotiation of such a stream feature.
   Section:  Section 4.3.3
   Roles:  Client MUST, Server MUST.

   Feature:  stream-reconnect
   Description:  Reconnect with exponential backoff if a TCP connection
      is terminated unexpectedly.
   Section:  Section 3.3
   Roles:  Client MUST, Server MUST.

   Feature:  stream-tcp-binding
   Description:  Bind an XML stream to a TCP connection.
   Section:  Section 3
   Roles:  Client MUST, Server MUST.

Top      Up      ToC       Page 179 
   Feature:  tls-certs
   Description:  Check the identity specified in a certificate that is
      presented during TLS negotiation.
   Section:  Section 13.7.2
   Roles:  Client MUST, Server MUST.

   Feature:  tls-mtn
   Description:  Consider TLS as mandatory-to-negotiate if STARTTLS is
      the only feature advertised or if the STARTTLS feature
      advertisement includes an empty <required/> element.
   Section:  Section 5.3.1
   Roles:  Client MUST, Server MUST.

   Feature:  tls-restart
   Description:  Initiate or handle a stream restart after TLS
      negotiation.
   Section:  Section 5.3.2
   Roles:  Client MUST, Server MUST.

   Feature:  tls-support
   Description:  Support Transport Layer Security for stream encryption.
   Section:  Section 5
   Roles:  Client MUST, Server MUST.

   Feature:  tls-correlate
   Description:  When validating a certificate presented by a stream
      peer during TLS negotiation, correlate the validated identity with
      the 'from' address (if any) of the stream header it received from
      the peer.
   Section:  Section 13.7.2
   Roles:  Client SHOULD, Server SHOULD.

   Feature:  xml-namespace-content-client
   Description:  Support 'jabber:client' as a content namespace.
   Section:  Section 4.8.2
   Roles:  Client MUST, Server MUST.

   Feature:  xml-namespace-content-server
   Description:  Support 'jabber:server' as a content namespace.
   Section:  Section 4.8.2
   Roles:  Client N/A, Server MUST.

   Feature:  xml-namespace-streams-declaration
   Description:  Ensure that there is a namespace declaration for the
      'http://etherx.jabber.org/streams' namespace.
   Section:  Section 4.8.1
   Roles:  Client MUST, Server MUST.

Top      Up      ToC       Page 180 
   Feature:  xml-namespace-streams-prefix
   Description:  Ensure that all elements qualified by the
      'http://etherx.jabber.org/streams' namespace are prefixed by the
      prefix (if any) defined in the namespace declaration.
   Section:  Section 4.8.1
   Roles:  Client MUST, Server MUST.

   Feature:  xml-restriction-comment
   Description:  Do not generate or accept XML comments.
   Section:  Section 11.1
   Roles:  Client MUST, Server MUST.

   Feature:  xml-restriction-dtd
   Description:  Do not generate or accept internal or external DTD
      subsets.
   Section:  Section 11.1
   Roles:  Client MUST, Server MUST.

   Feature:  xml-restriction-pi
   Description:  Do not generate or accept XML processing instructions.
   Section:  Section 11.1
   Roles:  Client MUST, Server MUST.

   Feature:  xml-restriction-ref
   Description:  Do not generate or accept internal or external entity
      references with the exception of the predefined entities.
   Section:  Section 11.1
   Roles:  Client MUST, Server MUST.

   Feature:  xml-wellformed-xml
   Description:  Do not generate or accept data that is not XML-well-
      formed.
   Section:  Section 11.3
   Roles:  Client MUST, Server MUST.

   Feature:  xml-wellformed-ns
   Description:  Do not generate or accept data that is not namespace-
      well-formed.
   Section:  Section 11.3
   Roles:  Client MUST, Server MUST.

Top      Up      ToC       Page 181 
16.  References

16.1.  Normative References

   [BASE64]        Josefsson, S., "The Base16, Base32, and Base64 Data
                   Encodings", RFC 4648, October 2006.

   [CHANNEL]       Williams, N., "On the Use of Channel Bindings to
                   Secure Channels", RFC 5056, November 2007.

   [CHANNEL-TLS]   Altman, J., Williams, N., and L. Zhu, "Channel
                   Bindings for TLS", RFC 5929, July 2010.

   [CHARSETS]      Alvestrand, H., "IETF Policy on Character Sets and
                   Languages", BCP 18, RFC 2277, January 1998.

   [DNS-CONCEPTS]  Mockapetris, P., "Domain names - concepts and
                   facilities", STD 13, RFC 1034, November 1987.

   [DNS-SRV]       Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR
                   for specifying the location of services (DNS SRV)",
                   RFC 2782, February 2000.

   [IPv6-ADDR]     Kawamura, S. and M. Kawashima, "A Recommendation for
                   IPv6 Address Text Representation", RFC 5952,
                   August 2010.

   [KEYWORDS]      Bradner, S., "Key words for use in RFCs to Indicate
                   Requirement Levels", BCP 14, RFC 2119, March 1997.

   [LANGMATCH]     Phillips, A. and M. Davis, "Matching of Language
                   Tags", BCP 47, RFC 4647, September 2006.

   [LANGTAGS]      Phillips, A. and M. Davis, "Tags for Identifying
                   Languages", BCP 47, RFC 5646, September 2009.

   [OCSP]          Myers, M., Ankney, R., Malpani, A., Galperin, S., and
                   C. Adams, "X.509 Internet Public Key Infrastructure
                   Online Certificate Status Protocol - OCSP", RFC 2560,
                   June 1999.

   [PKIX]          Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
                   Housley, R., and W. Polk, "Internet X.509 Public Key
                   Infrastructure Certificate and Certificate Revocation
                   List (CRL) Profile", RFC 5280, May 2008.

Top      Up      ToC       Page 182 
   [PKIX-ALGO]     Jonsson, J. and B. Kaliski, "Public-Key Cryptography
                   Standards (PKCS) #1: RSA Cryptography Specifications
                   Version 2.1", RFC 3447, February 2003.

   [PKIX-SRV]      Santesson, S., "Internet X.509 Public Key
                   Infrastructure Subject Alternative Name for
                   Expression of Service Name", RFC 4985, August 2007.

   [PLAIN]         Zeilenga, K., "The PLAIN Simple Authentication and
                   Security Layer (SASL) Mechanism", RFC 4616,
                   August 2006.

   [RANDOM]        Eastlake, D., Schiller, J., and S. Crocker,
                   "Randomness Requirements for Security", BCP 106,
                   RFC 4086, June 2005.

   [SASL]          Melnikov, A. and K. Zeilenga, "Simple Authentication
                   and Security Layer (SASL)", RFC 4422, June 2006.

   [SCRAM]         Newman, C., Menon-Sen, A., Melnikov, A., and N.
                   Williams, "Salted Challenge Response Authentication
                   Mechanism (SCRAM) SASL and GSS-API Mechanisms",
                   RFC 5802, July 2010.

   [STRONGSEC]     Schiller, J., "Strong Security Requirements for
                   Internet Engineering Task Force Standard Protocols",
                   BCP 61, RFC 3365, August 2002.

   [TCP]           Postel, J., "Transmission Control Protocol", STD 7,
                   RFC 793, September 1981.

   [TLS]           Dierks, T. and E. Rescorla, "The Transport Layer
                   Security (TLS) Protocol Version 1.2", RFC 5246,
                   August 2008.

   [TLS-CERTS]     Saint-Andre, P. and J. Hodges, "Representation and
                   Verification of Domain-Based Application Service
                   Identity within Internet Public Key Infrastructure
                   Using X.509 (PKIX) Certificates in the Context of
                   Transport Layer Security (TLS)", RFC 6125,
                   March 2011.

   [TLS-NEG]       Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
                   "Transport Layer Security (TLS) Renegotiation
                   Indication Extension", RFC 5746, February 2010.

   [TLS-SSL2]      Turner, S. and T. Polk, "Prohibiting Secure Sockets
                   Layer (SSL) Version 2.0", RFC 6176, March 2011.

Top      Up      ToC       Page 183 
   [UCS2]          International Organization for Standardization,
                   "Information Technology - Universal Multiple-octet
                   coded Character Set (UCS) - Amendment 2: UCS
                   Transformation Format 8 (UTF-8)", ISO Standard
                   10646-1 Addendum 2, October 1996.

   [UNICODE]       The Unicode Consortium, "The Unicode Standard,
                   Version 6.0", 2010,
                   <http://www.unicode.org/versions/Unicode6.0.0/>.

   [UTF-8]         Yergeau, F., "UTF-8, a transformation format of ISO
                   10646", STD 63, RFC 3629, November 2003.

   [URI]           Berners-Lee, T., Fielding, R., and L. Masinter,
                   "Uniform Resource Identifier (URI): Generic Syntax",
                   STD 66, RFC 3986, January 2005.

   [X509]          International Telecommunications Union, "Information
                   technology - Open Systems Interconnection - The
                   Directory: Public-key and attribute certificate
                   frameworks", ITU-T Recommendation X.509, ISO Standard
                   9594-8, March 2000.

   [XML]           Maler, E., Yergeau, F., Sperberg-McQueen, C., Paoli,
                   J., and T. Bray, "Extensible Markup Language (XML)
                   1.0 (Fifth Edition)", World Wide Web Consortium
                   Recommendation REC-xml-20081126, November 2008,
                   <http://www.w3.org/TR/2008/REC-xml-20081126>.

   [XML-GUIDE]     Hollenbeck, S., Rose, M., and L. Masinter,
                   "Guidelines for the Use of Extensible Markup Language
                   (XML) within IETF Protocols", BCP 70, RFC 3470,
                   January 2003.

   [XML-MEDIA]     Murata, M., St. Laurent, S., and D. Kohn, "XML Media
                   Types", RFC 3023, January 2001.

   [XML-NAMES]     Thompson, H., Hollander, D., Layman, A., Bray, T.,
                   and R. Tobin, "Namespaces in XML 1.0 (Third
                   Edition)", World Wide Web Consortium
                   Recommendation REC-xml-names-20091208, December 2009,
                   <http://www.w3.org/TR/2009/REC-xml-names-20091208>.

   [XMPP-ADDR]     Saint-Andre, P., "Extensible Messaging and Presence
                   Protocol (XMPP): Address Format", RFC 6122,
                   March 2011.

Top      Up      ToC       Page 184 
   [XMPP-IM]       Saint-Andre, P., "Extensible Messaging and Presence
                   Protocol (XMPP): Instant Messaging and Presence",
                   RFC 6121, March 2011.

16.2.  Informative References

   [AAA]           Housley, R. and B. Aboba, "Guidance for
                   Authentication, Authorization, and Accounting (AAA)
                   Key Management", BCP 132, RFC 4962, July 2007.

   [ABNF]          Crocker, D. and P. Overell, "Augmented BNF for Syntax
                   Specifications: ABNF", STD 68, RFC 5234,
                   January 2008.

   [ACAP]          Newman, C. and J. Myers, "ACAP -- Application
                   Configuration Access Protocol", RFC 2244,
                   November 1997.

   [ANONYMOUS]     Zeilenga, K., "Anonymous Simple Authentication and
                   Security Layer (SASL) Mechanism", RFC 4505,
                   June 2006.

   [ASN.1]         CCITT, "Recommendation X.208: Specification of
                   Abstract Syntax Notation One (ASN.1)", 1988.

   [DIGEST-MD5]    Leach, P. and C. Newman, "Using Digest Authentication
                   as a SASL Mechanism", RFC 2831, May 2000.

   [DNSSEC]        Arends, R., Austein, R., Larson, M., Massey, D., and
                   S. Rose, "DNS Security Introduction and
                   Requirements", RFC 4033, March 2005.

   [DNS-TXT]       Rosenbaum, R., "Using the Domain Name System To Store
                   Arbitrary String Attributes", RFC 1464, May 1993.

   [DOS]           Handley, M., Rescorla, E., and IAB, "Internet Denial-
                   of-Service Considerations", RFC 4732, December 2006.

   [E2E-REQS]      Saint-Andre, P., "Requirements for End-to-End
                   Encryption in the Extensible Messaging and Presence
                   Protocol (XMPP)", Work in Progress, March 2010.

   [EMAIL-ARCH]    Crocker, D., "Internet Mail Architecture", RFC 5598,
                   July 2009.

Top      Up      ToC       Page 185 
   [ETHERNET]      "Information technology - Telecommunications and
                   information exchange between systems - Local and
                   metropolitan area networks - Specific requirements -
                   Part 3: Carrier sense multiple access with collision
                   detection (CSMA/CD) access method and physical layer
                   specifications", IEEE Standard 802.3, September 1998.

   [GSS-API]       Linn, J., "Generic Security Service Application
                   Program Interface Version 2, Update 1", RFC 2743,
                   January 2000.

   [HASHES]        Hoffman, P. and B. Schneier, "Attacks on
                   Cryptographic Hashes in Internet Protocols",
                   RFC 4270, November 2005.

   [HTTP]          Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
                   Masinter, L., Leach, P., and T. Berners-Lee,
                   "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616,
                   June 1999.

   [IANA-GUIDE]    Narten, T. and H. Alvestrand, "Guidelines for Writing
                   an IANA Considerations Section in RFCs", BCP 26,
                   RFC 5226, May 2008.

   [IANA-PORTS]    Cotton, M., Eggert, L., Touch, J., Westerlund, M.,
                   and S. Cheshire, "Internet Assigned Numbers Authority
                   (IANA) Procedures for the Management of the Transport
                   Protocol Port Number and Service Name Registry", Work
                   in Progress, February 2011.

   [IMAP]          Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
                   VERSION 4rev1", RFC 3501, March 2003.

   [IMP-REQS]      Day, M., Aggarwal, S., and J. Vincent, "Instant
                   Messaging / Presence Protocol Requirements",
                   RFC 2779, February 2000.

   [INTEROP]       Masinter, L., "Formalizing IETF Interoperability
                   Reporting", Work in Progress, October 2005.

   [IRC]           Kalt, C., "Internet Relay Chat: Architecture",
                   RFC 2810, April 2000.

   [IRI]           Duerst, M. and M. Suignard, "Internationalized
                   Resource Identifiers (IRIs)", RFC 3987, January 2005.

Top      Up      ToC       Page 186 
   [LDAP]          Zeilenga, K., "Lightweight Directory Access Protocol
                   (LDAP): Technical Specification Road Map", RFC 4510,
                   June 2006.

   [LINKLOCAL]     Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
                   Configuration of IPv4 Link-Local Addresses",
                   RFC 3927, May 2005.

   [MAILBOXES]     Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES,
                   ROLES AND FUNCTIONS", RFC 2142, May 1997.

   [POP3]          Myers, J. and M. Rose, "Post Office Protocol -
                   Version 3", STD 53, RFC 1939, May 1996.

   [PROCESS]       Bradner, S., "The Internet Standards Process --
                   Revision 3", BCP 9, RFC 2026, October 1996.

   [REPORTS]       Dusseault, L. and R. Sparks, "Guidance on
                   Interoperation and Implementation Reports for
                   Advancement to Draft Standard", BCP 9, RFC 5657,
                   September 2009.

   [REST]          Fielding, R., "Architectural Styles and the Design of
                   Network-based Software Architectures",  2000.

   [RFC3920]       Saint-Andre, P., Ed., "Extensible Messaging and
                   Presence Protocol (XMPP): Core", RFC 3920,
                   October 2004.

   [RFC3921]       Saint-Andre, P., Ed., "Extensible Messaging and
                   Presence Protocol (XMPP): Instant Messaging and
                   Presence", RFC 3921, October 2004.

   [SASLPREP]      Zeilenga, K., "SASLprep: Stringprep Profile for User
                   Names and Passwords", RFC 4013, February 2005.

   [SEC-TERMS]     Shirey, R., "Internet Security Glossary, Version 2",
                   RFC 4949, August 2007.

   [SMTP]          Klensin, J., "Simple Mail Transfer Protocol",
                   RFC 5321, October 2008.

   [SEC-GUIDE]     Rescorla, E. and B. Korver, "Guidelines for Writing
                   RFC Text on Security Considerations", BCP 72,
                   RFC 3552, July 2003.

Top      Up      ToC       Page 187 
   [TLS-EXT]       Eastlake 3rd, D., "Transport Layer Security (TLS)
                   Extensions: Extension Definitions", RFC 6066,
                   January 2011.

   [TLS-RESUME]    Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
                   "Transport Layer Security (TLS) Session Resumption
                   without Server-Side State", RFC 5077, January 2008.

   [URN-OID]       Mealling, M., "A URN Namespace of Object
                   Identifiers", RFC 3061, February 2001.

   [USINGTLS]      Newman, C., "Using TLS with IMAP, POP3 and ACAP",
                   RFC 2595, June 1999.

   [UUID]          Leach, P., Mealling, M., and R. Salz, "A Universally
                   Unique IDentifier (UUID) URN Namespace", RFC 4122,
                   July 2005.

   [XEP-0001]      Saint-Andre, P., "XMPP Extension Protocols", XSF
                   XEP 0001, March 2010.

   [XEP-0016]      Millard, P. and P. Saint-Andre, "Privacy Lists", XSF
                   XEP 0016, February 2007.

   [XEP-0045]      Saint-Andre, P., "Multi-User Chat", XSF XEP 0045,
                   July 2007.

   [XEP-0060]      Millard, P., Saint-Andre, P., and R. Meijer,
                   "Publish-Subscribe", XSF XEP 0060, July 2010.

   [XEP-0071]      Saint-Andre, P., "XHTML-IM", XSF XEP 0071,
                   September 2008.

   [XEP-0077]      Saint-Andre, P., "In-Band Registration", XSF
                   XEP 0077, September 2009.

   [XEP-0086]      Norris, R. and P. Saint-Andre, "Error Condition
                   Mappings", XSF XEP 0086, February 2004.

   [XEP-0100]      Saint-Andre, P. and D. Smith, "Gateway Interaction",
                   XSF XEP 0100, October 2005.

   [XEP-0114]      Saint-Andre, P., "Jabber Component Protocol", XSF
                   XEP 0114, March 2005.

   [XEP-0124]      Paterson, I., Smith, D., and P. Saint-Andre,
                   "Bidirectional-streams Over Synchronous HTTP (BOSH)",
                   XSF XEP 0124, July 2010.

Top      Up      ToC       Page 188 
   [XEP-0138]      Hildebrand, J. and P. Saint-Andre, "Stream
                   Compression", XSF XEP 0138, May 2009.

   [XEP-0156]      Hildebrand, J. and P. Saint-Andre, "Discovering
                   Alternative XMPP Connection Methods", XSF XEP 0156,
                   June 2007.

   [XEP-0160]      Saint-Andre, P., "Best Practices for Handling Offline
                   Messages", XSF XEP 0160, January 2006.

   [XEP-0174]      Saint-Andre, P., "Link-Local Messaging", XSF
                   XEP 0174, November 2008.

   [XEP-0175]      Saint-Andre, P., "Best Practices for Use of SASL
                   ANONYMOUS", XSF XEP 0175, September 2009.

   [XEP-0178]      Saint-Andre, P. and P. Millard, "Best Practices for
                   Use of SASL EXTERNAL with Certificates", XSF
                   XEP 0178, February 2007.

   [XEP-0191]      Saint-Andre, P., "Simple Communications Blocking",
                   XSF XEP 0191, February 2007.

   [XEP-0198]      Karneges, J., Hildebrand, J., Saint-Andre, P., Forno,
                   F., Cridland, D., and M. Wild, "Stream Management",
                   XSF XEP 0198, February 2011.

   [XEP-0199]      Saint-Andre, P., "XMPP Ping", XSF XEP 0199,
                   June 2009.

   [XEP-0205]      Saint-Andre, P., "Best Practices to Discourage Denial
                   of Service Attacks", XSF XEP 0205, January 2009.

   [XEP-0206]      Paterson, I. and P. Saint-Andre, "XMPP Over BOSH",
                   XSF XEP 0206, July 2010.

   [XEP-0220]      Miller, J., Saint-Andre, P., and P. Hancke, "Server
                   Dialback", XSF XEP 0220, March 2010.

   [XEP-0225]      Saint-Andre, P., "Component Connections", XSF
                   XEP 0225, October 2008.

   [XEP-0233]      Miller, M., Saint-Andre, P., and J. Hildebrand,
                   "Domain-Based Service Names in XMPP SASL
                   Negotiation", XSF XEP 0233, June 2010.

   [XEP-0288]      Hancke, P. and D. Cridland, "Bidirectional Server-to-
                   Server Connections", XSF XEP 0288, October 2010.

Top      Up      ToC       Page 189 
   [XML-FRAG]      Grosso, P. and D. Veillard, "XML Fragment
                   Interchange", World Wide Web Consortium CR CR-xml-
                   fragment-20010212, February 2001,
                   <http://www.w3.org/TR/2001/CR-xml-fragment-20010212>.

   [XML-REG]       Mealling, M., "The IETF XML Registry", BCP 81,
                   RFC 3688, January 2004.

   [XML-SCHEMA]    Thompson, H., Maloney, M., Mendelsohn, N., and D.
                   Beech, "XML Schema Part 1: Structures Second
                   Edition", World Wide Web Consortium
                   Recommendation REC-xmlschema-1-20041028,
                   October 2004,
                   <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.

   [XMPP-URI]      Saint-Andre, P., "Internationalized Resource
                   Identifiers (IRIs) and Uniform Resource Identifiers
                   (URIs) for the Extensible Messaging and Presence
                   Protocol (XMPP)", RFC 5122, February 2008.


Next RFC Part