[Standards] XEP-0225 Component Connections - namespaces again
stpeter at stpeter.im
Sat Jun 5 03:28:29 UTC 2010
On 5/1/10 10:48 AM, Artur Hefczyc wrote:
> I have already mentioned about the issue here in another thread but
> I think it is best to discuss it separately.
> The XEP uses 'jabber:client' namespace which is great as it avoid
> xmlns problems I have recently encountered with s2s connections
> and XEP-0114 connections.
> I have implemented the XEP in the Tigase server and it supports
> both multiple connections on single port, domains bindings, etc...
> There is one significant problem though.
> The XEP uses the same exact elements and namespace for protocol
> handshaking (authentication, tls, etc....) as the client to server connection.
> This makes it actually impossible to put c2s connection managers behind
> XEP-0225 link as then there is no way to reliably detect whether the
> SASL or starttls comes from the client or from the component on the
> other side of the link.
> Of course we can guess (the link is already authenticated to this SASL
> request must come from the client) but this is not a good way to do it.
> My suggestion is to modify the XEP to simply say something like this:
> All packets with top-level element within namespace 'urn:xmpp:component:0'
> are the XEP-0225 handshaking stanzas, all packets within 'jabber:client'
> are the client stanzas which should be forwarded to/from external component.
That seems reasonable.
I'm still looking for a co-author on XEP-0225, so feel free to volunteer
and we can get these changes made more quickly than if we depend on me. :)
Another option is to submit a ticket:
I think we have a few other open issues on XEP-0225, right? If we put
these issues in the tracker it will be easier to fix them.
> Ideally this approach could be adopted for all other connections
> (s2s, xep-0114, etc....). I know that's not going to happen any time soon though.
I don't see why we would need this for s2s, and XEP-0114 will perhaps
eventually be deprecated by XEP-0225. Eventually. :)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards