Re: New proposed fix for here()

Hi,

Could this be addressed by simply eliminating EnvelopedSignature,
as suggested, and letting such applications use either an XPointer
or, more probably, just a null URI. This null URI can be interpreted
as per the application's needs. A null URI would obviously render
such signatures domain-specific, but it would simplify our task.

Merlin

r/dee3@torque.pothole.com/2000.08.17/08:00:12
>
>I believe there is a desire from eCheck and presumably similar
>protocols to be able to sign things relative to where the signature
>element is.  This relates to composite documents formed from
>pre-existing XMLD documents where you can't depend on using IDs
>because they might conflict in the documents combined to make the
>composite result.
>
>Donald
>
>From:  TAMURA Kent <kent@trl.ibm.co.jp>
>Date:  Thu, 17 Aug 2000 17:01:23 +0900
>Message-Id:  <200008170801.RAA16848@ns.trl.ibm.com>
>References:  <27FF4FAEA8CDD211B97E00902745CBE201AB44FB@seine.valicert.com>
>To:  w3c-ietf-xmldsig@w3.org
>In-reply-to:  Kevin Regan's message of "Wed, 16 Aug 2000 13:51:06 -0700"
>	<27FF
>4FAEA8CDD211B97E00902745CBE201AB44FB@seine.valicert.com>
>User-Agent:  SEMI/1.13.5 (=?ISO-8859-4?Q?Meih=F2?=) FLIM/1.13.2 (Kasanui)
>	     Emacs/20.4 (i386-*-nt4.0.1381) MULE/4.1 (AOI) Meadow/1.10 (TSUYU)
>
>>Do we need both of here() and the enveloped-signature transform?
>>
>>-- 
>>TAMURA Kent @ Tokyo Research Laboratory, IBM
>>
>

Received on Thursday, 17 August 2000 08:59:00 UTC