Sorry, still catching up on email here. Dave Cridland wrote: > 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.
So anything starting with urn:xmpp:stream: would be handled in this special way? I don't know whether I like that, since there are exceptions for older namespaces etc. Peter -- Peter Saint-Andre https://stpeter.im/
