OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office-comment message

[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 
> 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 
> know about any MAYs and SHOULDs (and whose definition of such 
> 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 

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. 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]