Re: [office] 17.5 on IRIs

["Bob Jolliffe" <bobjolliffe@gmail.com>]

Hi Michael, Andreas and all

Thanks for the clarifications.  Unfortunately I've had my head a bit
buried in the DSIG stuff so my assumptions about the way relative IRIs
(or URIs) are interpreted has been shaped in that particular dark
place :-)

I am happy to hear that the DSIG case is an outlier and a peculiarity
as I agree with Andreas, that, in my own words, it is quite strange.

So, at least for the purposes of the errata and 1.1, there is no
inconsistency in the interpretation of the root of a relative IRI - I
think...

Regarding the DSIG revisions for v1.2, I hope to reshape our earlier
proposal quite soon.  We are also still waiting for formal comment
from both the DSS-X and the ETSI XaDES TC's.

Regards
Bob

2008/9/23 Michael Brauer - Sun Germany - ham02 - Hamburg
<Michael.Brauer@sun.com>:
> Hi Bob,
>
> On 09/23/08 11:28, Bob Jolliffe wrote:
>>
>> Dennis and others
>>
>> 2008/9/23 Dennis E. Hamilton <dennis.hamilton@acm.org>:
>>>
>>> Patrick and others,
>>>
>>> A quick question.  My reading of this ISO 26300 passage
>>>
>>> "A relative-path reference (as described in §6.5 of [RFC3987]) that
>>> occurs
>>> in a file that is contained in a package has to be resolved exactly as it
>>> would be resolved if the whole package gets unzipped into a directory at
>>> its
>>> current location. The base IRI for resolving relative-path references is
>>> the
>>> one that has to be used to retrieve the (unzipped) file that contains the
>>> relative-path reference."
>>>
>>> is that the base IRI is the Zip-file "path" to the sub-file that contains
>>> the relative-path reference.
>>
>> I can't speak for all cases but there is at least one case where this
>> is not so.  Document signatures, as produced by OpenOffice, are
>> contained in a file within the package called
>> META-INF/documentsignatures.xml.  Signatures contain relative IRI
>> references (actually URI) to the streams which are signed.  So, for
>> example, we find <Reference URI="content.xml">.  Note this IRI is
>> relative to the root of the package, and not "the sub-file which
>> contains the relative-path reference".  Otherwise it should be
>> <Reference URI="../content.xml"> , which I think would actually be
>> better, but so be it.  These signatures are not documented in the
>> standard, so technically they could be changed, but that would break
>> all the existing signature implementations.
>
> That's a good point. I believe the reason OOo writes "content.xml" rather
> than "../content.xml" is that we consider all streams within META-INF to be
> information that belongs to the package itself rather than to the content
> that is stored within the package, and that we therefore have used the same
> convention as for the manifest.xml. In the manifest.xml, we are not using
> URIs but paths, and the paths are relative to the package root.
>
> But of the cause, the URI attributes takes an URI rather than a path.
> Therefore, unless we state otherwise, it can be assumed that the rules
> regarding IRI processing apply here. We therefore should either state in the
> description of the digital signature feature that these URIs relate to the
> package root, or we should adapt OOo. But even in the later case, a
> clarifying sentence within the description of the signature feature may be
> helpful.
>
> Anyway, that is something we have to address for ODF 1.2. Since digital
> signatures are not part of ODF 1.0, this issue does not matter there.
>
>>
>> On the basis of my experience above, I have worked on the assumption
>> that the way to interpret a relative IRI is that it is always relative
>> to the root directory of the package.
>>
>>> So the relative path may need to be
>>> de-"../"-ed and the correct prefix pushed onto what's left to make the
>>> Zip
>>> file name that is used.   Of course, if de-"../"-ing exceeds the path
>>> depth
>>> of the sub-file, we know that the remainder must be used with the host-OS
>>> file system.
>>>
>>> For the most part (e.g., in the content.xml file), the in-package
>>> relative
>>> URIs start with "./" followed by what is actually the Zip filename for
>>> the
>>> referenced object.
>>
>> This starts to stretch the meaning of relative and is quite strange.
>> What happens if you rename the file?  Does this break all the internal
>> references?  Or what if the package doesn't have a filename?  It
>> doesn't need to have if it is in-memory or being streamed from a file
>> descriptor like a socket.
>
> That is the reason we only allow relative-paths for referencing files within
> the package. And while I am not 100% sure, I believe this is exactly why we
> added the note that
>
> "IRI references inside a package may leave the package, but once they have
> left the package, they never can return into the package or another one."
>
>>
>>> I have a master document and the way it's content.xml file references the
>>> related component documents is via relative URIs such as
>>> "../MasterChecker2.odt".
>>>
>>> I have no handy ODF samples with any XML files below the top level of the
>>> package that also have relative URIs in them.  The manifest.xml file is
>>> not
>>> at the top level, but its file references are all via manifest:full-path
>>> references and these are strings, not URIs.  In fact, they are like Zip
>>> filenames for Zip package parts (and some empty directory-named parts)
>>> although there is no description in the ODF specification of the format
>>> or
>>> encoding of these attribute values.
>>>
>>> But we seem to have enough evidence that the base IRI for relative-path
>>> references is the IRI of the container of the package sub-file that
>>> contains
>>> the references
>>
>> I've attached an example signature file as evidence of the opposite.
>>
>>> So this particular paragraph seems perfectly clear.  In 17.5, it is only
>>> the
>>> final paragraph that is lacking, and the list at the beginning of the
>>> section is problematic too.
>>
>> Unfortunately it looks like we have two distinct inconsistencies here.
>>  One related to what exactly a relative IRI is relative to - there are
>> two possibilities and we have evidence of both.
>
> We do not have an inconsistency in ODF 1.0 and 1.1. We may have one in ODF
> 1.2 only regarding the use of the URI attribute in digital signatures. We
> should resolve that, but I don't think we need to consider this case for the
> ODF 1.0 errata.
>
>>
>> The other is whether  IRI="./somefile" refers to some sibling file in
>> the filesystem relative to the package or to some sub file in the root
>> in the package.  Again it seems we have evidence of both.
>
> The ODF 1.0/1.1 and even the ODF 1.2 spec are clear in this regard. They
> state:
>
> "A relative-path reference (as described in §6.5 of [RFC3987]) that occurs
> in a file that is contained in a package has to be resolved exactly as it
> would be resolved if the whole package gets unzipped into a directory at its
> current location. The base IRI for resolving relative-path references is the
> one that has to be used to retrieve the (unzipped) file that contains the
> relative-path reference."
>
> It is only the digital signature implementation in OpenOffice.org that
> behaves differently. The simple question is whether this is reasonable and
> that we therefore should state that exception in the ODF 1.2 specification,
> or whether we simply should consider this behavior as a bug in
> OpenOffice.org.
>
> Best regards
>
> Michael
>
> --
> 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: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
> Vorsitzender des Aufsichtsrates: Martin Haering
>