Re: Directions for SOAP One-Way MEP (Joint Note from David Hull & Noah Mendelsohn)

Yves Lafon wrote:
> On Tue, 12 Sep 2006, noah_mendelsohn@us.ibm.com wrote:
>
> When you are using the SOAP Response MEP in the HTTP binding, it is
> entirely possible that you may hit a HTTP proxy cache in the middle.
> So a first request will go through the cache to the SOAP endpoint,
> while subsequent request may be served by the cache directly.
> In that case, are we still using the SOAP Response MEP? From the
> originator, yes, as it is (mostly) transparent. For the receiver, no,
> as nothing is received in the subsequent calls.
>
> In the case of the one way MEP, the story might be the same. There is
> a global assumption that from the sending and the receiving side we
> are observing one way messages, but only the binding implementation of
> that MEP would tell the story of "is it multicast-capable or not". So
> my preference to be as agnostic as possible about the support of
> multicast in the one way MEP definition, while keeping the spirit of
> the unicast definition in the MEP (one sender, one receiver).
What would bindings look like for such a MEP,  e.g., email, jabber chat,
jabber groupchat?
>
>
>> (This note is jointly authored by David Hull and Noah Mendelsohn)
>>
>> As you all surely could not fail to observe, the two of us have been
>> particularly active and on somewhat different sides of the question: 
>> what
>> should we do about multicast in the one-way MEP?  Over the past several
>> days we've made some effort to resolve as many of those differences
>> as we
>> can manage, and we offer this status report in the hope that it will be
>> useful to the rest of the working group in deciding what to do next.
>>
>> A few days ago, David posted a summary of what he took to be the open
>> issues [1].   We are now in agreement that all of these can be
>> reasonably
>> easily resolved, regardless of whether we choose to do multicast or
>> not. A
>> few turned out to be misunderstandings, and on others we either can
>> propose specific resolutions, or we believe that the remaining work
>> to be
>> done is unlikely to be seriously controversial.  A summary of the issues
>> and their suggested dispositions is at the end of this note.
>>
>> That leaves the big question, which is whether to do multicast at
>> all. Our
>> preferences on this remain somewhat different, but we have agreed that
>> each of our concerns has been amply communicated to the group, and that
>> the remaining step is to find consensus with the other members of the
>> workgroup.  As input to that, we suggest that the following options be
>> considered.  For now, we assume that any MEP(s) to be published would be
>> as W3C Notes.  With each option, our (somewhat differing) personal
>> preferences are listed:
>>
>> Option 1:  Publish a single MEP to be named something like "One Way
>> Point-to-Point SOAP MEP"  This would allow only a single message to a
>> single destination.  (Noah's personal preference; David can't live
>> with.)
>>
>> Option 2: Along the lines of our first working draft, a single MEP
>> renamed
>> to be something like "One Way Multicast-Capable SOAP MEP".  As in the
>> first working draft , this would allow bindings to restrict
>> themselves to
>> a single message and destination, and would allow other conforming
>> bindings to support multiple messages (but with identical envelopes) to
>> multiple destinations (multicast.)  (Noah's 3rd choice.  David's first
>> choice).
>>
>> Option 3: Publish two Notes, each with one of the MEPS.  In other words,
>> publish both of the MEPs given in options 1 and 2. This is a new option
>> the WG has not considered, but it may be an appealing compromise.  While
>> it does involve publishing two Notes, we agree that once you do the
>> multicast one, the diffs to create pt-to-point are measured in a few
>> hours, if not a few minutes.  Both MEPs would be published at the same
>> time.  (Noah's probable second choice, and his preferred way if we do
>> multiast.  David's second choice, behind option #2).
>>
>> We suggest to the chair and the workgroup that the above be among the
>> options considered.
>>
>> Regarding our personal positions:  David believes that, from the
>> standpoint of applying SOAP to existing protocols, multicast and unicast
>> are equally important primitives.  David's main priority is thus to have
>> first class support for multicast, one way or the other, and while he
>> has
>> some preference for doing a single MEP with a switch (option 2), he can
>> live with option 3.
>>
>> Noah believes that unicast is the more fundamental abstraction in
>> computer
>> networking.   He therefore feels it's desirable to have a pure
>> exposition
>> of unicast in a separate MEP.  He believes that such an MEP will be the
>> natural one for UDP, IP (should we wish to put SOAP directly in IP), and
>> for the many physically point-to-point networks that are created by
>> direct
>> wiring.  Thus, Noah's preferences are, in order: unicast-only (option
>> 1);
>> 2 MEPs (option 3); one MEP with switch (option 1).
>>
>> Thus, while our preferences are different, it appears that we can both
>> live with the option of publishing two separate notes, one with a
>> unicast
>> MEP and one with a multicast.  The text in the two should be very
>> similar,
>> and in both cases easily adapted from our FWD. We acknowledge this is an
>> option the WG has not seriously debated to date.
>>
>> As to the specific issues from David's note at [1], the summary of our
>> progress on those is:
>>
>>> Rewriting of destinations [2], corrected for loss of formatting
>>> in [3], discussed in [4], [5].  This is independent of
>>> multicast  For example, re-writing can occur with XMPP chat and
>>> (IIUC) email to a single address.
>>
>> Follow precedent in existing MEPs, which makes clear e.g. that
>> ImmediateSender need not have the same value as ImmediateDestination.
>>
>>> "MEP instance" vs. "MEP" [6].  This is a trivial editorial fix,
>>> independent of everything.
>>
>> Some remaining distance between the two of us as to what's really
>> intended
>> by the original text. Shouldn't be to hard for the WG to resolve.  So,
>> specific wording TBD.
>>
>>> Inconsistency of number of properties [7].  This is independent
>>> of multicast.  Having separate names for the sender's and the
>>> receiver's view of the Message appears to make every mention of
>>> the Message property longer.  As the issue name suggests, it's
>>> also inconsistent with the treatment of the other two properties.
>>
>> Keep the property names, which are derived from the existing ROR, but
>> split into two separate property tables, one for sender properties
>> (ImmediateDestination and Outbound message) and one for receiver (the
>> other two).
>>
>>> Description of ImmediateDestination [8], discussed in [9]. This
>>> broke into 4 parts (see following), but I agree that the issue
>>> as a whole is only an issue in the context of multicast. If we
>>> were to abandon multicast, we would instead face a somewhat
>>> differently formulated set of similar issues.
>>
>>> - "immediate destination" is not a
>>>   very informative description of
>>>   ImmediateDestination.
>>
>> Editorial.  We can tune up, but note that this same sub-optimal
>> explanation is in the existing MEPs.
>>
>>> - material about multicast should be
>>>   consolidated in section 2.2
>>
>> Suggest adding high level intro to 2.2, but in the case of any
>> multicast-capable MEPs, do talk in the property tables about the fact
>> that
>> an ImmediateDestination may indeed be interpreted as causing
>> transmission
>> to multiple receivers.  Specific wording TBD.
>>
>>> - no need to talk about "multicast group"
>>
>> Replacement wording TBD.
>>
>>> - discussion of "standard means of
>>>   representing"?
>>
>> Replacement wording TBD.
>>
>> We both hope that this, which represent our joint suggestion for how to
>> move forward, is useful to the workgroup in considering next steps.
>> Thank
>> you.
>>
>> David Hull
>> Noah Mendelsohn
>>
>> [1] http://lists.w3.org/Archives/Public/xml-dist-app/2006Sep/0010.html
>> [2] http://lists.w3.org/Archives/Public/xml-dist-app/2006Aug/0046.html
>> [3] http://lists.w3.org/Archives/Public/xml-dist-app/2006Aug/0048.html
>> [4] http://lists.w3.org/Archives/Public/xml-dist-app/2006Sep/0000.html
>> [5] http://lists.w3.org/Archives/Public/xml-dist-app/2006Sep/0008.html
>> [6] http://lists.w3.org/Archives/Public/xml-dist-app/2006Aug/0047.html
>> [7] http://lists.w3.org/Archives/Public/xml-dist-app/2006Sep/0001.html
>> [8] http://lists.w3.org/Archives/Public/xml-dist-app/2006Sep/0005.html
>> [9] http://lists.w3.org/Archives/Public/xml-dist-app/2006Sep/0007.html
>>
>> --------------------------------------
>> Noah Mendelsohn
>> IBM Corporation
>> One Rogers Street
>> Cambridge, MA 02142
>> 1-617-693-4036
>> --------------------------------------
>>
>>
>>
>>
>>
>

Received on Thursday, 28 September 2006 17:20:53 UTC