[Standards-JIG] Re: component protocol

Matthias Wimmer m at tthias.eu
Fri Nov 17 16:39:36 UTC 2006


Hi Ralph!

Ralph Meijer schrieb:
> This is of course an historical accident. I don't believe we can fix it
> now.

Why not? With current jabberd14 a client can already send his stanzas in
the 'jabber:server' namespace as well (it could even send them using the
'jabber:component:accept' namespace). So it is possible.

(jabberd14 changes all 'jabber:client' namespaces to 'jabber:server'
when they arrive at the c2s link. This is to ensure that I can use the
same xpath expressions inside the server doesn't matter where the stanza
comes from. - And when serializing the XML tree, I convert the namespace
'jabber:server' namespace back to 'jabber:client' so that the client
gets what it expects.)


> Juggling namespaces between jabber:client and jabber:server is
> indeed delicate, you MUST NOT not change the namespace inside your
> attach:x, and if implementations do that, they are faulty. We might want
> to test these things specifically at the next interop event.

I'd object ... I'd say they are faulty if they don't change these
namespaces.

Eitherway ... doesn't matter how you define it, you get into problems.
As I described last year. Please have a look at the archives.

> That said, assuming an implementation can juggle namespaces anyway,
> having different ones for different purposes doesn't hurt anymore.

It does as I wrote last year. Having it done the wrong or a hacky way in
the past does not mean that we have to do it the same way all the time
in the future. When we're defining protocols we should always try to
make it in a clean way.

The other way round: Changing the namespace for a component connection
does not hurd anyone, especially if we're updating the component
connection streams anyway. - That's why I propose to stop using an own
namespace for this stream.

For the server it's one link less it has to mangle namespaces. - For the
component it's just another namespace to use. (Changing this in the code
is typically just changing the content of one constant ... while
updating the authentication requires real changes to the code.)


Tot kijk
    Matthias

-- 
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/



More information about the Standards mailing list