I'm a bit torn about this, comments inline.
On Wed, 2007-08-08 at 15:11 -0700, Justin Karneges wrote:
> On Wednesday 08 August 2007 1:44 pm, Peter Saint-Andre wrote:
> > XMPP Extensions Editor wrote:
> > > Version 0.1 of XEP-0225 (Component Connections) has been released.
> > >
> > > Abstract: This document specifies a standards-track XMPP protocol
> > > extension that enables server components to connect to XMPP servers.
> >
> > One of the items up for discussion is the default namespace for
> > component connections. At the XMPP DevCon we thought that it would be
> > good to use 'jabber:client', but I know that both Matthias Wimmer and
> > Ralph Meijer have some arguments for 'jabber:server'. So perhaps we
> > could have a debate about that. :)
>
> For namespace-aware implementations, these multiple namespaces are a real
> pain. <body xmlns='jabber:client'> and <body xmlns='jabber:server'> have
> identical meaning: a body of a message. Yet, namespace-aware implementations
> will consider these to be two distinct elements. This affects the creating
> and parsing of all RFC 3920 and 3921 XML data. You need to write code that
> understands both namespaces and can output under either namespace (depending
> on whether a stanza is going out on c2s or s2s).
>
> In jabberd2, I believe all XML is internally handled in the jabber:client
> namespace. I did the same thing in Ambrosia. When a stanza arrives over
> s2s, I iterate over the DOM and change all namespace instances
> of 'jabber:server' to 'jabber:client' (note here that I'm not talking about
> xmlns attributes, but rather the namespace property of each DOM element).
> This allows me to reuse all of my existing stanza parsing and generation code
> based on a single namespace ('jabber:client').
Since I am interesting how others do this, I'll first describe how I go
about this.
My namespace handing code has None besides the typical empty and
non-empty namespace names. None means inheriting from whatever is the
default namespace of the parent (or closest ancestor that sets this. So,
I convert the namespace to None on incoming messages and to the stream
namespace on outgoing messages.
This keeps namespace changes at the edges. Not having a defined default
namespace the elements in transit between parts of the server make sense
to me, as they don't actually belong to any of the currently defined
stream namespaces.
That said, all server implementations need to do this namespace juggling
anyway, so I don't see how it is an extra burden to do this for another
namespace, too.
> Additionally, I think indicating support for a feature or connection type
> simply through a namespace declaration is weird. A namespace declaration
> indicates what namespace child elements should be assigned to, when you
> actually have child elements. By itself it doesn't have much meaning.
> Namespace declarations don't show up in DOM either (they do show up in SAX
> though, which is how I handle them). I personally think it was a mistake to
> use namespace declarations to indicate c2s vs s2s, or to indicate dialback
> support, and so I vote not repeating this mistake. This means
> no 'jabber:component' or such. The choice should be between 'jabber:client'
> and 'jabber:server' for the namespace. Use a real attribute or element to
> indicate component support.
I can sympathize with the reasoning, actually. This is a clear case of
hist(e|o)ric reasons. I have to agree with Rachel and Peter here,
though, that jabber:server and jabber:client both don't make much sense
for component streams. I think we have a couple of choices here:
1. Use a separate namespace for the component streams.
2. Choose from jabber:server and jabber:client
3. Iff we do a new version of XMPP (i.e. >1.0), we could choose one
namespace for all connections.
I strongly prefer 1 over 2, but if we do 2, I'd choose jabber:server.
Option 3 is something that could be considered, but if you want to be
interoperable with client and server implementations that implement
versions <=1.0, you still have to do some juggling at the edges. However
you would change the namespaces to and from that new namespace and use
the new namespace internally.
--
Groetjes,
ralphm
