Brendan Taylor wrote:
> On Wed, Oct 15, 2008 at 06:11:56AM -0600, Peter Saint-Andre wrote:
>> Brendan Taylor wrote:
>>> I just noticed this clause:
>>>
>>> ... but MUST NOT return a stream error in response to the receipt
>>> of [Bad XMLNS].
>>>
>>> Why is that there? Silently dropping the stanza seems like a bad idea.
>>> It also requires servers to be able to handle Bad XMLNS, which is a step
>>> backward from where we are now.
>> That is the nub of the issue being discussed here. :)
>
> Even if we're not willing to require servers to be draconian about Bad
> XMLNS, the ones that are draconian about it should return the same kind
> of error that they would have for Bad XML.
>
> I don't see any reason to say that they MUST NOT return a stream error.
In draft-saintandre-rfc3920bis-08, Section 12.3 *currently* reads:
***
12.3. Well-Formedness
There are two varieties of well-formedness:
o "XML-well-formedness" in accordance with the definition of "well-
formed" in Section 2.1 of [XML].
o "Namespace-well-formedness" in accordance with the definition of
"namespace-well-formed" in Section 7 of [XML-NAMES].
The following rules apply.
An XMPP entity MUST NOT generate data that is not XML-well-formed.
An XMPP entity MUST NOT accept data that is not XML-well-formed;
instead it MUST return an <xml-not-well-formed/> stream error and
close the stream over which the data was received.
An XMPP entity MUST NOT generate data that is not namespace-well-
formed. An XMPP server SHOULD NOT route or deliver data that is not
namespace-well-formed, and SHOULD return a stanza error of <not-
acceptable/> or a stream error of <xml-not-well-formed/> in
response to the receipt of such data.
Note: Because these restrictions were underspecified in an earlier
revision of this specification, it is possible that
implementations based on that revision will send data that does
not comply with the restrictions; an entity SHOULD be liberal in
accepting such data.
***
Further feedback is welcome.
/psa
