[Standards-JIG] Re: component protocol
m at tthias.eu
Fri Nov 17 15:51:08 UTC 2006
Ralph Meijer schrieb:
> About the namespace, why is that a problem exactly? I suppose that if
> your development platform is able to switch between 'jabber:client' and
> 'jabber:server', a third namespace wouldn't be an issue. I haven't had
> any difficulty with it in my code.
There are the same problems with jabber:client/jabber:server, that is
true. I described them about a year ago on this list, when I made
jabberd14 fully namespace compliant.
Today it seems, that most Jabber software still does not really work
with namespace support, but handles the xmlns attributes as normal
attributes. As long as you do it that way, you will really not get any
problems. But if you think the XML way and work with real namespace
support you get into problems with the shifting of them.
One problem I explained already last year:
If a client sents the following stanza to a contact on another host
(therefore that stanza passes a s2s link):
<message from='alice at example.com' to='bob at example.org'
<body>Hey, look this stanza I received on my server's s2s
<message xmlns='jabber:server' from='bob at example.org'
to='alice at example.com'/>
With real namespace support on example.org's server, in the stanza that
bob at example.org receives the inner message element in namespace
jabber:server has probably changed to a message element in the
jabber:client server. This is because the destination server cannot know
if the originating server just has changed the namespace to
'jabber:server' because it forwarded the message to a s2s link or if the
client sent it in this namespace.
This is only one problem I have with it. But probably the easiest to see
for most of the users here that never implemented a server.
If we consider the both namespace to be different, they have to be
delivered as they have been sent. If we consider both namespaces to
declare the same, I don't understand why we need two IRIs to declare the
> The advantage of a separate namespace is that it clearly marks that
> stanzas are treated differently.
What IS treated differently, that requires two different namespaces? The
only difference is if the from and to attributes are optinal or required.
> Making 'components' do s2s is not a protocol issue, but an
> implementation issue.
As I said, I don't propose s2s for components. I'd only like to see the
stream syntax for both streams unified.
(Well I'd like to see client connections to switch to the same namespace
as s2s connections as well. But doing this change for component links
might be a good first step for the unification.)
Matthias Wimmer Fon +49-700 77 00 77 70
Züricher Str. 243 Fax +49-89 95 89 91 56
81476 München http://ma.tthias.eu/
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4263 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards