Comments on the "drop response-only" Part 2 draft

First, thanks again to Pete for providing the diff markup [1]  on Dave's 
draft.  My earlier note pointed out that the diffs don't catch everything 
of significance, but they are very helpful!

Last week I took an action to provide detailed comments on Dave's draft. A 
marked up copy is attached.  I started with Pete's diff and added my own 
comments as additions.  The changes I made were:

* My comments have a yellow background  and all contain the flag 
***NOAH*** to make them easy to find.

* So I could use yellow for my comments, I change the diff markup to use 
an acqua color for additions.  It should be self evident when you look at 
it.

Sorry I didn't get this done earlier, but I hope it will still be useful 
on the call.  This exercise has reconfirmed my personal position on what 
we should and shouldn't do.

* Because of its impact on the spec, because I believe the whole point of 
MEPs is to allow applications to identify the differences and the 
commonalities between what different bindings provide, and because I 
continue to believe after this week's discussion that one way and req/resp 
are deeply and appropriately different, I am strongly opposed to merging 
request/response with response only.  Keep the two MEPs.

* In other respects, I continue to think that the editorial direction of 
dropping the detailed state machines is beyond what we need to do to 
succeed now, but I'm not against it on technical or editorial grounds.  As 
noted in my comments, Dave has kept more detail in the binding than in the 
MEP, and I think if we do decide to drop the full state machines the MEP 
descriptions should at least have detail similar to what's in his binding 
writeup.  Not a big deal I think.

Bottom line:  I'd prefer to go with something closer to the draft I sent 
[2].  I think it easily meets the requirements we've been given, and is 
much closer to the minimal needed to declare success.  At this point in 
the life of our workgroup, I think we should take such paths when 
reasonably possible.  Stability is important, and I'm not convinced that 
the state machines as documented are proving a big barrier to those who 
need to figure them out.  I do agree that they are cumbesome.  I was never 
enthusiastic about them and I'm still not, but they were a compromise we 
made to get consensus of those who joined the group to create SOAP.  I 
don't think we've had a tremendous amount of "new information" to suggest 
reopenning our status quo on them.  If the group decides to do so, I think 
Dave's editorial style signals a good direction, modulo the specific 
details mentioned in comments.

Note that I will be on the call today, but must send regrets for next 
week.  Thank you

Noah

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0124.html
[2] http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0050.html


--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------