[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office] Extended conforming packages and manifest:algorithm-name
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----- From: Michael.Brauer@Sun.COM [mailto:Michael.Brauer@Sun.COM] Sent: Tuesday, May 04, 2010 23:40 To: robert_weir@us.ibm.com Cc: office@lists.oasis-open.org Subject: Re: [office] Extended conforming packages and manifest:algorithm-name 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 --------------------------------------------------------------------- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]