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
namespaces
> (with a MUST NOT) at stream level. Now, as it happens, many
> implementations cope with this fine, but in principle, they need
not
> - 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
considerably slower.
> I'm inclined to say, therefore, that either we redeclare the
> namespace on each XEP-0198 element, or else we just say that
XEP-0198
> extends the jabber:server and jabber:client namespaces - the
latter
> is uglier in the specification, but much cleaner on the wire.
FWIW, dialback also uses a stream-level prefix, which would violate
the
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
stream elements.
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:
urn:xmpp:stream:sm:0
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.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
