OASIS Open Document Format for Office Applications (OpenDocument) TC

 View Only

  • 1.  Extended conforming packages and manifest:algorithm-name

    Posted 05-04-2010 19:12 
    We recently discussed removing the "extended" conformance clause for 
packages.  This was in :  
http://tools.oasis-open.org/issues/browse/OFFICE-2257

I think the idea was it was only used when there were additional files in 
the document beyond those defined by ODF.

However, I found another place where "extended" conformance is triggered. 
Part 3, Section 3.8.1 defines the allowed values of the 
manifest:algorithm-name attribute, and says:

"The IRI of an alternative algorithm as specified in §5.1 of 
[xmlenc-core]. Alternative algorithms may be specified by extended 
conforming documents only. They shall not be specified by conforming 
documents."

So if we eliminate the extended package distinction, then we allow 
conforming documents to be encrypted using proprietary algorithms, which I 
think goes against the interoperability benefits we were trying to foster 
by making the extended/non-extended distinction.

I don't think I'm in favor of this change.

Anyone want to argue otherwise?

-Rob


  • 2.  Re: [office] Extended conforming packages and manifest:algorithm-name

    Posted 05-04-2010 19:16 
    I agree with you.

Jomar

On Tue, May 4, 2010 at 4:14 PM,


  • 3.  RE: [office] Extended conforming packages and manifest:algorithm-name

    Posted 05-04-2010 20:25 
    A. I would remove the allowance of arbitrary algorithms from all conforming
ODF 1.2 documents, extended or otherwise.  Anything that makes it impossible
for a conforming consumer to even start consuming the document, even an
extended one where foreign-element fallbacks can be applied, should not be
supported for obvious interoperability reasons.  We have eliminated
arbitrary compression methods and we should do the same for arbitrary
encryption algorithms.

B. Remedies

 1. Everywhere in section 3.8 I would remove every bullet-item that says

       * The IRI of an alternative algorithm as specified in section 5.1 of
[xml-enc] ... 

There are some other problems (for example in the last bullet of 3.8.1 of
CD01, requiring producers to support Blowfish is strange when it is
consumers that should be required to support it [at a minimum]).

 2. Another way to do this would be to leave this alone but in ODF 1.2 Part
1 prohibit any alternative algorithms as specified in [xml-enc] section 5.1
in packages that are acceptable for ODF documents.  This leaves alternative
algorithms available for other uses of ODF 1.2 Package but not for ODF 1.2
Documents.  

I don't have a preference on which way this is achieved, so long as ODF 1.2
consumers never have to deal with alternative algorithms.  Inability to
recognize the algorithm means the document can't be consumed.  Using
alternative algorithms in the production of packages identified as ODF
documents should not be considered achieving any level of ODF 1.2
conformance, even if it is an experimental extension.  (Seems like an
experimental MIME type should go with that.)

 - Dennis



    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


Related Content