[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office] Do we really have that many options in ODF?
I'm willing to modify my statement to be "Everywhere there is a "SHOULD," "MAY," "implementation-defined," and especially "implementation-dependent" (including when implicit in the omission of sufficient detail for it to be anything but implementation-dependent) that is PERMISSION TO CONFORMING PRODUCERS, we need to consider *any* unnatural acts and barriers that this imposes on consumers." To clarify further: I was not distinguishing natural and unnatural with regard to the history of office productivity software. That has nothing to do with it. I was using unnatural with regard to over-burdening conforming implementation of interoperable consumers of any standard format by having to support provisions that no conforming producer might ever emit and that places consumers at the mercy of prominent producers (who one can expect to consume what they emit and perhaps little else). And with regard to Michael's question, "but do we really have that many options in ODF?" I must say, "Afraid so." - Dennis A HANDY ILLUSTRATIVE EXERCISE Although I meant this concern for optionality quite broadly, I have a great example before me in ODF 1.2 Part 3 cd03-rev04-editor-revision.odt. I will doubtless add JIRA issues about this and any similar cases that I find. But here it is as an example of what there is when one reviews specification material with a concern over sufficient but not too many options and the minimization of dependence on out-of-band agreements of any flavor. 1. This is all about 3.8.3 manifest:checksum-type. This is new to ODF 1.2 and a big improvement, because before this, 3.8.2 manifest:checksum was implementation-dependent and there was no clue what it was a checksum of. On the other hand, it is now too complicated in the following respects: 2. Consumer More Constrained than Producers. The last paragraph of 3.8.3 explicitly REQUIRES consumers to support SHA1/1K and SHA256/1K (by whatever URI or fixed attribute value is used). The last paragraph explicitly RECOMMENDS that producers use an SHA256/1K algorithm and makes no additional conformance provision on producers in that paragraph. Note that, with respect to [xmlenc-core] these are *ALL* "an alternative algorithm as specified in §5.1 of [xmlenc-core]," so I suppose the last list item in 3.8.3 should really say "any other alternative algorithms as specified in §5.1 of [xmlenc-core]" (see 4, below). 3. I note that both manifest:checksum-type and manifest:checksum are now required attributes of the <manifest:encryption-data> element and there are no defaults. There probably needs to be more about this in Appendix D so ODF 1.1 implementers are on notice that the ODF 1.2 story is different. 4. The last bullet in the list in 3.8.3 allows arbitrary additions of algorithms via identifying URIs, "as specified in section 5.1 of [xmlenc-core]." Although confined to "extended conforming packages" I have already commented on how unnecessary I believe this to be. There are adequate ways to deal with this in the event of a breakthrough or breakdown without writing blank checks. 5. An additional problem consists of the repeated references to sections of [xmlenc-core]. These are normative references. So the question is, how much of the normative provisions of [xmlenc-core] are incorporated via those normative references? No profile has been offered for how [xmlenc-core] is to be applied normatively in ODF 1.2 Part 3. 6. In the specific case of section 3.8.3 analysis, I note that the defined values and their defined algorithms for manifest:checksum-type include "an IRI listed in section 5.7 of [xmlenc-core]." That section lists 4 algorithms with their URIs. One (SHA1) is specified to be REQUIRED. One (SHA256) is specified to be RECOMMENDED. The remaining two are specified to be OPTIONAL. 7. In addition, [xmlenc-core] has a conformance section that establishes what support in (6) constitutes conformance to [xmlenc-core] and what that means for encryptors, decryptors, and applications (ODF 1.2 package producers and consumers, evidently). 8. Now, it happens that consumers get a free pass here. There is no requirement that manifest:checksum actually be checked. So, as a consumer, I wouldn't. As a producer, it appears that I must provide it and that's a problem. For security reasons, I don't want to reveal such information. So as a producer, I would never implement this encryption. Wow, that was easy. 9. The issues of profiling [xmlenc-core] are more significant for encryption (unless you use my get-out-of-jail-free don't-produce-it card). Section 3.8.3 is an easier, more-straightforward example. The question is, how, given section 3.8.3 written this way, do we know what the interoperable cases are and what is the least that consumers and producers have to do to ensure accomplishing that? - - - - - - - - - - I ain't signin' no stinkin' blank checks -----Original Message----- From: firstname.lastname@example.org [mailto:email@example.com] <http://lists.oasis-open.org/archives/office/201005/msg00169.html> Sent: Friday, May 07, 2010 10:47 To: firstname.lastname@example.org Subject: RE: [office] Do we really have that many options in ODF? "Dennis E. Hamilton" <email@example.com> wrote on 05/07/2010 12:55:06 PM: <http://lists.oasis-open.org/archives/office/201005/msg00168.html> > > I would say that everywhere there is a "SHOULD," "MAY," > "implementation-defined," and especially "implementation-dependent" > (including when implicit in the omission of sufficient detail for it to be > anything but implementation-dependent) that is PERMISSION TO CONFORMING > PRODUCERS, we need to consider the unnatural acts and barriers that this > imposes on consumers. > I don't think I'd say "unnatural" here. The history of this area is quite clear. There has never been an interoperable, widely-adopted, open standard format for office documents. For the last 30-years it has been a constant state of every vendor defining their own format and than trying to get whatever degree of interoperability they can, via whatever means they could scrap together. I think that is the "natural" state of things. [ ... ]