W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > January to March 2000

RE: Difficulties with URI="" and IDREF

From: Joseph M. Reagle Jr. <reagle@w3.org>
Date: Wed, 05 Jan 2000 15:59:29 -0500
Message-Id: <3.0.5.32.20000105155929.00aa67b0@localhost>
To: "John Boyer" <jboyer@uwi.com>
Cc: "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>, Dan Connolly <connolly@w3.org>
At 10:38 00/01/04 -0800, John Boyer wrote:
 > However, URI="" has no scheme, so presumably the
 >application is being asked to provide the document's bytes, and presumably
 >it will do so in an application-specific way.
 
Also, not all URIs include a scheme that designates ways of providing a
document's bytes (for instance, URN or UUID).

 >Currently, URI="" cannot be used without some kind of transform to exclude
 >SignatureValue.  Since the XPath transform is currently written in such a
 >way that W3C c14n is required, there will be no problems.  However, it
would
 >seem that any transform (such as XSLT or Java) that takes URI="" as input
 >will have a problem.  This is why we must still consider the URI=""
problem.
 >One simple solution would be to eliminate all transforms other than c14n,
 >base64 decode, xpath and xpointer.

However, these might be useful transforms for a 'URI-reference' [1].
Furthermore, they still might be useful if you do an XPath and XML c14n
(canonicalization) _first_.  Or maybe in the java example, the java code
c14n'izes and removes the signature elements itself. Consequently,
disallowing them in this particular case doesn't seem ecessary.

[1] URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]
    http://www.ietf.org/rfc/rfc2396.txt

However, the status of the URI and IDREF was 'lets put it in there, and see
what sort of response we get.' No one seems to be a huge fan from an
elegance point of view. The two options we had of proceeding were as follows:

a. (absoluteURI | relativeURI) and IDREF
b. (URI-reference) and no IDREFs

(We constrained ourselves so we'd have a single consistent way of doing
something). I'm beginning to think the right interpration would've been B.
(Partly because I don't think we can define a 'clean URI' (without a
fragment) that anyone will pay attention to. The uri schema datatype isn't
defined that way.) No attribute should be definied as an IDREF, instead it
should be defined as a URI. However, this still means that someone can
specify an XPath or an XPtr as part of the URI and also have one as part of
a transform. The consequence of this would be to return to a target
attribute of type attribute, but I'm curious to hear other thoughts.

_________________________________________________________
Joseph Reagle Jr.   
Policy Analyst           mailto:reagle@w3.org
XML-Signature Co-Chair   http://www.w3.org/People/Reagle/
Received on Wednesday, 5 January 2000 15:59:33 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:08 GMT