Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6120

Extensible Messaging and Presence Protocol (XMPP): Core

Pages: 211
Proposed Standard
Errata
Obsoletes:  3920
Updated by:  75908553
Part 8 of 9 – Pages 172 to 189
First   Prev   Next

Top   ToC   RFC6120 - Page 172   prevText

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   ToC   RFC6120 - 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   ToC   RFC6120 - 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   ToC   RFC6120 - 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   ToC   RFC6120 - 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   ToC   RFC6120 - 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   ToC   RFC6120 - 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   ToC   RFC6120 - 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   ToC   RFC6120 - 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   ToC   RFC6120 - 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   ToC   RFC6120 - 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   ToC   RFC6120 - 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   ToC   RFC6120 - 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   ToC   RFC6120 - 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   ToC   RFC6120 - 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   ToC   RFC6120 - 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   ToC   RFC6120 - 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   ToC   RFC6120 - 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 page on part 9)

Next Section