[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office-comment] ODF security hazard? (ODF all versions)
"Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 02/21/2009 03:39:42 PM: > > The bigger issue seems to be the failure of ODF to profile its normative > dependence on XML 1.0 at all. So, at the moment, all XML 1.0 edge/outlier > cases have to be tolerated (e.g., charsets, parameters, prolog omission, > MIME Type interaction, entity definitions, DTD occurrences, processing > instructions, and for all I know, byte-order marks). I assume that the > various normative statements on XML processors apply as well, though I don't > know about any MAYs and SHOULDs (and whose definition of such conformance > language is being used, in contrast to the ISO usage in those ODF > specifications starting with IS 26300:2006). > No doubt XML has its quirks, but these are well known and have been around for a decade. XML parsers handle them. In practice XML 1.0 is one of the most widely deployed and interoperable standards in use today. No ODF implementer sits down and writes an XML parser from scratch. They use an off-the-shelf one, typically one that comes with their programming environment or on their deployment platform. So I don't see the need to profile XML. It is odd that you would see this as a failure. Did you have a few examples in mind where this has been done with OASIS or W3C standards, where they forbid the use of core XML features such as processing instructions? Was this done in constrained environments, like mobile devices, where they needed a smaller subset of XML? Certainly Postel's robustness principle is good advice for implementors: " Be conservative in what you do; be liberal in what you accept from others.". Conservative output should shun the edge features of XML and stick to the core. But an ODF processor should be prepared to handle anything that a conformant XML document can throw at them. In fact, any reasonable ODF processor should be robust enough to handle non conformant ODF documents as well, including potentially invalid instances. This is more reasonable than failing or giving a user a cryptic error message. -Rob
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]