RE: [office] DSIG proposal - URI vs.

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

Oh, I see.  OK, for me "the root of the package" is different than the
location of the package, with respect to Base URL.  I have some angst about
that.  (By major surgery I meant introducing something other than the URI
type, such as the package-path type used in manifest.xml.)

INCIDENTAL REMARK: Also, although it has not been addressed in the ODF
specification, the URI specification points out that the different segments
of a path may have quite different rules because they pertain to different
means of resolution, and this is the kind of detail for an application of
URI to deal with, as in the use of paths inside Zip files by ODF.  It is
actually a little underspecified in 17.5 how the cases work within and
wandering out of a Zip file (especially around what is the character set and
encoding for within-Zip segments, etc.).  There are not actual
sub-directories inside of a Zip file (although a mapping to sub-directories
is the common implementation for import and extraction).  I take the
description of treating the path as if the package were unzipped into a file
system to be a metaphor and a logical requirement, not a literal one, since
the Unzip might fail around character-set requirements and case-sensitivity
in an actual file system and/or since the literal path might not work in the
actual file system. 

ON-TOPIC: But for the use of xml-dsig, I just think we need to get clear on
what "/" and "." mean as the URI attribute value in a <ds:Reference> in the
ODF application of XML digital signatures.  It looks to me that this and
current implementations are honored by treating them as the same and being
the "root" of the package as if the package is a subdirectory of a file
system.  I suspect there is a way to word this in terms of BaseURL and the
hypothetical explosion of the package into a file system.  "/" and "." would
be that subdirectory in this case, I think, but that doesn't give you a way
to refer anonymously to the package itself as an octet stream to be
digested.

I think anonymous reference to the package itself may be important.  Perhaps
there is nothing that will do that job?

 - Dennis

PS: I have no knowledge of current implementations inside of Zip packages.
Are they all the same? Can you help me with the context. - dh

PPS: The RDF metadata proposal involves use of URIs to refer to the interior
elements of an ODF package too.  Does the same concern apply there or are
the metadata RDF files required to be at the top level already?  (I forget.
I will check later.)

-----Original Message-----
From: Bob Jolliffe [mailto:bobjolliffe@gmail.com] 
http://lists.oasis-open.org/archives/office/200901/msg00039.html
Sent: Tuesday, January 06, 2009 04:55
To: dennis.hamilton@acm.org
Cc: Michael Brauer - Sun Germany - ham02 - Hamburg; office TC; Jomar Silva
Subject: Re: [office] DSIG proposal - URI vs.

Hi Dennis

2009/1/5 Dennis E. Hamilton <dennis.hamilton@acm.org>:
http://lists.oasis-open.org/archives/office/200901/msg00030.html
> I don't think it is that hard to choose.  I agree that it is rather
> arbitrary which choice is made.
>
> Here's my thinking:
>
> 1. [xml-dsig] specifies URI, so it seems rather difficult to borrow from
> that namespace and not use the same scheme.  We can't easily insert the
> package-root type with out major surgery on the xml-dsig schema to have an
> alternative to the <ds:Reference> URL attribute.

There is no major surgery required.  xml dsig processors simply have
to set a BaseURI to the root of the package.  Most implementations,
such as the JSR 105: XML Digital Signature APIs have a facility to do
exactly this.

[ ... ]

Current implementations use the following convention for the
<ds:Reference> URL attribute:
 <Reference URI="content.xml">
 <Reference URI="Thumbnails/thumbnails.png">

The discussion is about the Base URI to be used rather than the root.
If there were no existing implementations, then I would have suggested
the same as you.  But there are and it doesn't make sense to make a
recommendation which will break all existing signatures.  So its about
deciding that URI's in signatures should always be treated as a
special case following Michaels reasoning, or whether we just find a
way to accommodate this in existing signature forms and find a way to
revert to a more 'ODF conventional' form when new forms of signature
are proposed (not here yet, but on the horizon).

[ ... ]