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

(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 Tuesday, 12 September 2006 23:26:02 UTC