OASIS Open Document Format for Office Applications (OpenDocument) TC

 View Only
Back to discussions
Expand all | Collapse all

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

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

    Posted 05-05-2010 06:41 
    Hi Rob, all,

That's a good point. Does that mean we shall keep the extended 
conforming package class? That would actually work for me.

If we keep it, shall it allow other compression algorithms than deflate 
(see http://tools.oasis-open.org/issues/browse/OFFICE-2532)? Unlike 
encryption algorithms, these algorithms would not add a real value. My 
suggestion therefore is that we only allow DEFLATE (and of course 
STORED) even for extended conforming documents. Are there objections to 
this?

Best regards

Michael,



On 05/04/10 21:14, robert_weir@us.ibm.com wrote:
> 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
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
> 


-- 
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500
http://blogs.sun.com/GullFOSS

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
	   D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Jürgen Kunz


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

    Posted 05-05-2010 16:32 
    I still don't think we need the extended conforming package, and we
certainly don't need to allow such a thing at any level in Part 1.

As I remarked earlier,
< http://lists.oasis-open.org/archives/office/201005/msg00034.html>
We can sanitize the confirming package by simply removing all bullet items
of the form

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

Since that removal will still allow the specifically-identified methods in
[xml-enc] core as optional (and covered under a different bullet in the same
lists).  This open-ended arbitrary alternative case is objectionable for the
same reason open-ended compression methods are.  Considering that
alternative encryptions are likely not to use the ODF 1.2 Package Encryption
methodology at all, this is a likely waste of specification.  

Finally, I can find nothing in section 5.1 of [xml-enc] that constitutes
specification of how to introduce alternative algorithms beyond what
[xml-enc] provides.  All it says is "Furthermore, the mechanism is
extensible, and alternative algorithms may be used," along with some
preceding recommendations about the use of namespaces.  The [xml-enc]
section 7 on conformance is a bit more emphatic on what constitutes a
conformant use.  We need to double-check what we do against that, if we
expect [xml-enc] conformance and have any *additional* conformance
requirements.

 - Dennis


    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


Related Content