[xmpp] Fwd: Use of namespace in RFC 3920

[Jehan Pagès <jehan.marmottard at gmail.com>]

Oups sorry, this message went only to Dave, not the whole list. :-)

Jehan

---------- Forwarded message ----------
From: Jehan Pagès <jehan.marmottard at gmail.com>
Date: 2009/9/24
Subject: Re: [xmpp] Use of namespace in RFC 3920
To: Dave Cridland <dave at cridland.net>


Hi,

On Thu, Sep 24, 2009 at 2:11 AM, Dave Cridland <dave at cridland.net> wrote:

 So you MUST absolutely have a
default namespace in the root <stream>, and this one MUST be the one
for the stanza ("jabber:client" or "jabber:server", most typically)

Right, this allows us to detirmine whether it's a client, server, or component. We actually do this - so if you want to, you can point clients, components, and servers alike at a single port and it'll all just work.

If we didn't do this, we'd need some additional signalling to distinguish, or else we'd have to use distinct TCP ports for all three, which seems suboptimal, especially when we're already using this quite happily.

I don't really see the problem. This can be seen also on the received stanza, which is the same thing. I don't tell we stop using namespace, but that telling they MUST (or SHOULD) be done on such specific way does not seem right to me. What matters, in my logic, is just the finale qualified name of stanza, which means the tuple (namespace, local name). So you can still redirect clients, components and servers to the same port. And you will still distinguish them with the finale qualified name (however it has been qualified: default ns, prefix, etc.).

 +
you MUST have a prefix declared, for the stream related first level
elements,

Well if you've already got a default namespace, it stands to reason you can't have the stream top-level elements in it.

No, I don't say that it is not a logical way to do. I just say that there are others and that the RFC should not force to do a specific way. For instance, you could imagine that you set the stream ns as the default ns and declare a prefix for "jabber:client" (or "jabber:server", or whatever) and use this prefix in the stanzas, instead of doing the opposite. I just say it should not matter, as at the end, what matters is the qualified name.
 

 and this prefix MUST be "stream".

I don't care about this, and FWIW, we do not rely on it. Also, it's a SHOULD not a MUST, and a MAY rely on. The latter, I think, needs changing - this should be SHOULD (because of legacy systems) and MUST NOT rely on.

Ok right this is a "SHOULD", not a "MUST". But "SHOULD" is still a strong "recommandation". This is for me different than saying that legacy systems were doing a check on this, so it is a good idea tocontinue to use the name "stream"

 

So for instance, the current RFC asks me to reject and consider this
stream start as an error, though it is perfectly valid XML and
conforming to XMPP:

<toto:stream
         from='juliet at im.example.com'
         to='im.example.com'
         version='1.0'
         xml:lang='en'
         xmlns='jabber:client'
         xmlns:toto='http://etherx.jabber.org/streams'>

No, the RFC says you MAY reject it. Section 11.2.1 says so.

Yes. We MAY, you are right. I am not forced. Still, the RFC tells me it is perfectly good (yet not mandatory, I agree) to refuse a perfectly well formed (and valid) XML, which conforms to the XMPP DTD, namespace choices, and so on. I personally don't think this is really nice.

And many other examples: for instance, if I prefer to use a declared
namespace for "jabber:client" instead of a default namespace, why
couldn't I?

See above. Various other things, like XEP-0220, get triggered by the default namespace choice of the initiator of the stream.

Yes. And I agree, but my answer is the same: I don't see the difference of getting namespace on the stanzas themselves.
 

For historical reasons, some older implementations may accept only a
stream element qualification through a prefix named "stream" (and not
for instance through a default namespace, nor a prefix named other
than "stream"), declared in the initial <stream/> element. For
backwards compatibility, it may therefore be a good idea, though not
mandatory, to declare a prefix named "stream" and with value
"http://etherx.jabber.org/streams" in the <stream/> header. However an
implementation MUST NOT send any error, hence reject a stream doing
differently, as long as the qualified names for the <stream/>,
<features/> and <error/> element are correct with this alternative
method.

"it may therefore be a good idea, though not mandatory" = SHOULD.

Yes. I agree globally. But I still think this "SHOULD" is too strong, so not exactly the same. Note also that what I added is that I removed the possibility of the error. That's for me the main point. So yes we can keep it a "SHOULD", but it must not prevent from doing another way, perfectly XML-compliant.
 
Bye.

Jehan