- From: Tommy Lindberg <tommy.lindberg@gmail.com>
- Date: Wed, 22 Jun 2005 00:21:26 +0100
- To: jose.kahan@w3.org
- Cc: Rich Salz <rsalz@datapower.com>, www-xkms@w3.org
>Will either striking the text or changing it to request the use of exc-c14n >affect existing implementations? No it won't. I followed the advise in paragraphs [89] and [90] of Part 1 which kept me out of trouble. Like Matt I don't find Section [60] in Part 2 particularly informative. I think I would have ended up with the same result/code even if it hadn't been there. I other words I didn't pay much/any attention to it. >> XKMS messages that will be embedded in SOAP documents SHOULD be >> signed using exc-c14n. > >I also think that mentioning exc-c14n is better than just striking out the >text. Replacing the existing paragraph [60] of Part 2 with above seems fine to me. Regards Tommy On 6/20/05, Jose Kahan <jose.kahan@w3.org> wrote: > Hi folks, > > A question for developers. > > Following Rich's comment: > > On Thu, May 19, 2005 at 10:42:21AM -0400, Rich Salz wrote: > > > > I think that since we no longer use QName's in XKMS, that this is not > > much of an issue any more. Also, since WS-Security and WS-I, et al., > > are now all recommending exclusive-c14n, which doesn't have the problems > > caused by standard c14n and embedding content, we should strike this. > > > > It's not really an editorial change, although it can be treated as such, > > since it's removing a limitation. We can either remove the text, and > > let folks like ws-i, etc., advise what to do, or we can explicitly say > > XKMS messages that will be embedded in SOAP documents SHOULD be > > signed using exc-c14n. > > Will either striking the text or changing it to request the use of exc-c14n > affect existing implementations? If the answer is yes, I prefer to defer > this modification to a subsequent edition of the spec. > > I also think that mentioning exc-c14n is better than just striking out the > text. > > Tommy, Vamsi, ... comments? > > Thanks! > > -jose > > > BodyID:107510499.2.n.logpart (stored separately) > >
Received on Tuesday, 21 June 2005 23:21:31 UTC