See also: IRC log
march 4th minutes approved
april 6th minutes approved
Chris: pending
Mike: Mark Baker's comment at http://lists.w3.org/Archives/Public/xmlp-comments/2006Mar/0000.html
Noah sent a reply to Mark
<scribe> ACTION: Yves to open an issue and send closing email immediately [recorded in http://www.w3.org/2006/04/12-xmlprotocol-minutes.html#action01]
Mike: As Dave and Anish are out, will be discussed later
http://lists.w3.org/Archives/Public/xml-dist-app/2006Mar/0051.html
Noah: did we discuss the fact that a request has an envelope?
Chris: the issue is that we are not precise enough wrt SOAP message and SOAP envelope
is an HTTP GET a SOAP message?
Noah: yes
... we should clarify the definition of "message" in part1, or be
more precise in the bindings like "the request MUST contain an
envelope"
<Noah> The request message MUST contain a SOAP envelope.
<Noah> The response MAY contain a SOAP envelope, or else the response must include a binding-specific indication that the request has been received.
<DaveO> I like that.
<Noah> Thanks.
<Chris> sorry, I thought I was connected
<Chris> could someone cut-n-paste Noah's proposed text?
<Noah> The response MAY contain a SOAP envelope, or else the response must include a binding-specific indication that the request has been received.
DaveO: if there is an envelope back it may also be a binding-specific indication that the request has been received.
<Noah> The response MAY contain a SOAP envelope, and MUST in all cases include a binding-specific indication that the request has been received.
<Noah> The rec sez:
<Noah> The SOAP Request-Response MEP defines a pattern for the exchange of a SOAP message acting as a request followed by a SOAP message acting as a response. In the absence of failure in the underlying protocol, this MEP consists of exactly two SOAP messages.
<Chris> what if we changed " indication that the request has been received." to "indication as to the disposition of the request."
<DaveO> I'm liking the MAY, and MUST formulation..
<DaveO> chris agrees to dispose of the dispose suggestion
<Mike> The request message MUST contain a SOAP envelope.
<Mike> The response MAY contain a SOAP envelope, and MUST in all cases include a binding-specific indication that the request has been received.
<Noah> bye DaveO
<Mike> In the absence of failure in the underlying protocol, this MEP consists of exactly two messages.
<Noah> Status quo text for response only:
<Noah> " In the absence of failure in the underlying protocol, this MEP consists of exactly two messages, only one of which is a SOAP message:"
<Noah> Therefore, for ROR:
<Noah> In the absence of failure in the underlying protocol, this MEP consists of exactly two messages, only one of which MUST be a SOAP message:
Chris: still not convinced. is 405 a underlying protocol valid reply?
Noah: should we fix the whole thing or accomodate only marginal uses
<Noah> Noah notes to DaveO that Noah is at least being consistent in not advocating that we fix most of what's suboptimal.
DaveO: I am against doing anything more than the ROR bits
<Noah> NM: Me too. I don't mind fixing very minor "infelicities" when it's easy, but I don't feel like doing this one.
Noah: so is the proposal to avoid clarifying the glossary?
<Noah> +1 to Dave. Ship it.
DaveO: if we need to do the errata, so be it, but it would be good to ship things asap
<Noah> Final proposed SC2 text:
<Noah> The SOAP Request-Response MEP defines a patt
<Noah> The request message MUST contain a SOAP envelope.
<Noah> ******
<Noah> Final proposed SC2 test (trying again)
<Noah> The request message MUST contain a SOAP envelope.
<Noah> ******
<Noah> Final proposed SC2 text (take 3)
<Noah> The SOAP Request-Response MEP defines a pattern for the
<Noah> exchange of a SOAP message acting as a request followed by a message
<Noah> acting as a response.
<Noah> The request message MUST contain a SOAP envelope.
<Noah> The response MAY contain a SOAP envelope, and MUST in all cases include a binding-specific indication that the request has been received.
<Noah> ******
<Noah> In the absence of
<Noah> failure in the underlying protocol, this MEP consists of exactly
<Noah> two messages.
<Noah> ******
<Noah> Final proposed SC2 text (take 4)
<Noah> acting as a response.
<Noah> acting as a response.
<scribe> ACTION: Mike to send to the ML the definitive SC2 text [recorded in http://www.w3.org/2006/04/12-xmlprotocol-minutes.html#action02]
one editor only, we may have lost critical mass
DaveH: state machines are quite complex, especially
in the ROR case as it implicitely describe parallelism, while it
would have been better to describe it explicitely. However there is
a tradition to describe protocols based on state machine
... so I'm leaning toward using a simple state machine for the one
way case
Mike: so you prefer having a state machine (albeit a simple one).So you value 1) consistency 2) rigor
DaveH: yes, it makes things more explicit
DaveO: I do prefer the 1 page-long description of
the same thing described by a 3-pages description
... it seems more simple
DaveH: the problem implementing the spec is not reading a nicely written and concise spec, the issue is to understand what the spec means, and state machines (or formal notations) helps.
DaveO: waiting for a formal notation may make you miss the window
DaveH to continue the discussion on the ML.
ADJOURNED
[NEW] ACTION: Mike to send to
the ML the definitive SC2 text [recorded in http://www.w3.org/2006/04/12-xmlprotocol-minutes.html#action02]
[NEW] ACTION: Yves to open an
issue and send closing email immediately [recorded in http://www.w3.org/2006/04/12-xmlprotocol-minutes.html#action01]