- From: Joseph M. Reagle Jr. <reagle@w3.org>
- Date: Wed, 05 Jan 2000 15:59:29 -0500
- 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 UTC