W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > October to December 1999


From: Jim Schaad (Exchange) <jimsch@EXCHANGE.MICROSOFT.com>
Date: Thu, 28 Oct 1999 14:49:16 -0700
Message-ID: <EAB5B8B61A04684198FF1D0C1B3ACD194A70E5@DINO>
To: "W3c-Ietf-Xmldsig (E-mail)" <w3c-ietf-xmldsig@w3.org>
The use of Location="" to refer to the entire document appears to me to be
potentially troublesome in work flow applications.  When one starts
including or moving forward signed documents, add other items (including
other signatures) and so forth.  Using Location="" to refer to the
containing document has now rather drastically changed its meaning and its
not clear that the same set of items can be found again except potentially
by explicit inclusion (rather than exclusion). 

I assume that when this statement is made that the omission of the Location
element is absent that it is equivalent to <Location HREF="">.

While I agree that it would be nice to be able to refernce the containing
document by some simple and identifiable expression I don't believe that
Location="" should potentially be that expression.  I would like to reserve
this for a different reference, specifcally the object contained within the
Signature element.  I believe that a large number of protocal messages will
be built with the data being signed (a single item) being included in the
Object of the Signature.  These are the message that I am most worried about
size for, and would therefore like to be able to omit the Location reference
and still have it well understood what the location of the object is suppose
to be.

It seems to me that we potentially need a couple of different types of
"labels" that are distinct within the location.  Specifically would be "this
is a URI of one type" and "You (the application) know what this is really
suppose to be, find it for me" are two that spring to mind.  Potentially the
root of the document could be represented as <Location DOC/>.

Received on Thursday, 28 October 1999 17:49:19 UTC

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