RFC 6120
Extensible Messaging and Presence Protocol (XMPP): Core
Pages: 211
Proposed Standard
→ Errata
Obsoletes: 3920
Updated by: 7590 8553
Proposed Standard
→ Errata
Obsoletes: 3920
Updated by: 7590 8553
Part 8 of 9 – Pages 172 to 189
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
[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.
[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.
[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.
[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.
[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.
[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.
[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.
[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)