See also: IRC log
<scribe> agenda: http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2006Mar/0023.html (Member-only)
MM: Yves, anything to announce from W3C CG?
YL:
New pubrules in place. Need to check documents as we publish.
... I'm not sure what changes were made. I just use the pubrules
checker.
MM: Any other agenda items?
(silence)
MM: David Hull -- need update on March 4 minutes
DH: Thought I did it.
MM: Please check.
DH: Will do.
<Yves> http://lists.w3.org/Archives/Public/xml-dist-app/2006Mar/0008.html
Note pending March 4 minutes are at http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2006Mar/0006.html
RESOLUTION: Minutes of 22 March 2006 at http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2006Mar/0022.html are approved
DH: http://lists.w3.org/Archives/Public/xml-dist-app/2006Mar/0008.html is log of 4 March
MM: Sorry, missed that.
DH: It has been "massaged"
MM: I'll republish today.
2006/03/04: Anish
Start email discussion on what FAF really means.
<scribe> CLOSED.
MM: Will discuss later today.
2006/03/04: Noah
Suggest how the group should proceed in reviewing draft
Was: PENDING - Deprecated.
MM: Noah and I discussed last week. I've given promised rollup of input received so far. Noah, comments?
NM: The consolidated comments are very helpful. I think we need to get to the point where we have agreement from the group as to what the exact list of changes is. Clearly we need to settle 202 vs. 204.
<scribe> ACTION: Yves to check pubrule changes to see whether any need advance review by our WG [recorded in http://www.w3.org/2006/03/29-xmlprotocol-minutes.html#action01]
The action above to Noah is CLOSED
2006/03/04: Yves
Propose resolution for rec42
<scribe> CLOSED
MM: Would like to go through comments.
From the agenda:
MM: Lets first deal with Anish's issue while he is on the call, then jump back to this.
See: http://lists.w3.org/Archives/Public/xml-dist-app/2006Mar/0031.html
AK:
At F2F we talked about difference between UDP vs. inherently
req/resp protocol where a response flows on a backchannel, and
there sre timing issues of waiting for the response.
... I sent email with my thoughts. Not convinced we need to do two
MEPs, one way vs. FAF.
... Not sure we can quantify timing issues.
... This is an abstract MEP anyway, somewhat indepedent of actual
on the wire flows.
... Even when sending UDP, there are issues of waiting for local
calls to complete
... The abstract MEP is somewhat different from API. Could be
mapped to API, but could also map same MEP lots of ways.
... Threads, workqueues etc. let you get the appearance of
non-blocking even when there's more work to do.
AK. You can get the same kind of errors on UDP send
NM: I agree that we dont need 2 MEPs in this space
NM:I think that bindings like HTTP should
support the existing R/R and R/O, and not any new one-way
... The transports like UDP, JMS, MQ that are inherently "do a bit
of work locally, and then you're done" should support the one new
mep
... Anyway, we should do one new MEP. Maybe or maybe not we should
say something about timing, but we should aim to work well on UDP,
JMS, etc.
DH:
Like Anish, I'm nervous about quantifying timing. Also agree we're
talking about abstract MEP.
... Also agree things like UDP can reflect errors, e.g. on bad IP
address.
... I agree with Noah that there will basically be two worlds, r/r
and one-way
... Glad to see lots of agreements.
... Useful to look at obligations incurred when using MEP. For
example, in R/R, receiver is expected to respond.
... If not, there's a failure (something catastrophic with plumbing
related to us) as opposed to fault (from outside)
... With FAF, faults don't necessarily happen.
(Noah thinks they happened, but aren't routed anywhere beyond the node on which they occur.)
DH:
By contrast in R/R, you are expected to generate and "make known"
the fault.
... Receiver is not obligated to do anything SOAP'y with errors in
one-way
... oops, using one-way and FAF interchangeably
... That's why FAF doesn't fit well on HTTP, but if you insist on
doing it, you have to look at it that way.
<marc> (marc think the same applies to RR, generate != send)
DH:
Yves mentions SMTP. Yes I can address responses, but I claim it's
mostly one-way.
... Yes someone will tend to send reply confirmation, but not
necessarily the ultimate receiver.
... Being able to address response and do response are somewhat
orthogonal.
(Noah agrees.)
MH: My point is that even in R/R the responder isn't required to do anything with the fault.
NM: I think the spec says do it.
MH: Can cut connection.
NM: I think cutting the connection is a response to a different error, such as denial of service.
MH: In the absence of getting a response, the requestor knows as much in the one way case as with r/r
NM: I disagree. If a connection closes with no resp in r/r you know there's an error.
MH: not convinced.
AK:
I like David Hull's characterization regarding responder
responsibilties.
... I think I also agree with Noah that we don't need to bind the
new one-way FAF or 1-way to HTTP.
... I'm not as convinced as Noah that you shouldn't do, e.g. r/r
over UDP-like, but you do have work to do to add
infrastructure.
... Where does TCP fit.
<anish> my concern is that we are tieing MEPs more and more closely to transport
<anish> which is why i was advocating getting rid of MEPs ;-) some time back if we want to do that (tie MEP close to transport)
NM:
mostly I'm saying that the two worlds aren't completely disjoint,
or that we won't ever need a 2nd MEP, but rather that we can get
away with one now.
... I'm proposing we draw the line at MEPs meant to be used with
transports that require no interaction with the network in order
for the sender to complete work (in the typical case)
DH:
curious accident that we never said what it is to send a simple
message
... I'll probably push for light weight, because we'd meet that
basic need.
MH: I think MEPs as currently defined don't talk about the kind of thing we're talking about now.
<dhull> agree with Marc about binding vs. MEP and which details MEP leaves out
(noah thinks the Response-only MEP has always talked about binding-level flows and synchronization)
<anish> +1 to marc
<Zakim> dhull, you wanted to re-state a main objective
MM: Do we agree, e.g. on Anish proposal on naming. Lets capture here our points of agreement
NM: Suggestions: (1) we agree on doing one MEP (2) call it one-way (3) it captures what David Hull said about sender/receiver responsibilities (4) we're ready to draft preliminary text (5) however we don't yet have agreement on timing issues...let someone draft text and we'll debate from there
<marc> sounds good
<dhull> I think we also agree that transport failures (as opposed to faults) are always possible (but the sender can't count on hearing about them)
<scribe> ACTION: Editors (Anish, David Orchard, and Chris Ferris) to draft proposed text for one-way MEP. See minutes of 29 March for details. [recorded in http://www.w3.org/2006/03/29-xmlprotocol-minutes.html#action02]
NM: Let me take a flyer on text on timing: "Note: this MEP is meant to be implementable on transports such as UDP and JMS and MQ, which have the characteristic that senders can queue messages and then proceed without interacting through the network with receivers." Not sure that's good, but maybe something like that.
DH: I think there have been some previous attempts by Dave Orchard and others to do drafts of such MEPs.
<scribe> ACTION: David Hull to look through archives of async task force to find earlier drafts of one-way MEPs [recorded in http://www.w3.org/2006/03/29-xmlprotocol-minutes.html#action03]
MM: thanks noah – agreed
Thread start:
http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0037.html
Reworked proposal:
http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0050.html
HTML Part2 proposal:
http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part2OptRespMEP.html
Consolidated comments:
http://lists.w3.org/Archives/Public/xml-dist-app/2006Mar/att-0026/consolidated_comments.txt
MM:
There were interleaved comments, comments on comments, etc. Hard to
consolidate.
... I found (a) 4 purely editorial (b) 3 substantial
... Can we move forward on some even with out Chris Ferris, who
isn't here?
DO: Might be better to wait for Chris, I'm not "swapped in".
MM: Let's start with SC1, a non-Chris issue
Issue: If we are using 202 as
indicated in Table17, there should be clarification on the
semantic: that any SOAP envelope would not represent the results of
processing the inbound SOAP message. It only indicates an
intermediate result, like an ack.
... If we are using 202 as indicated in Table17, there should be
clarification on the semantic: that any SOAP envelope would not
represent the results of processing the inbound SOAP message. It
only indicates an intermediate result, like an ack.
NM: This accurately describes what people are doing. Is it OK use of HTTP.
<Yves> <<< (rfc2616)
<Yves> The entity returned with this response SHOULD include an indication of the request's current status... >>>
YL: so everything seems to be about the request.
MM:
What's the conclusion?
... Relative to 202 vs. 204
YL: Mark B seems to be saying we should document how we're using 202.
NM: The text I've drafted says "envelopes not expected with 202. If one is there, SOAP processing of it is beyond the scope of this spec." That sounds right to me.
DO: ... Let's consider something in an HTTP request, perhaps an envelope with an RM header. Let's say there's an acknowledgement in there. Looks fine to me.
Noah is curious: would it be just as fine if the request had no RM header?
DO: I think the RM header is always there.
NM: Are we agreeing that this all points in favor of rejecting the requested edit?
DO: Yes, I think so.
MM:
Other opinions?
... we should inform Mark of why we're going here.
... volunteers?
YL: Wait for 202/204 discussion?
<dhull> Dave O's one-way MEP proposal: http://lists.w3.org/Archives/Public/public-ws-addressing/2004Dec/0159.html
MM:
OK
... Noah?
NM: Agreed.
MM: I'll wrap this into the comment note, text wrap it, but otherwise we'll wait.
<dhull> my cut: http://lists.w3.org/Archives/Public/public-ws-async-tf/2005Mar/0006.html
SC2
Proposed text:
From: 'The response message MAY contain a SOAP envelope, or else the response MUST be a binding-specific message indicating that the request has been received.'
To(1): 'The response message is a binding-specific response that MAY contain a SOAP envelope.'
To(2): The SOAP Request-Response MEP defines a pattern for the exchange of a message acting as a request optionally followed by a message acting as a response. The messages may or may not carry SOAP envelopes. In the absence of failure in the underlying protocol, this MEP consists of one request message and one optional r
and one optional response message:"
NM: I'm not sure the From/To line up as talking about the same thing. The To: looks like text that's already here.
DO: We have 3 commentors including Noah that need to be here, and Noah's not here next week.
<scribe> ACTION: Mike Mahan -- start email discussions of summarized issues SC2 and SC3 [recorded in http://www.w3.org/2006/03/29-xmlprotocol-minutes.html#action04]
MM: Yves, can we talk a bit about 202/204, and then I'd like to talk about what WSA wg has done with 202 vs. 204
YL:
Sure. We need to decide 202/204/200(length=0).
... Says roughly "I got the request, and won't tell you about its
processing."
... 202 says roughly "I got the request, and won't tell you about
its processing."
... 204 says roughly "If you put a mustUnderstand header, I would
have checked it."
... 204 cuts message channel but not error channel. 202 cuts
both.
From 2616, status code 204:
The server has fulfilled the request but does not need to return an
entity-body, and might want to return updated metainformation. The
response MAY include new or updated metainformation in the form of
entity-headers, which if present SHOULD be associated with the
requested variant.
NM: That looks to me like 204 is only for the case where you have completely fulfilled the request.
DO: Are you encouraging 204 vs. 202?
YL: Yes.
DO: Well, even notwithstanding architectural purity, it's just not what's happening.
NM: I'm still not convinced that 204 is even more appropriate architecturally, Combining that with what Dave says about widespread practice, and 202 seems like the answer.
YL:
Do we need to say anything about, e.g. mU checking having been
done?
... We might need to say something more specific than HTTP does as
to how SOAP is using this. E.g. whether mU processing is
necessarily done.
MM: Running out of time. Can we move to the mailing list?
<scribe> ACTION: Yves to start email thread on whether we need to say more about use of 202 and 204, including whether we need to discuss header processing if 202 is used. [recorded in http://www.w3.org/2006/03/29-xmlprotocol-minutes.html#action05]
MM:
Looks like we'll have to defer WS-Addressing work on SOAP 1.1.
... Adjourned
[NEW]
ACTION: David Hull to look through archives of
async task force to find earlier drafts of one-way MEPs [recorded
in http://www.w3.org/2006/03/29-xmlprotocol-minutes.html#action03]
[NEW] ACTION: Editors (Anish,
David Orchard, and Chris Ferris) to draft proposed text for one-way
MEP. See minutes of 29 March for details. [recorded in http://www.w3.org/2006/03/29-xmlprotocol-minutes.html#action02]
[NEW] ACTION: Mike Mahan -- start
email discussions of summarized issues SC2 and SC3 [recorded in
http://www.w3.org/2006/03/29-xmlprotocol-minutes.html#action04]
[NEW] ACTION: Yves to check
pubrule changes to see whether any need advance review by our WG
[recorded in http://www.w3.org/2006/03/29-xmlprotocol-minutes.html#action01]
[NEW] ACTION: Yves to start email
thread on whether we need to say more about use of 202 and 204,
including whether we need to discuss header processing if 202 is
used. [recorded in http://www.w3.org/2006/03/29-xmlprotocol-minutes.html#action05]
[End of minutes]