dave at cridland.net
Tue Sep 30 07:04:00 CDT 2008
On Tue Sep 30 00:27:49 2008, Justin Karneges wrote:
> On Monday 29 September 2008 12:13:52 Dave Cridland wrote:
> > One reason is that we forbid the declaration of extension
> > (with a MUST NOT) at stream level. Now, as it happens, many
> > implementations cope with this fine, but in principle, they need
> > - you could chop stanzas out and not rewrap them in the original
> > <stream:stream/> and be legal, for example.
> XEP-198 elements are not stanzas, and don't need to exist outside
> the context
> of the <stream> they are part of.
Quite true - hence my use of extension namespaces specifically, as
opposed to all namespaces.
Non-extension namespaces - such as the TLS namespace we use - are
legally able to be declared at the stream level. It's a bit
pointless, perhaps, but it can be done that way according to the spec.
> If XMPP-Core forbids declaring namespace prefixes in <stream>, then
> IMO this
> restriction should be relaxed in the bis draft.
It doesn't - it forbids declaring extension namespaces - ie, those
used within stanzas.
> I understand that declaring a namespace prefix in <stream> and then
> using it
> in a stanza could result in some routability problems, but I think
> this is
> only an issue for naive implementations?
No, declaring an extension namespace in a stream would indeed cause
non-namespace-well-formed data to be emitted from a very naïve, but
legal, server. However, even in the release we're about to make,
where I fixed this issue, it still causes us to slow down, since we
have to fully parse and reconstruct every stanza, which is
> > I'm inclined to say, therefore, that either we redeclare the
> > namespace on each XEP-0198 element, or else we just say that
> > extends the jabber:server and jabber:client namespaces - the
> > is uglier in the specification, but much cleaner on the wire.
> FWIW, dialback also uses a stream-level prefix, which would violate
> existing rule you speak of.
No, because it's not an extension namespace, as per the definition.
XEP-0198 doesn't fall foul of this rule as-is, either, the problem is
that a naïve server (ie, one that's never heard of XEP-0198) cannot
know whether or not the extension namespace rule has been violated,
and from there, it cannot know if it should use a slower code path,
or else it might choose to risk generating bad namespace prefixes.
I've an idea, though. We could define "stream namespaces" to mean
those namespaces which are not extension namespaces as defined -
namespaces which are never used within stanzas, but only within
From there, it's easy to reserve a chunk of URN-space for them, so -
and I appreciate PSA will now wish to throttle me - we'd change the
namespace of XEP-0198 again, to something like:
And then servers can now that, since the namespace begins
"urn:xmpp:stream:", it's safe to ignore if they don't understand it.
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards