Date: 3 May, 2006
<scribe> Scribe: Pete Wenzel
Scribe for minutes selected from attached list.
Actions to be recorded on IRC.
Absent: Iona Technologies, Sonic Software, Sonoa Systems
Excused: Ericsson (Nilo Mitra), Oracle (Jeff Mischkinsky)
> - Announcements W3C?
> - AOB?
>
> 3. Approval of minutes:
> 26 Apr: http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2006Apr/0014.html
Approved.
> 2006/04/26: Noah
> Draft proposed text after Table 17.
<scribe> > PENDING
http://lists.w3.org/Archives/Public/xml-dist-app/2006May/0003.html
<scribe> Done.
> 2006/04/26: Mike
> Draft text for "before dashes" based on Chris's friendly amendment
<scribe> > PENDING
http://lists.w3.org/Archives/Public/xml-dist-app/2006May/0000.html
<scribe> Done.
> 2006/04/26: Mike
> Show the conclusions of SC3 to the mailing list.
<scribe> > PENDING
http://lists.w3.org/Archives/Public/xml-dist-app/2006May/0001.html
<scribe> Done.
> 2006/04/26: Mike
> Send query about F2F to members-only list
<scribe> > DONE
> http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2006Apr/0013.html
> Proposal for ROR
> 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
>
> Issues:
>
> SC1: 202 semantics. Table 17 for status code 202 row.
> http://lists.w3.org/Archives/Public/xml-dist-app/2006Mar/0052.html
> - I believe this is now moot, see (NM/MB exchange):
> http://lists.w3.org/Archives/Public/xml-dist-app/2006Apr/0008.html
> - Yet now continuing 202 and RX (2 separate requests) thread (DH):
> http://lists.w3.org/Archives/Public/xml-dist-app/2006Apr/0009.html
<scribe> > - New proposed text from last week around Table 17. Mike will post
> agreed material, Noah will post new clarifying text after Table 17.
<scribe> > PENDING
Noah: Based on last week's discussion, we agreed that an HTTP 202
... response could indicate an optional SOAP envelope will follow. Found
... that there is text around the table that relies on the fact that there
... is no response envelope. Proposed text:
...
... "The request has been accepted, but the server makes no commitment
... as to whether processing of the request has been completed. If a
... response SOAP envelope is provided, than it may represent a partial
... response or a status update on progress of requst processing; if no
... response envelope is provided, then any further application
... processing is beyond the scope of this use of the 6.2 SOAP Request-
... Response Message Exchange Pattern***."
Mike: We already accepted text from Chris for this part of the table.
Noah: Use Chris' text, unless the above is better.
... Next, text states that there will be immediate transition from
... "receiving" to "success" as soon as 202 is received. Should be *to*
... either "sending+receiving" and "receiving", and then immediately to
... "success" if no envelope is received.
DavidH: Comfortable with Noah's proposed text.
Noah: Table 17 is in a section entitled "Requesting". But this
... transition is to "success", so also needed to draft text for 7.5.1.5
... "Success and Fail".
Mike: Does this add conformance criteria?
Noah: No, it's just clarification.
DavidH: This won't change existing "200" implementations, because they
... do this anyway.
Noah: New proposed text:
... If the "success" state has been reached, either as a result of ... or ...
... [See IRC log at http://www.w3.org/2006/05/03-xmlprotocol-irc
... Access to log is forbidden at the time minutes are being submitted.]
... Bug in 7.5.1.4:
... Indicate status code 200 ... response includes soap envelope....
... Need to remove this.
... Look for everywhere the spec implies that 202 has no envelope.
<scribe> ACTION: Yves to perform critical review of changes SC1, SC2, SC3 to ensure the result is complete.
> SC2: Semantics of response message. 6.2.2
> http://lists.w3.org/Archives/Public/xml-dist-app/2006Mar/0051.html
> - reworked in last telecon. New text is at:
> http://lists.w3.org/Archives/Public/xml-dist-app/2006Apr/0023.html
> If no more pushback, then this is the final text
> This is DONE.
>
> SC3: OutboundMessage abstraction
> http://lists.w3.org/Archives/Public/xml-dist-app/2006Mar/0050.html
> - discussed at some length last week, search for SC3
>
> http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2006Apr/att-0004/2006-04-05-minutes.html
> - Chris has a action here
> This is DONE. - final text from Chris. Mike will repost to list.
> DaveO's draft of Part 3: (with and without state machine)
> http://lists.w3.org/Archives/Public/xml-dist-app/2006Mar/0044.html
> http://lists.w3.org/Archives/Public/xml-dist-app/2006Mar/0045.html
DaveO: Produced 2 different MEPs. First is in the style of current
... Adjuncts, keeping state transition tables. Second has state tables
... removed. State machine is still described, but Noah thought in not
... enough detail. Noah proposed friendly amendment at
... http://lists.w3.org/Archives/Public/xml-dist-app/2006Apr/0025.html; it
... still leaves out the formal state machine but in English spells out the
... rules more carefully. I (DaveO) am OK with those changes. DavidH agreed
... that Noah's added description was useful.
DavidH: We shouldn't talk about reliable delivery, but there should be
... hooks there (sending and receiving events).
DaveO: Naming of properties on sending & receiving side is an issue;
... either use different names or scope them. Thinking about incorporating
... Noah's feedback into the simplified version and publishing the result.
... Believe this will also satisfy DavidH's concerns.
<scribe> ACTION: DaveO incorporate feedback into "simplified" One-Way MEP draft
and republish. (Due prior to next meeting.)
> Issues:
> - Scope of work: MEP only vs MEP and single binding, conformance
> testing
> - Simplified vs State Machine (next item)
>
> Archives of async task force to find earlier one-way MEPs drafts -
> DavidH
> http://lists.w3.org/Archives/Public/xml-dist-app/2006Mar/0036.html
> http://lists.w3.org/Archives/Public/xml-dist-app/2006Mar/0037.html
> Critical analysis of one-way MEP proposals
> http://lists.w3.org/Archives/Public/xml-dist-app/2006Apr/0020.html
DavidH: This has been overtaken by events. No need to discuss again.
> Meaning of FAF - Anish.
> http://lists.w3.org/Archives/Public/xml-dist-app/2006Mar/0031.html
> http://lists.w3.org/Archives/Public/xml-dist-app/2006Mar/0032.html
> http://lists.w3.org/Archives/Public/xml-dist-app/2006Mar/0039.html
>
> How Many States on each end? - DavidH/Noah
> http://lists.w3.org/Archives/Public/xml-dist-app/2006Mar/0042.html
> http://lists.w3.org/Archives/Public/xml-dist-app/2006Apr/0003.html
> http://lists.w3.org/Archives/Public/xml-dist-app/2006Apr/0007.html
> http://lists.w3.org/Archives/Public/xml-dist-app/2006Apr/0022.html
scribe: [Some discussion of state model.]
... "Begin" and "End" sending events were thought to be needed to describe
... streaming, but they may not be. Will see how it works in next draft.
Noah: We are attempting to make this a "bug fix" errata. Two concerns
... on that front: (1) we shouldn't change the name of the MEP as that
... would be beyond an erratum -- thus, it should remain request/response;
... (2) we should not make "nice to have" changes -- since the Recommendation
... does deal with asynchrony, we should stick with that precedent. We want
... to do pretty close to the minimum necessary to declare victory.
DaveO: Proposed text allows asynchrony.
> Multiple MEPs per binding - Anish/Noah
> http://lists.w3.org/Archives/Public/xml-dist-app/2006Apr/0006.html
> http://lists.w3.org/Archives/Public/xml-dist-app/2006Apr/0019.html
Mike: Can we discuss this?
Noah: Not critical path; propose to wait until Anish is available.
> Two questions - DavidH
> http://lists.w3.org/Archives/Public/xml-dist-app/2006Apr/0021.html
DavidH: Already discussed; need a way to talk about reliability and
... "Tony's timeline".
Mike: Will we produce a binding for One-Way?
DavidH: Suggest binding to XMPP.
Yves: If we don't, we'll have trouble getting out of CR. We need
... implementations.
Noah: One approach was a non-normative SMTP (RFC 822) binding that was
... done for the binding framework; easy to code. Since we were asked to
... do this work, the requesters (WSA WG) should fulfill the use
... requirement, and we'll exit CR at about the same time. Just writing a
... binding proves that the MEP is usable.
DaveO: Exit criteria is determined by the WG. WSA WG decided to
... require 4 interoperable implementations for each required feature,
... and 2 for each optional feature.
Noah: Propose not to demonstrate streaming (optional feature). Wait
... for WSA WG to write a (non-normative) binding and implementation.
... When they're satisfied that it works, we're finished.
DaveO: WGs don't produce implementations; vendors do.
Yves: Infoset was in CR for a long time, waiting for implementation.
... In our case, using email binding should be easy. One or two vendors
... would be sufficient.
DaveO: Agree that we shouldn't write the binding. Hopefully we won't
... have to change anything in the MEP when that happens.
None.
> A rep from the member org at the top of the list is expected to scribe
> the meeting. If no rep from that org is able to scribe, a rep from the
> next member org on the list is expected to scribe. After one rep from a
> member org is scribe, the member org name goes to the bottom of the
> list.
> SAP
> Iona
> Sonic
> Sun
> BEA
> IBM
> Oracle
> W3C
> Tibco
> Nokia