Hi, thanks for your answer.
Here's our use case: We use several XMPP servers for internal testing. Some of them are available from our company's intranet under an "internal" IP Address only, e.g. 172.x.x.x. The same XMPP server might also be available via internet under an external IP, e.g. 180.x.x.x as well as under a real domain name (e.g. xmpp.domain.com). So, for external internet access to the server, one could either connect to "http://180.x.x.x/http-bind/"; or "http://xmpp.domain.com/http-bind/";. From intranet the server can only be reached with ("http://172.x.x.x/http-bind/";), since "xmpp.domain.com" cannot be resolved from within the intranet, (maybe somehow it can, but in our case it didn't work, but I am no network expert). So basically we told our users: If you are at home (internet), connect to "180.x.x.x". If you are in the company network, connect to "172.x.x.x". The problem we then had, when users wanted to connect with BOSH, is that our BOSH implementation (which is the one from Openfire) did not return a "from" attribute, which also means that during SASL DIGEST-MD5 authentication the realm could not be set (which is expected to be the server's domain name). Consequently this authentication failed. The only solution was to either hardcode the domain name in our client or to make it configurable on the client's UI, which means there's another field for the user to fillout besides the hostname/IP, which might be confusing. If the BOSH response would include a "from" attribute, we would knew that we are connected to "xmpp.domain.com" even if we used the internal URL "http://172.x.x.x/http-bind/"; to connect from internal company network. (For normal XMPP on 5222 it works in this case, since the 'from' attribute is included in the stream header response). I don't know if this use case is "valid" or if you expect to know the identity (as you said), i.e. the domain name before connecting. But I guess this use case is quite similar to http://xmpp.org/rfcs/rfc6120.html#tcp-resolution-srvnot "(say, to "hardcode" an association from an origin domain of example.net to a configured FQDN of apps.example.com)" in which case you would connect to "http://apps.example.com/http-bind/"; but would never know that the origin domain name is actually "example.net". Christian Gesendet: Mittwoch, 29. Januar 2014 um 12:10 Uhr Von: "Winfried Tilanus" <winfr...@tilanus.com> An: standards@xmpp.org Betreff: Re: [Standards] BOSH patches, hopefully the last before final -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 29-01-14 08:14, Christian Schudt wrote: Hi Christian, On a general notice: interop issues are a good reason to take a close look at the specs: specs are meant to facilitate interoperability, so interop issues may indicate there is a flaw in the specs. At the same time, specs do have a life-cycle. The BOSH specs are widely implemented and used in very diverse use cases. Changes to BOSH have the potential of breaking lots of deployments, so changes have to be handled with a lot of care. That is also the reason why we are pushing the BOSH specs to the 'final' status: to formalize the status they already have in practice. Though we certainly would have made different choices, if we were to design BOSH from scratch right now. For my own understanding: your problem is with the client you have been writing recently? If so, can you tell a little bit more about the use case scenario's it is meant for and how it works? That background information helps me a lot. > I've had trouble connecting (and authenticating) through > Openfire's BOSH implementation, when I don't know Openfire's > domain, but only its IP address or hostname (which might be > different to the domain name). > > It turned out, that Openfire did not send a "from" attribute in > its initial BOSH session response, leaving me unknown about the > domain name. > > However the domain name is required by (at least) DIGEST-MD5 > authentication. > > Eventually I could only connect, if I know the domain name before > connecting. I am a bit surprised your client is trying to authenticate without knowing the identity it uses for authentication. The only two scenario's I can imagine where that makes sense, is while using SASL-EXTERNAL or SASL-ANONYMOUS. The first case is covered by patch 4/4, in the second case there is a mechanism for the server to inform the client about its identity *after* authentication, see XEP-0175. But of course, I may be missing something here (quite common). So if you, or anybody else, knows a case where this makes sense, please let me know! > Therefore I think the "from" attribute must be included. It should > be: "it MUST forward the identity to the client by including a > 'from' attribute in a response" (instead of MAY). The 'to' and 'from' attributes are quite a sticky problem for BOSH, for several reasons. In the past there was an attempt to cut the BOSH specs in two: a general comet-like part (XEP-0124) and a XMPP specific part (XEP-0206). The general part never really took of on its own, but in a formal sense the attributes in XEP-0124 have nothing to do with the attributes in XEP-0206 or RFC6120. That is one of the reasons the 'from' in XEP-0124 is only loosely coupled to the other XMPP specs. Some implementations use this 'gap' to give these attributes in BOSH an own meaning. Changing the specs here would break those. An other issue is the question who has the authority to set the domain name and how to handle conflicts here. This has been discussed quite extensively in the past. The answer is that it differs from deployment to deployment what works. The only sensible way of putting it in the specs we could come up with, was keeping it open. > Another reason: The core spec says: "For response stream headers > in both client-to-server and server-to-server communication, the > receiving entity MUST include the 'from' attribute" > (http://xmpp.org/rfcs/rfc6120.html#streams-attr-from) Please also pay attention to the interoperability note at the bottom of that section: though the server MUST send a "from", a client SHOULD be liberal in accepting a stream without it. Exactly this was also one of the reasons not to make a "from" obligatory in XEP-0124: to not break implementations that are relying on RFC3920 based servers. The problems you (and several others, you are not the first) ran into with the 'from' attribute, certainly indicates there is some issue there. But I hope you can understand the circumstances that lead to this decision. I believe it is the best option, given the circumstances. But if anybody can come up with a better solution that won't break current implementations: I would strongly favour it! Winfried -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCgAGBQJS6OGkAAoJEHZ7UH0X6LdcWZYP/3HWr1yvmld7a9NR5/dt8qFa mWXhsIid/X4lyNoq0WMGub9sHqZLotyfU0jY9NV39KHBxioLV1phatQMIxK+1KGJ iIdxB03XML1lHmCzeqHQLDB0relKxnwi+WVh3PM8JdDJ//icxrf/sv/3LJOIY6m9 I54buzI1gk2oZGcXGG97MLjT+dGk97eeYN6E+ZZLXyXfgcPPeW2G0pHLaRuUPYmb qzFu9OYBtVZo+gbi3wh9i5O6g6nTBxiDOW7H8rAxjmeBGdfcLGeE1WqdWXhhWRRw CqBVbcZTO4xwJ7mwhHyDh/s2XaUANWQ8D82Dn9v3hx+Z4OkQOUwJ1vfjvaTsE7jM P56tFhTvrufIhVFPMs/ECXkXm3widVfGBqtPZEQsrtDZoV1SYIlvEnDDY1HBSs5n n33K9LJRJqB/0gzEVxOUZ2OfcE+fG0i455imHnRkfh5ezEgZuWF8hBIPP2l0fhVn 3WpSvv3zuvVi4sQUXSOv80PFWWDLp63kSFYddGIYmdWL8fA4msQnLmuesWf0S6YR wQD8PFZGc7PPlKvBfMZwa2tZfmof8UDbVdO4YgjF8S2oQYxovrqCf6NcpKhGYubx rboNEVde9bcOMXV8WTiDFMiTWzhXZ0URFzQerRLdTCkpi08F/eJkZKnowP1BXHtc +DTYQ4Lgfar1uhIo0Tev =uPdM -----END PGP SIGNATURE-----
