- From: Roberto Chinnici <Roberto.Chinnici@Sun.COM>
- Date: Tue, 23 Nov 2004 14:58:52 -0800
- To: Amelia A Lewis <alewis@tibco.com>
- Cc: David Booth <dbooth@w3.org>, www-ws-desc@w3.org
Amelia A Lewis wrote: > On Tue, 23 Nov 2004 14:04:37 -0500 > David Booth <dbooth@w3.org> wrote: > >>The bottom line is that I suggest -- actually JMarsh made this >>suggestion on the call, but I didn't manage to minute it in the midst >>of our debate :) -- that the service be permitted to characterize the >>fault either as a violation of its policies about where replies are >>permitted to be redirected or as an MEP violation. How about letting >>the service characterize the fault in whatever way it sees fit? > > > Violent agreement. > > Sorry, I'm afraid that in the discussion, it must have appeared that > Roberto and I were saying that the service MUST do something, > specifically determine the node identity associated with both > origination address and reply-to address. No. I think it *is* possible > that a node could do so, and that, doing so, it could then feasibly > fault with the reason "MEP violation." It could also have a set of > policies, associated with or independent of node identity association > with addresses, which could cause a fault in the same circumstances, > certainly (as well as, potentially, in other circumstances; policy > covers a wide territory). Both faults are possible. If our > disagreement during the call was based on the notion that we would > somehow require the service to perform some form of node-identity > checking, then I must have misspoken. I would like the service to be > *permitted* to fault in this manner, if, by means unspecified, it > determines that the provided reply-to address is in fact *not* > associated with the requesting node. That's all. Absolutely. We never intended to require the service provider to deploy some identity-verification infrastructure, we just wanted to ensure that it is possible to do so. Roberto
Received on Tuesday, 23 November 2004 22:54:43 UTC