CR 33: Various

This is an attempt to pull some thoughts together after looking through
the WS-RX spec [1], with particular attention to section 3.10, and
reading Dug's example flow [2] and Paco and Anish's proposal for CR33 [3].

    * Section 3.10 of WS-RX uses the phrase "transport-specific
      back-channel" repeatedly but does not define it (the definition is
      clearly left to the transport).
    * The MakeConnection message seems to be essentially a poll for a
      pending message (it appears that no more than one can be returned
      at a time).  If so, perhaps the name should reflect this better. 
      My first impression of "MakeConnection" is that it must be similar
      to CreateSequence.
    * The MakeConnection message is described as one-way.  A comment in
      the WSDL particularly says "In SOAP terms the message [coming
      back] is not a response, so there is no WSDL output message."  I'm
      not sure that the implication follows, and I'm of two minds about
      the assertion that the message not being a response.  On the one
      hand, if I POST a SOAP message and a SOAP message comes back in
      the HTTP response, the interaction is indistinguishable on the
      wire from an instance of the SOAP request-response MEP.  On the
      other hand, I'm all for allowing such an exchange also to be
      described as two one-way messages (after all, the still-ante-natal
      one-way is the building block from which all other interactions
      may be built :-)
    * If the back-channel is transport specific, then it's implicit in
      the transport binding.  Any marker for it in this sense is thus
      redundant.
    * Since WS-RX appears quite SOAPy, I would be more comfortable
      seeing much of this recast, in line with Anish's suggestion and
      the WSA description of anonymous, in terms of the SOAP
      request-optional-response MEP.  It looks like RX leaves open the
      possibility of other forms of back-channel, but this would cover
      the common case of HTTP and would pick up anything else that
      supports R-O-R for free.
    * Paco & Anish's proposal also uses back-channel without defining it.
    * The SOAP 1.2 Adjuncts [4], which include the SOAP/HTTP binding, do
      not mention "back-channel" (though they do mention Backus-Naur form).
    * RFC 2616 [5] neither uses nor defines "back-channel" (though it
      does mention back links).
    * From a purely WSA point of view, the most important thing to mark
      is whether an endpoint supports non-anonymous replies.  If it
      prohibits anonymous, that will generally be because the request is
      coming in on a one-way transport, in which case the "I don't'
      support anonymous" marker is, strictly speaking, redundant.
    * I believe I would be comfortable with a specification of a
      "back-channel available" marker that defined "back-channel"
      clearly in terms of SOAP MEPs.  I can't live with the current
      "everyone knows" definition.  We're writing specs here.  That
      means we specify things.
    * OTOH, I'm 80+% sure that CR33 can also be closed with no action.

[1]
http://www.oasis-open.org/committees/download.php/20910/wsrm-1.1-spec-wd-16.pdf
(you may need to be an OASIS member)
[2]
http://lists.w3.org/Archives/Public/public-ws-addressing/2006Oct/0036.html
[3]
http://lists.w3.org/Archives/Public/public-ws-addressing/2006Oct/0094.html
[4] http://www.w3.org/TR/2003/REC-soap12-part2-20030624/
[5] http://www.ietf.org/rfc/rfc2616.txt

Received on Tuesday, 31 October 2006 06:36:12 UTC