Re: Should we say anything on security?

On Wed, Sep 12, 2012 at 12:37 PM, Liam R E Quin <liam@w3.org> wrote:

 >  We can also say that another factor that may make
> > it more suitable for protocols is that it allows you to follow the
> > long-standing IETF tradition of being liberal in what you accept.
>
> I'm reluctant there. XML doesn't forbid error recovery either - it only
> forbids *silent* error recovery. If a document isn't XML you can't claim
> it's XML, but you can turn it into XML and process the result.
>

The XML Rec says (in the definition of fatal error):

Once a fatal error is detected, however, the processor must not continue
> normal processing (i.e., it must notcontinue to pass character data and
> information about the document's logical structure to the application in
> the normal way)


The way I've interpreted this (which I think it s reasonable) is that the
parser must not continue to pass start-/end-element/character data events
to the application after it has seen a well-formedness error.  This is
quite different from MicroXML where it's perfectly OK for parsers to fix
things up (eg by replacing non-characters by 0xFFFD) and continue passing
data to the application, provided only that it tells the application that
the document is not well-formed.

This is an issue for use of XML in protocols. RFC 3470 says:

The IETF has a long-standing tradition of "be liberal in what you
> accept" that might seem to be at odds with this recommendation.
> Given that XML requires well-formedness, conforming XML parsers are
> intolerant of well-formedness errors. When specifying the handing of
> erroneous XML protocol elements, a protocol design must never
> recommend attempting to partially interpret non-well-formed instances
> of an element which is required to be XML. Reasonable behaviors in
> such a scenario could include attempting retransmission or aborting

an in-progress session.


James