Re: Scope of MEP

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
--------------------------------------

Received on Wednesday, 6 September 2006 22:10:34 UTC