Re: XMLP telcon agenda, 1 Feb 2006

[Note cross-post to WSA]

DaveO to Noah:

> One thing that I didn't get from your conclusion is whether you
> believe that this incarnation of the XMLP group (that is without
> rechartering) should do the FAF in addition to r/r.

[Note on notation: FAF == "Fire and Forget".  r/r == "request response
with request-optional-response tweaks." r-o-r == 
request-optional-response.]
[Dave later continues ...]

> My belief is that if redoing the r/r using a new style is agin the
> charter, then sure as heck doing FAF is also agin the charter.  What's
> good for the goose is good for the gander and all that.

Noah to DaveO:

> Well, no, with respect. The charter focussed on meeting the needs of
> WSA. David Hull at least seems to believe that the FAF is essential to
> that.  He may be right. 

DavidO in reply:

> WS-A can sure live with request-optional-response. David Hull might
> believe otherwise, but he certainly hasn't convinced the WS-A WG that
> it needs that. I agree that it might be useful to do, but if we're
> niggling over charter scope, WS-A didn't ask for TWO meps.

On September 30/October [1], WSA explicitly asked XMLP for "a one-way
MEP."  On October 5 [2], Dave put forth r-o-r (not for the first time)
and Noah wondered whether that fit with WSA's requirements.  On October
14 [3], WSA clarified that straw polling had indicated a small
preference for a one-way MEP, but that other approaches were
acceptable.  If I've failed since then to convince WSA of its original
(albeit less than unanimous) position, what can I say?

My personal position is that

    * Some form of FAF (a.k.a. one-way) is essential to supporting the
      asynchronous cases that WSA is supposed to support.
    * FAF is a Good Thing for other reasons as well. [4]
    * Defining a few more SOAP properties [5] would also be very helpful.
    * Defining such a MEP and such properties is out of scope for WSA
      but in scope for XMLP.
    * The current re-charter is a bit vague as to whether it allows for
      a FAF/one-way MEP.  TIBCO has commented on this, taking the
      position that r-o-r is useful on its own, but not the whole
      story.  Due to a failure on my part, this comment arrived late and
      "may not have been counted."
    * Indeed, r-o-r is useful on its own, as it allows for one-way
      operation over inherently request-response protocols.
    * However, r-o-r is a poor fit for inherently one-way protocols. 
      That's what FAF is for.
    * The previous two items assume that in r-o-r, the response is
      actually mandatory, but may not always be SOAP.  If the response
      itself and its SOAPiness are /both/ optional, I don't think that
      fits /either/ case well.
    * FAF and r-o-r are by no means mutually exclusive.
    * I'm much less happy with r-o-r alone than with r-o-r and FAF
      together.  Throw in a couple more SOAP properties [5] along with
      the two and I'll be quite happy indeed.
    * The latest stuff about a non-empty 202 response is interesting but
      in need of clarification. [6]
    * I don't think I much care whether we use state machines to
      describe MEPs, certainly not as much as I care whether messaging
      is well-supported.
    * The pot pies at the Granville Island Public Market [7] are tasty.

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2005Oct/0000.html
[2] http://www.w3.org/2000/xp/Group/5/10/05-minutes.html#item06
[3] http://lists.w3.org/Archives/Public/xml-dist-app/2005Oct/0008.html
[4] http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0177.html
[5] http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0135.html
[6]
http://lists.w3.org/Archives/Public/public-ws-addressing/2006Jan/0109.html
[7] http://www.granvilleisland.com/en/publicmarket