RE: Clarification on URIs (XLink & XPtr)

 >In the XML-DSIG draft specification, I have proposed the use of XLink
 >because they do not mandate the URI portion. By default, an XLink refers
 >to the containing resource, thence allowing relative references. I
 >strongly feel that mandating the use of URI will render the
 >specification inapplicable to XML applications that heavily rely upon
 >composition (IOTP, eCheck, BIPS...). Recall that, before all, they
 >authenticate XML elements and not necessarily XML documents. 
 
I think I agree and had reformulated it yesterday as (sorry for all the
updates, but it will freeze tomorrow for FTF discussion and I'm trying to be
as responsive as possible till then):

 >XML-Signatures can be applied to any Web resource -- including non-XML 
 >content. XML-Signature referents are identified with URIs that refer to 
 >external or internal resources (i.e., network accessible or within the
same 
 >XML document/package). [Berners-Lee, Reagle, Brown, List(Vincent)] 

Perhaps it make more sense to use the XLink terminology of locator? (I'm
open to alternative wordings -- feel free to make a proposal.) Which
specifies:

Locator
   Locator ::= URI
     | Connector (XPointer | Name)
     | URI Connector (XPointer | Name)
   Connector ::= '#' | '|'
   URI ::= URIchar*
   
Regardless, we are going to  have to give more thought to the processing
model of XLink/Xptr, which I raised on the workshop list. [4] To prompt this
I also had added the following terms [3]:

    6. XML-Signature applications must
         1. understand XML-Pointers [XPointer]. Applications will
            reference/select parts of XML documents using XML-Pointer.
            [Reagle]
         2. understand XML-namespaces [XML-namespaces] in the creation of
            its own signature syntax. Applications may optionally choose
            C14N algorithms which do or do not process namespaces.
         3. understand XLink. Applications will use XLink to reference
            signed resources in the manifest. Applications do not embed
            or expand XLink references in the signed content, though
            applications may optionally choose C14N which provide this
            feature.

Another question I have, which I've wondered about in the Jetforms
submission (slow getting to our site as a NOTE, but should be up soon) is
are the following two identical?

1. select then C14N
2. C14N then select

Depending on how/if we permit XPtr, these two operations will not result in
the same fragment from which one generates a hash. If one selected a XPtr
spanning term, that included two attribute location terms (or string terms)
as its bounds, the C14Nical re-ordering of attributes will goof things. (See
sectin 3.7 [3])

 ____


[1] http://www.w3.org/TR/WD-xlink#addressing
[2] http://www.w3.org/Signature/Drafts/xml-dsig-requirements-990601.html
[3] http://www.w3.org/TR/WD-xptr

[4] http://lists.w3.org/Archives/Public/w3c-xml-sig-ws/1999May/0000.html

Resources, XPointer, and Fragment Identifiers
Joseph M. Reagle Jr. (reagle@w3.org)
Thu, 06 May 1999 16:20:54 -0400 

Messages sorted by: [ date ][ thread ][ subject ][ author ] 
Next message: Joseph M. Reagle Jr.: "Draft Charter" 

-----------------------------------------------------------------------------
---

Message-Id: <3.0.5.32.19990506162054.00a287d0@localhost>
Date: Thu, 06 May 1999 16:20:54 -0400
To: "XML-DSig Workshop" <w3c-xml-sig-ws@w3.org>
From: "Joseph M. Reagle Jr." <reagle@w3.org>
Cc: "Daniel Veillard" <veillard@w3.org>, bill.smith@sun.com
Subject: Resources, XPointer, and Fragment Identifiers

[I'm raising this issue while it's fresh in my mind and to put it on the
issues list of the WG once it is formed.]

I was talking to Philipp Hoschka (W3C Architecture Domain Lead) about some
of the coordination issues with XML and we spent a small amount of time
talking about filters, selectors, and XPointer when I said signed-XML was
probably going to punt on the issue of using "filters" to say which elements
and sub-blocks are signed. Or, only go as far as requiring that if an
element block wants to be signed, it should have an ID attribute specified
that can be referenced in a locator in the manifest. Philipp responded by
stating that if you permit URIs, then you permit XPointer. [1] Were we going
so far as to say only URIs, or only certain types of URIs. (He also
mentioned that XSL selectors and XPtr should converge.)

This seems odd to me in the following way. signed-XML will be a XML 1.0
application, but need it be an XPtr application, do they mean the same
thing? Imagine one implementor who supports XPtr and uses them in his
manifest, and another who doesn't. The semantics are not shared and in a way
that is dangerous to interoperability.  I'm comfortable with the idea of a
signed-XML application failing on the fact that it doesn't recognize a HTTP
scheme (e.g., locator="foobar:ASF*&@#$~~"). But less comfortable on failing
because of fragment identifiers.

Presently, Richard Brown's signed-XML draft states that:

      Locator: Locator value that contains either a URI [RFC 2396], a
           fragment identifier, or both. Notice that making use of a
           fragment identifier for a document content other than XML is
           out of the scope of this draft proposal and may lead to
           inconsistent results.

This certainly seems true. But I think we should be more specific. Also,
this might even be true in XML if XPtr is used, because the semantics of the
content after the "#" (i.e., "http://*#stuff") is defined by the MIME type.
Does the registered MIME type specify XPtr?

[1] http://www.w3.org/TR/WD-xptr
___________________________________________________________
Joseph Reagle Jr.  http://www.w3.org/People/Reagle/
Policy Analyst     mailto:reagle@w3.org


-----------------------------------------------------------------------------
---


Messages sorted by: [ date ][ thread ][ subject ][ author ] 
Next message: Joseph M. Reagle Jr.: "Draft Charter" 

_________________________________________________________
Joseph Reagle Jr.   
Policy Analyst      mailto:reagle@w3.org
XML-DSig Co-Chair   http://w3.org/People/Reagle/

Received on Tuesday, 15 June 1999 12:52:38 UTC