[Standards] [Fwd: Re: Namespace well-formedness and RFC3920bis backwards compatibility]
stpeter at stpeter.im
Thu Sep 18 19:05:22 CDT 2008
Here's a thread that Brendan and I had off-list. He gave me permission
to forward this to the list. I added a note about this to version -07 of
-------- Original Message --------
Date: Tue, 15 Jul 2008 06:28:05 -0600
From: Peter Saint-Andre <stpeter at stpeter.im>
To: Brendan Taylor <whateley at gmail.com>
Subject: Re: Namespace well-formedness and RFC3920bis backwards
Brendan Taylor wrote:
> RFC 3920bis-06 says:
> A XMPP entity MUST NOT accept XML data from another entity if that
> data is not well-formed in accordance with both the definition of
> "well-formed" in Section 2.1 of [XML] and the definition of
> "namespace-well-formed" in Section 7 of [XML-NAMES].
> In an XMPP entity receives XML data that is not so well-formed, it
> MUST return an <xml-not-well-formed/> stream error and close the
> stream over which the data was sent.
> The namespace-well-formedness constraint wasn't explicit in the original
> RFC (Appendix F suggests it was intended but overlooked).
> Clients can't adopt the constraint until servers do. (because otherwise
> if an attacker sends you a namespace-ill-formed stanza, the server will
> pass it on and your client will be forced to disconnect when it receives
> Ejabberd happily accepts namespace-ill-formed stanzas, I don't know
> about other servers.
That's a bug and I thought it was corrected in version 2.x.
> I agree with the updated section; XMPP should move away from the ad-hoc
> namespace handling that's been the norm. If that constraint isn't there
> then a client can't use a namespace-aware XML parser.
Right. What we do is tighten up the spec but say that (because it was
underspecified previously) older software may not comply. We have
similar text in several other places.
> Also, "In an XMPP entity" should be "If an XMPP entity". :)
Fixed. I haven't completed a detailed proofreading yet, that will happen
during my work on version -07. I'll put out a call for widespread
feedback here soon so we can get these specs done. I for one am ready to
move on with my life. :)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20080918/08bb57cb/attachment.bin
More information about the Standards