On Mon Oct 20 04:40:56 2008, Waqas wrote:
On Tue, Oct 14, 2008 at 3:28 AM, Peter Saint-Andre
<[EMAIL PROTECTED]> wrote:
> "an entity SHOULD be liberal in accepting such data."
This translates to:
"an entity SHOULD NOT use a namespace-validating parser (as
defined
in [XML-NAMES])"
No, I disagree, it translates as "an entity SHOULD NOT use a parser
that produces an unrecoverable fatal error on an undeclared namespace
prefix". I disagree that's the same thing at all.
This is indeed the case. Entities in the XMPP world tend not to use
namespace aware parsers.
Um, wait...
In
fact most do not care about namespaces at all (aside from a few
specific cases where the XEPs use
a namespace prefix in the examples, the implementations are often
coded to look for that prefix).
... because...
Testing with ejabberd and gajim (quite a popular combination), it
was
quickly clear that both did
not deal with valid <message>s where a prefix was used, and both did
deal with <message>s with a
namespace other than jabber:client.
... Gajim was using, and still does use, a namespace aware parser.
All implementations must be namespace non-aware if they don't wish
to
have the disconnection bug
that gajim had. I would like to argue that it was not a bug at all.
And Gajim is most certainly namespace aware. Please, review the code
and tell me where it doesn't conform to XML-NAMES.
There are a few cases in it's higher layers where it ignores the
namespace, and switches only based on the local-name of the element -
this is, indeed, an error, but it's one that has nothing at all to do
with this. The fact that these existed when the namespace handling in
Expat was used somewhat defeats your argument.
The behavior when a server receives a badly-namespaced stanza needs
to
be clarified. I have
been working with Matthew Wild on a not-yet-released server. We are
wondering whether we should
discard the stanza, the element, or raise a stream error. After all,
there really is no reason
that any (non-malicious) entity should be sending invalid
namespaces.
If they do then it is a bug,
just the same as if they sent invalid XML.
Wrong. It's impossible, in the current infrastructure, to receive
invalid XML except via a error in the entity you're actually
connected to.
If you receive invalid XML, there is no way to handle it in any
useful manner.
If you receive invalid XMLNS, however, it might have come from
anywhere, and merely been forwarded on to you. ANd there's at least
three ways of handling it.
a) Assume that undeclared prefixes are bound to an arbitrary
"unknown" namespace. (This is what Gajim does, now). From there,
process the stanza as much as is possible, which might include doing
nothing at all, or rejecting it with <service-unavailable/>, just as
with any other unrecognized namespace.
b) Detect unbound namespaces as a special case, and bounce the stanza.
c) Emit a stream error. This is what Gajim did previously, and what
you're recommending everyone does.
Just discarding it has a problem. Someone could send a message with
invalid namespaces to a
conference.jabber.org room. Everyone (human) would see that, except
entities which care about
namespaces. From the protocol's perspective this would be "correct",
but not from a normal user's
perspective.
And this will have exactly the same effect with any of the above
solutions, unless one is mandated. And the interesting thing is if a
server passes through - as existing servers do, essentially doing (a)
- and the clients all do (c).
Because then, sending invalid XMLNS via a chat room kicks out all the
users, and this doesn't seem to be appreciated.
Sorry if this sounds like a rant. I just don't like where we are
headed.
I don't like where we are. I don't like where some people want us to
go, because they seem to want to send us off into a fantasy land,
where servers are redeployed in seconds.
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
