W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > April to June 2002

Re: newbie Question about PKCS#7

From: Joseph Reagle <reagle@w3.org>
Date: Tue, 21 May 2002 08:50:54 -0400
To: "Tom Gindin" <tgindin@us.ibm.com>
Cc: "Ed Simon" <edsimon@xmlsec.com>, "Roman Huditsch" <roman.huditsch@hico.com>, <w3c-ietf-xmldsig@w3.org>
Message-Id: <20020521125055.62EA64F4@policy.w3.org>
On Tuesday 21 May 2002 07:39, Tom Gindin wrote:
>       If the syntax which has been suggested for transparent non-XML data
> could be interpreted as a node-set, then IMO we need a syntax which
> explicitly tells developers: "This reference accesses data transparently
> as a sequence of octets.  That data is part of the base on which the
> digest is calculated, but is not to be interpreted as XML."

I'm not sure I understand your question (nor understand or agree with 
Christian's response.)  I don't grok "transparent non-XML data could be 
interpreted as a node-set". The process and result of dereferencing a URI 
is defined by the scheme. In the URI="http://example.com/bar.xml#chapter1" 
the http scheme yields an entity body that is naturally octets. 
Furthermore, the client's interpratation of those octets (such as the 
fragment identifier) is further defined by the octets' media type 
(specified "out-of-band", for example in the http headers). In this case, 
the fragment identifier identifies a particular element (and sub-tree via 
XPointer), if no subsequent transforms are defined, that nodeset is 
serialiazed via c14n. However, because of this "server provides, 
client/proxy interprets" confusion, we recommend against this approach 
regardless. "Again, for the sake of interoperability, the element 
identified as 'chapter1' should be obtained using an XPath transform rather 
than a URI fragment (barename XPointer resolution in external resources is 
not REQUIRED in this specification)."

Regardless, I've expect I've gone afield from your original question. 
Perhaps if you could provide a complete example?
Received on Tuesday, 21 May 2002 08:50:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:37 UTC