Re: How omniscient is "omniscient"?

I would very much like to avoid a detailed discussion of the finer
points of intermediaries.  This is why I've been pushing the view that,
so long as the message is the same at the receiving end as at the
sending end, you've got a one-way MEP.  The question about message paths
came up because, quite reasonably, you (I think) raised the issue that
this is SOAP and the SOAP processing model includes message paths.  So
if you're talking about a sender and a receiver, the message has to get
from one to the other somehow.

Similarly, Marc raised the issue of what would happen if a secure
message needed to be encrypted differently for different destinations. 
This led me to the question of what happens if it's encrypted/decrypted
in a SOAP-visible way at all along the way, regardless of how many
receivers there are.  The answer I heard at the end of the call was,
IIUC, that the only instance of the one-way MEP involved was the sending
of the encrypted message.  The actual encryption and decryption is
application-level logic outside the MEP.  I found this profoundly
unsatisfying, since clearly the whole point of the exercise is to get
the plaintext message from point A to point B intact.  If there's more
SOAP-visible stuff going on in between, then presumably that means
intermediaries.

So the whole question of message path is my attempt to reconcile the
"Point A/Point B" picture with a (perceived) need to address issues of
message path like those above.  I'd rather not talk about it at all, and
interestingly enough, I think I'm hearing the same from you.  Based on
feedback from the call, I'd rephrase the second question as:

   2. Are there any guarantees or requirements regarding the message path?

A typical transport binding (jabber, 2TCS, whatever) could choose to
assert that there are no intermediaries between the sender and the
receiver.  That is, the binding may choose to promise it won't suddenly
throw a mU fault or otherwise muck around.

If later generations decide to put together composite bindings for
things like security (I'm wondering if there aren't better ways to do
the same thing while still preserving the Point A/Point B picture), then
they can choose to say things like "the path will include matching
encrypting/decrypting intermediaries (and therefore various faults or
other mayhem might happen)".

And of course a binding can choose to say nothing on the matter.

I believe I suggested that one-way was essentially half of
request-response quite some time ago, and I doubt I was the first.  What
goes around, comes around.

noah_mendelsohn@us.ibm.com wrote:
> I think if you only look at the SOAP senders and receivers that's to a 
> significant degree peephole.  If you talk about where the message is at 
> each stage, for example whether it can live for a day in some durable 
> queue that's not formally a SOAP node, that's omniscient.  If you talk 
> about the fact that the message actually makes 3 non-SOAP hops and that 
> the message is (take your choice of) end-to-end or hop-by-hop encrypted on 
> these hops using transport-specific security mechanisms, that's 
> omniscient. 
>
> I'm a bit worried that we seem to be taking these discussions into way 
> more detail than is merited.  There were a ton of questions roughly 
> equivalent to these which, as Marc Hadley eloquently said on our call this 
> week, we talked about at length during the SOAP 1.2 design discussions. We 
> took them to a place that got consensus for releasing a Recommendation. 
> So, there are lots of them that reasonable people might want to discuss 
> more.  Nonetheless, I don't think we are chartered in this period, and I 
> certainly didn't personally sign up in this period, to work on most of 
> those.  In this period, my understanding is that we are fixing bugs, and 
> we are to deliver a one-way MEP.  I take it as implicit that the one-way 
> MEP will be in the spirit of the existing req/resp mep in its use of SOAP 
> mechanisms, etc.  As I said on the call, I think we can come very close by 
> making a one way that's similar to the request part of request/response. I 
> don't think we need to or should spend a lot of time on these broader 
> questions of what's an MEP, what's omniscience, etc.  If the answers were 
> good enough to get us a useful request/response MEP, my intuition is that 
> they're similarly good enough to ship a one-way. 
>
> --------------------------------------
> Noah Mendelsohn 
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
>
>
>
>
>
>
>
>
> David Hull <dmh@tibco.com>
> Sent by: xml-dist-app-request@w3.org
> 11/30/2006 04:00 PM
>  
>         To:     "xml-dist-app@w3.org" <xml-dist-app@w3.org>
>         cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
>         Subject:        How omniscient is "omniscient"?
>
>
>
> There has been some use lately of the terms "peep-hole" and
> "omniscient", referring to views of the SOAP activity in a MEP
> instance.  I don't know what either of those terms means here.  To see
> whether a one-way message exchange has happened, we need to look at the
> sender and all receivers /and nothing else/ (like so many other things,
> this is independent of the supposedly complicating matter of how many
> receivers there are. If you like, substitute "the receiver").
>
> If all receivers receive a message identical to the one sent, then we
> have normal operation of the one-way MEP.  If not, we have abnormal
> operation, which MAY produce faults.
>
> I'm not sure if this view is a "peep-hole" view or an "omniscient"
> view.  Whatever it is, it appears to work.
>
>
>
>
>
>