- 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