W3C home > Mailing lists > Public > www-ws-desc@w3.org > November 2004

Re: Minutes of MEP Task Force 2004-11-23

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
Message-id: <41A3C0AC.6050207@sun.com>

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.

Received on Tuesday, 23 November 2004 22:54:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:45 UTC