Hi,
On Fri, Sep 25, 2009 at 12:03 AM, Dave Cridland <dave at cridland.net> wrote:
>
> <foo/> is also well-formed XML. You - hopefully - reject that too, because
> it's not valid XMPP.
>
I do. But what bothers me is more that I am asked to refuse such
opening stream for instance:
<stream:stream
from='juliet at im.example.com'
to='im.example.com'
version='1.0'
xml:lang='en'
xmlns:client='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
If the sender expects to send prefixed stanzas is an example:
"<client:message ..." Why a program would do that? I don't know and I
don't care because I expand the namespace, as required by the XML
namespace recommandation. So this is transparent for my
implementation. But for some strange reason XMPP wants me to make some
kind of exception:
---
12.2.2. Default Namespace
A default namespace declaration is REQUIRED [...]
---
Another example is this:
<stream
from='juliet at im.example.com'
to='im.example.com'
version='1.0'
xml:lang='en'
xmlns:client='jabber:client'
xmlns='http://etherx.jabber.org/streams'>
----
12.2.1. Streams Namespace
A streams namespace declaration is REQUIRED in all XML stream headers
and the name of the streams namespace MUST be
'http://etherx.jabber.org/streams'. If this rule is violated, the
entity that receives the offending stream header MUST return a stream
error to the sending entity, which SHOULD be <invalid-namespace/> but
MAY be <bad-format/>.
----
This is perfectly valid as for namespace qualification, but the RFC
"REQUIRES" a stream namespace declaration (why is a default ns for
stream not good? Once again this should be transparent).
Etc.
> The spec says very little - intentionally - about the validity of the XML
> involved.
Yes but it says these stuffs about how the namespaces MUST or SHOULD
be declared or set default, which I don't understand.
By the way, to come back to the example of the use of the default ns
as a "signal" for knowing if it is a client/server/component, I
already answered that you get this information anyway immediately
after (through a stanza).
But in fact I thought afterwards: you also get it in the stream
header, even without the default ns to "jabber:client/server". You get
this information from the "from" attributes:
- if there is no "from" attribute, then it is definitely a client, as
a server must set a "from".
- if there is a "from", then you know anyway your users, so you can
see if it is a client or a server.
But even without this, we still get all the necessary information on
the stanza qualified name anyway.
Bye.
Jehan
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.