The following is a summary of potentially material changes made between draft-ietf-xmpp-core-22 and draft-ietf-xmpp-core-23 (minor editorial fixes are not mentioned in this summary). 2.3 Client In consultation with WG Chairs and in order to address concerns voiced by a WG member, modified the text as follows (text about binding to TCP was moved to a new section 4.2 as described below).... 22: Most clients connect directly to a server over a [TCP] connection and use XMPP to take full advantage of the functionality provided by a server and any associated services. Although there is no necessary coupling of an XML stream to a TCP connection (e.g., a client could connect via HTTP [HTTP] polling or some other mechanism), this specification defines a binding of XMPP to TCP only. Multiple resources (e.g., devices or locations) MAY connect simultaneously to a server on behalf of each authorized client, with each resource differentiated by the resource identifier of an XMPP address (e.g., vs. ) as defined under Addressing Scheme (Section 3). The RECOMMENDED port for connections between a client and a server is 5222, as registered with the IANA (see Port Numbers (Section 15.9)). 23: Most clients connect directly to a server over a [TCP] connection and use XMPP to take full advantage of the functionality provided by a server and any associated services. Multiple resources (e.g., devices or locations) MAY connect simultaneously to a server on behalf of each authorized client, with each resource differentiated by the resource identifier of an XMPP address (e.g., vs. ) as defined under Addressing Scheme (Section 3). The RECOMMENDED port for connections between a client and a server is 5222, as registered with the IANA (see Port Numbers (Section 15.9)). 2.4 Gateway Added references to RFCs for SMTP and IRC, and to URL for SIMPLE WG. 2.5 Network Changed examples to conform to RFC 2606. 4. XML Streams 4.1 Overview In consultation with WG Chairs and in order to address concerns voiced by a WG member, modified the definition of XML stream as follows.... 22: Definition of XML Stream: An XML stream is a container for the exchange of XML elements between any two entities over a network. An XML stream is negotiated from an initiating entity (usually a client or server) to a receiving entity (usually a server), normally over a [TCP] connection, and corresponds to the initiating entity's "session" with the receiving entity. The start of the XML stream is denoted unambiguously by an opening XML tag (with appropriate attributes and namespace declarations), while the end of the XML stream is denoted unambiguously by a closing XML tag. An XML stream is unidirectional; in order to enable bidirectional information exchange, the initiating entity and receiving entity MUST negotiate one stream in each direction (the "initial stream" and the "response stream"), normally over the same TCP connection. 23: Definition of XML Stream: An XML stream is a container for the exchange of XML elements between any two entities over a network. The start of an XML stream is denoted unambiguously by an opening XML tag (with appropriate attributes and namespace declarations), while the end of the XML stream is denoted unambiguously by a closing XML tag. During the life of the stream, the entity that initiated it can send an unbounded number of XML elements over the stream, either elements used to negotiate the stream (e.g., to negotiate use of TLS (Section 5) or use of SASL (Section 6)) or XML stanzas (as defined herein, , , or elements qualified by the default namespace). The "initial stream" is negotiated from the initiating entity (usually a client or server) to the receiving entity (usually a server), and can be seen as corresponding to the initiating entity's "session" with the receiving entity. The initial stream enables unidirectional communication from the initiating entity to the receiving entity; in order to enable information exchange from the receiving entity to the initiating entity, the receiving entity MUST negotiate a stream in the opposite direction (the "response stream"). 4.2 Binding to TCP In consultation with WG Chairs and in order to address concerns voiced by a WG member, moved content previous contained in Section 2.4 to a new section 4.2 devoted to describing the binding of XMPP to TCP, including clarification that client-to-server connections MUST be bidirectional whereas server-to-server connections MUST be unidirectional; the text is as follows: 23: Although there is no necessary coupling of an XML stream to a [TCP] connection (e.g., two entities could connect to each other via another mechanism such as polling over [HTTP]), this specification defines a binding of XMPP to TCP only. In the context of client-to-server communications, a server MUST allow a client to share a single TCP connection for XML stanzas sent from client to server and from server to client. In the context of server-to-server communications, a server MUST use one TCP connection for XML stanzas sent from the server to the peer and another TCP connection (initiated by the peer) for stanzas from the peer to the server, for a total of two TCP connections. 4.3 Stream Security In consultation with WG Chairs and in order to address concerns voiced by a WG member, clarified directionality of streams (see above) and copied text regarding appropriate error messages from later sections to the Stream Security section, as follows.... 22: When negotiating XML streams in XMPP 1.0, TLS SHOULD be used as defined under Use of TLS (Section 5) and SASL MUST be used as defined under Use of SASL (Section 6). If the initiating entity attempts to send an XML Stanza (Section 9) before the stream has been authenticated, the receiving entity SHOULD return a stream error to the initiating entity and then terminate both the XML stream and the underlying TCP connection. 23: When negotiating XML streams in XMPP 1.0, TLS SHOULD be used as defined under Use of TLS (Section 5) and SASL MUST be used as defined under Use of SASL (Section 6). The "initial stream" (i.e., the stream from the initiating entity to the receiving entity) and the "response stream" (i.e., the stream from the receiving entity to the initiating entity) MUST be secured separately, although security in both directions MAY be established via mechanisms that provide mutual authentication. An entity SHOULD NOT attempt to send XML Stanzas (Section 9) over the stream before the stream has been authenticated, but if it does then the other entity MUST NOT accept such stanzas and SHOULD return a stream error and then terminate both the XML stream and the underlying TCP connection; note well that this applies to XML stanzas only (i.e., , , and elements scoped by the default namespace) and not to XML elements used for stream negotiation (e.g., elements used to negotiate use of TLS (Section 5) or Use of SASL (Section 6)). Note: To improve the flow of the text, moved Stream Security text from Section 4.5 to Section 4.3. 4.4 Stream Attributes Changed "SHOULD be no" to "SHOULD NOT be" in several places. 4.4.1 Version Support Changed "node" to the more general term "entity". 4.7.3 Defined Conditions Changed "CDATA" to the more accurate term "XML character data" here and throughout the text. 4.8 Simplified Stream Examples Added "version='1.0'" attribute to conform to recommendations. 6.3 SASL Definition Added the word "non-default" since the authorization identity is provided for clients only if the user desires to authorize as someone other than himself. Thus: 23: use of the authorization identity: The authorization identity may be used by xmpp to denote the non-default of a client or the sending of a server. 6.4 SASL Errors Corrected "initial challenge data" to "initial response data". 6.6. Server-to-Server Example Removed 'username="example.com"' from challenge since receiving entity would not provide this in the challenge. Also changed the username provided by initiating entity from "example.com" to "example.org", since in this example it is the receiving entity that is "example.com" and the example could have caused confusion. 7. Resource Binding At very end of section, specified an error condition related to a client attempt to send data before completing resource binding (this is consistent with Section 4.3 on Stream Security but was not previously specified in this context). 23: If, before completing the resource binding step, the client attempts to send an XML stanza other than an IQ stanza with a child qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' namespace, the server MUST NOT process the stanza and SHOULD return a stanza error to the client. 8. Server Dialback 8.1 Overview In consultation with WG Chairs and in order to address concerns voiced by a WG member, echoed content of new Section 4.2 by specifying here (in new paragraph) that server-to-server connections MUST be unidirectional; the text is as follows: Server dialback is uni-directional, and results in (weak) verification of identities for one stream in one direction. Because server dialback is not an authentication mechanism, mutual authentication is not possible via dialback. Therefore server dialback MUST be completed in each direction in order to enable bi-directional communications between two domains. 8.3 Protocol In consultation with WG Chairs and in order to address concerns voiced by a WG member, removed reference to TCP connection in step 5. 22: 5. Receiving Server establishes a TCP connection back to the domain name asserted by Originating Server, as a result of which it connects to Authoritative Server. (Note: As an optimization, an implementation MAY reuse an existing trusted connection here rather than opening a new TCP connection.) 23: 5. Receiving Server establishes a TCP connection back to the domain name asserted by Originating Server, as a result of which it connects to Authoritative Server. (Note: As an optimization, an implementation MAY reuse an existing connection here.) Per mailing list discussion, changed "or any validated domain" to "or any validated domain thereof, such as a validated subdomain of Receiving Server's hostname or another validated domain hosted by Receiving Server" in steps 8 and 9. In consultation with WG Chairs and in order to address concerns voiced by a WG member, changed "all data stanzas" to "all XML stanzas" step 10 (since the term "data stanza" is not used elsewhere in the document and could be construed as applying to TLS, SASL, and dialback negotiation elements, which is false). 22: Note: At this point the connection has either been validated via a type='valid', or reported as invalid. If the connection is invalid, then Receiving Server MUST terminate both the XML stream and the underlying TCP connection. If the connection is validated, data can be sent by Originating Server and read by Receiving Server; before that, all data stanzas sent to Receiving Server SHOULD be silently dropped. 23: Note: At this point the connection has either been validated via a type='valid', or reported as invalid. If the connection is invalid, then Receiving Server MUST terminate both the XML stream and the underlying TCP connection. If the connection is validated, data can be sent by Originating Server and read by Receiving Server; before that, all XML stanzas sent to Receiving Server SHOULD be silently dropped. In consultation with WG Chairs and in order to address concerns voiced by a WG member, clarified here as well as in previous text that the stream negotiated via dialback is unidirectional: 23: The result of the foregoing is that Receiving Server has verified the identity of Originating Server, so that Originating Server can send, and Receiving Server can accept, XML stanzas over the "initial stream" (i.e., the stream from Originating Server to Receiving Server). In order to verify the identities of the entities using the "response stream" (i.e., the stream from Receiving Server to Originating Server), dialback MUST be completed in the opposite direction as well. As discussed on the XMPP WG mailing list, added note about accepting subsequent packets over a stream negotiated via dialback: 23: After successful dialback negotiation, Receiving Server SHOULD accept subsequent packets (e.g., validation requests sent to a subdomain or other hostname serviced by Receiving Server) from the Originating Server over the existing validated connection; this enables "piggybacking" of the original validated connection in one direction. 9.1.2 from Specified that the 'from' address stamped by the server must be either or ; the former was left out of draft-ietf-xmpp-core-22 but is needed by draft-ietf-xmpp-im. 22: 2. add a 'from' address to the stanza whose value is the full JID () determined by the server for the connected resource that generated the stanza (see Determination of Addresses (Section 3.5)) 23: 2. add a 'from' address to the stanza whose value is the bare JID () or the full JID () determined by the server for the connected resource that generated the stanza (see Determination of Addresses (Section 3.5)) As noted for Section 8.3 and per mailing list discussion, changed "or any validated domain" to "or any validated domain thereof, such as a validated subdomain of Receiving Server's hostname or another validated domain hosted by Receiving Server". 10. Server Rules for Handling XML Stanzas Noted that these rules apply to a mere XMPP server but may be further specified or overridden by an application server; this is necessary since application servers may have more particular requirements that do not apply to mere XMPP server applications (specifically, some of the rules in draft-ietf-xmpp-im further specify or override the mere XMPP rules). 22: ... The following rules apply: 23: ... The following rules apply to a "mere" XMPP server, but MAY be further specified or overridden by a particular class of application servers (e.g., an instant messaging and presence server as defined in [XMPP-IM]): 10.5 Node in Same Domain Corrected rule 3 per developer feedback, since the requirement that the stanza MUST be delivered is not consistent with the rules for resources with negative priorities and the privacy list rules that are specified in draft-ietf-xmpp-im. 22: 3. If the JID is of the form and there exists at least one connected resource for the node, the recipient's server MUST deliver the stanza to at least one of the connected resources, according to application-specific rules (a set of delivery rules for instant messaging and presence applications is defined in [XMPP-IM]). 23: 3. If the JID is of the form and there exists at least one connected resource for the node, the recipient's server SHOULD deliver the stanza to at least one of the connected resources, according to application-specific rules (a set of delivery rules for instant messaging and presence applications is defined in [XMPP-IM]). 15.9 Port Numbers Updated this paragraph to reflect changes made by the IANA. 22: The IANA currently registers "jabber-client" and "jabber-server" as keywords for [TCP] ports 5222 and 5269 respectively. The IANA shall change these registrations to "xmpp-client" and "xmpp-server" respectively. 23: The IANA registers "xmpp-client" and "xmpp-server" as keywords for [TCP] ports 5222 and 5269 respectively. Appendix C. XML Schemas Added imports and error groups, fixed several errors.