Re: Scope of MEP

Actually, I agree with much of this, particularly the part about how
this MEP is supposed to be easy.  As far as I can tell, it actually is
easy.  I base this on our having a nice short spec that can demonstrably
be bound (as long as we allow for real-world behavior like forwarding
and multicast).

I was never that keen on the "(nearly) identical" part.  The Message
property will be identical.  The other properties may vary, but they do
that for other MEPs, too.  So let's just follow what the other specs do.

What I especially agree with, and what I've been pushing for quite a
while now, is that the important part is "to specify the means by which
the SOAP message infoset is transferred to and  reconstituted by the
binding at the receiving SOAP node and to specify the manner in which
the transmission of the envelope is effected using the facilities of the
underlying protocol."  I take "the manner in which the transmission ...
is effected" to mean things like "send email" or "send a <message/>
stanza" (and not some elaborate model of fan-out or re-writing or whatever).

As you can tell from the email binding sketch, this is in fact what
happens with the current text.  The meat of the binding is the table
mapping the MEP properties to and from their obvious counterparts in the
email message.  Multicast gets one non-normative sentence, which I added
mainly because we were making a point of it.

For what it's worth, I produced this sketch by taking the existing email
note for request-response, lopping off pretty much everything but the
sending of the initial message, and lightly seasoning the result.  This
seems strikingly in line with your assertion that you should be able to
get a one-way MEP by taking the front end of a request-response MEP.

This is why I so adamantly maintain that the current text is basically
right, that we are basically done, and trying to improve it by limiting
to unicast would not be an improvement.

I might feel differently if I'd seen any concrete proposal as to how a
unicast-only version would bind, or even if the several basic questions
I've raised about how this might work had not gone unanswered.

Again, by decoupling I am referring to the two-step process of 1) sender
gives message to transport 2) transport gives message to receiver.  The
key point is visibility.  Once step 1 is complete, the sender knows
nothing (I would argue pretty strongly that things like bounce messages
are additional instances of the one-way MEP).  E.g, if a jabber chat
server changes the <from/> and <to/> values before the receiver gets it,
the sender very explicitly has no knowledge of the new values
(particularly <to/>).  Another important feature is that the sender
doesn't directly know when (or if) the receiver gets the message.

noah_mendelsohn@us.ibm.com wrote:
> David Hull writes:
>
>   
>> (Noah Mendelsohn wrote:)
>>     
>>> "The SOAP one-way MEP defines a pattern for the transmission 
>>>       
>> of a single 
>>     
>>> SOAP message from a sending SOAP node to a receiving SOAP node."
>>>
>>>       
>> How then do you handle something like XMPP chat, which is clearly
>> unicast, and in which both the "to" and the "from" differ between the
>> sent message and the received message?  This re-writing is exactly the
>> same for type="chat" (unicast) and type="groupchat" (multicast).
>>     
>
> I think the answer is:  do it the way we did in request/response. Ignoring 
> for the moment multicast, this whole MEP was supposed to be really easy. 
> You pretty much take request/response, and leave off the response part.
>
> I think SOAP is already reasonably careful on all this.  It says that [1]:
>
> "the minimum responsibility of a binding in transmitting a message is to 
> specify the means by which the SOAP message infoset is transferred to and 
> reconstituted by the binding at the receiving SOAP node and to specify the 
> manner in which the transmission of the envelope is effected using the 
> facilities of the underlying protocol."
>
> Note that it says nothing about transmission intact of any other 
> properties, though particular MEPs and or bindings may call for such 
> things.  So, a particular MEP might say "you must be sure that the 
> sender's ImmediateDestination and the recievers ImmediateSender must be 
> the same for a given message, but I don't see that in our existing MEPs. 
> Rewriting is neither discussed nor explicitly prohibited.  Indeed, in SOAP 
> 1.2 Part 2 table 6 we find:
>
> "Set http://www.w3.org/2003/05/soap/mep/ImmediateSender to denote the 
> sender of the response message (may differ from the values in 
> http://www.w3.org/2003/05/soap/mep/ImmediateDestination ).."  Which makes 
> pretty clear that they can be different.
>
> So, this is already covered for request/response, and I would be glad to 
> carry over similar phrasing to one-way.  In general, I think we should 
> just make all these properties and their explanations as parallel as we 
> can to what we already have for the Request part of Request/Response, and 
> leave it at that.  I agree that going that far is independent of 
> multicast, should we wish to bother.
>
>  
>   
>>> So, I propose that this one be put on the "depends on multicast" pile.
>>>
>>>       
>> I put it in the "depends on decoupling" pile.
>>     
>
> I'm beginning to think I misunderstand what you mean when you say 
> decoupling.  If you mean, "which parts of the message can change between 
> sender and receiver?", I think that's already covered by SOAP 1.2 as 
> described above.  We've got a precedent for which parts of the story we 
> tell carefully (Infoset must arrive intact) and which we leave more open 
> (other properties).  You could quibble with those choices, but I don't 
> think we were chartered here to reopen them.  If we were, it would be far 
> more urgent to get them right for the normative MEPs.  Again, I think our 
> goal should be to write one-way in the style of request/resp on all of 
> these matters, except where there's something truly different about one 
> way.
>
> BTW: I would take my own medicine on that regarding ImmediateSender. While 
> I think there good reasons to make the population of ImmedateSender 
> optional, it would be fair to say that's another thing that's already 
> broken in SOAP 1.2, and beyond our remit to fix as part of one-way. 
> Honestly, on that one, I'd make it an erratum to Req/Resp, and get it 
> right in one way. 
>
> Noah
>
> [1] http://www.w3.org/TR/soap12-part1/#bindfw
> [2] http://www.w3.org/TR/soap12-part2/#tabreqstatetrans
>
> --------------------------------------
> Noah Mendelsohn 
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
>
>
>
>
>
>