Matthias Wimmer wrote:
Peter Saint-Andre schrieb:I received some extensive feedback on server dialback from someone offlist, and the commenter complained long and loud about the many ambiguities involved in the so-called "piggybacking" method described here:http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-02.html#dialback-reuse The suggestion is to remove piggybacking. I would like feedback from people on this list about whether that is desirable.I just want to note that if piggybacking is removed we break compatibility with existing implementations and we therefore have to change the XMPP version to 2.0.
1. Dialback itself is not mandatory to implement, so a change to dialback would not affect the XMPP versioning.
2. Removing piggybacking from the specification would not mean that an implementation MUST NOT do piggybacking, only that such behavior is not specified.
I am not sure if removing piggybacking is that important, that we want to do this incompatible change.
Agreed. That's why we're having this discussion. :)Piggybacking was woefully underspecified in RFC 3920. The only text I can find is this:
******After successful dialback negotiation, the Receiving Server SHOULD accept subsequent <db:result/> packets (e.g., validation requests sent to a subdomain or other hostname serviced by the Receiving Server) from the Originating Server over the existing validated connection; this enables "piggybacking" of the original validated connection in one direction.
****** We have tried to specify it more completely in rfc3920bis: ****** C.4. Reuse of Negotiated ConnectionsAfter the Receiving Server has validated the connection from the Originating Server, the Originating Server may wish to reuse that connection for validation of additional domains. One common motivation for such reuse is the existence of additional services associated with the Originating Server but hosted at subdomains of the Originating Server (the use of subdomains helps to ensure proper routing of XML stanzas to the hosted services). For example, the "example.org" XMPP server may host a groupchat service at "chat.example.org". In order to accept XML stanzas from rooms at "chat.example.org" intended for addresses at "xmpp.example.com", the "xmpp.example.com" will need to validate the "chat.example.org" domain (just as it already did for the "example.org" domain). Thus the "example.org" server would now initiate a dialback negotiation with "xmpp.example.com" but specify the Originating Server as "chat.example.org". Several optimizations are possible:
* Because the "example.org" server already has a validated connection open to the Receiving Server ("xmpp.example.com"), it MAY send a <db:result/> element with the key to be validated for the new Originating Server ("chat.example.org") over the XML stream that has already been negotiated, rather than opening a new TCP connection and XML stream. The Receiving Server SHOULD accept this element rather than returning an error to the Originating Server over the previously negotiated connection. * If the Receiving Server ("xmpp.example.com") has also negotiated a valid connection in the other direction (from the Receiving Server to the Originating Server), then that connection is ipso facto a connection to the Authoritative Server for the first negotiation. Therefore the receiving server can re-use that connection for exchange of the <db:verify/> elements associated with the second negotiation. The Authoritative Server SHOULD accept this element rather than returning an error to the Receiving Server over the previously negotiated connection.
These optimizations effectively enable "piggybacking" of the previously negotiated connections.
****** The error flows are not well specified here. In particular:1. What does the Receiving Server return to the Originating Server if it does not accept <db:result/> over the validated connection?
2. What does the Authoritative Server return to the Receiving Server if it does not accept <db:verify/> over the validated connection?
Presumably, if the Receiving Server in #1 or the Authoritative Server in #2 does not want to do piggybacking, they would close the streams in question. But it is still possible for the Originating Server in #1 or the Receiving Server in #2 to send a <db:result/> or <db:verify/> before the stream is closed, so we need to specify how these are handled. A <not-authorized/> or <policy-violation/> stream error?
Peter -- Peter Saint-Andre XMPP Standards Foundation http://www.xmpp.org/xsf/people/stpeter.shtml
smime.p7s
Description: S/MIME Cryptographic Signature
