XML Protocols Telcon of 5-Oct-2005

5 Oct 2005


BEA Systems, David Orchard
IBM, Noah Mendelsohn
Nokia, Mike Mahan
Oracle, Anish Karmarkar
Sun Microsystems, SeeBeyond, Pete Wenzel
Sun Microsystems, Marc Hadley
Canon, Herve Ruellan
IBM, Chris Ferris
W3C, Yves Lafon
Iona Technologies, Suresh Kodichath
Microsoft Corporation, Mike Vernal
SAP AG, Volker Wiechers
BEA Systems, Mark Nottingham
Canon, Jean-Jacques Moreau
Microsoft Corporation, Doug Purdy
Oracle, Jeff Mischkinsky
Sun Microsystems, Tony Graham
Mike Mahan
Noah Mendelsohn


<scribe> scribenick: noah

<scribe> Agenda: http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2005Oct/0002.html (member only)

<scribe> scribe: Noah Mendelsohn

F2F Scheduling

MM: Yves has proposed we meet at Tech Plenary
... I've put in for one day
... Mark Nottingham reports WSA will meet at TP or close by

Noah: I'll have Schema and TAG

DaveO: I'll have TAG, WSA and WSDL

MM: others with issues?

Anish: potential conflicts with WSA and WSD?

Marc: WSA and WSD

Various: doing at the TP is good overall, as we don't have to justify extra travel

MM: how much time do we need, 1 day?
... 1/2 day?

<scribe> ACTION: Mike Mahan to figure out F2F plan

Approval of Minutes

See minutes at: http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2005Oct/att-0001/2005-09-28-minutes.html

MM: let's leave more time for review and approve later

Action Items

2005/08/10: Yves Send a proposal to resolve issue rec33

<scribe> PENDING

MM: Yves has been on vacation, on hook for next week.


2005/08/17: Yves Send out a revised timeline for the new XMLP charter


<scribe> CLOSED - yet discussed in telecon. Close this. Tracking issue with

last Yves AI


2005/08/17: Editors Summarize the current requirements for the one

way MEP

<scribe> DONE (although progress report will be recurring agenda item)

MM: we'll close as action, carry as ongoing agenda item


2005/09/14: Mike Review appendix K and/or L from Voice Browser

<scribe> PENDING

MM: still pending


2005/09/28: Mike Revise the timeline for the charter and email to


<scribe> DONE


2005/09/28: Herve Send closing email for issue 34rec

<scribe> DONE


2005/09/28: Herve Send closing email for issue 35rec

<scribe> DONE


2005/09/28: Yves Create 36rec from


<scribe> PENDING

MM: still pending


2005/09/28: Herve Propose clarifying text for 36rec

<scribe> DONE

MM: Herve has sent email, therefore done.


2005/09/28: Mike Talk to the CG wrt scheduling and potential f2f at

the TechPlenary

<scribe> DONE

MM: this action closed, but note new action on F2F taken today

XMLP Requests

>From the agenda: ATF Issue: Does the SOAP/HTTP binding require a SOAP env in the response?

MM: People have been missing in telcons. Maybe we have the people we need today?


Emails from Agenda:

Private list:



Dist app:





- clarifies that other specs can modify the SOAP HTTP binding



- detailed changes



- OK, but more perhaps entity body in a 202 response. BP


Anish: the issue is whether an empty response can be used with the SOAP/HTTP binding
... comes up because WSA allows replyto, so you have to figure out what to send back as HTTP response
... my initial position was "no, can't do that"
... others then pointed out that implementations vary

(scribe is having trouble understanding Anish)

Anish: maybe we could do an errata or some such to allow empty body
.. there seems to be agreement on what wire format would be if we allowed this
.. we could either say "yes, implementors want this" or "build your own extension bindings"

MM: Marc Hadley also posted things

<marc> my proposal was spcific changes to doc to support empty 202

<marc> [over]

<anish> marc's proposal: http://lists.w3.org/Archives/Public/xml-dist-app/2005Aug/0014.html

<anish> Dave has a SOAP-request MEP that he created for the ATF

Noah: MEPs are important. The one we have says soap envelope comes back

DaveO: We can change that

Noah: but that's an incompatible change, and can't be done in erratum

DaveO: two ways of looking at the incompatibility question: (1) taken literally, it's an incompatible change, because it changes behavior of senders and receivers vs. (2) request optional response is what they have implemented
... would rather align with industry practice

Noah: two issues (a) is this a good change (b) how much W3C process would we need to change it

DaveO: I think on balance it's a good thing to do.

Anish: We have a new one-way MEP on our plate. We are going to come up with a binding that supports the two existing MEP's and new one-way. Maybe we can fix this in the potential new binding.

DaveO: true, could do über binding

Anish: still open questions on namespaces, etc. for new binding

MM: should we try making this a requirement for the new work?

Noah: yes, I would think that implementors who want new function would be the same ones implementing the new binding
... right, so from a process point of view, our new work on one-way takes us through the REC process anyway. That gives us a train we can ride should we wish to do these changes to MEPs and/or request/response in the HTTP binding.

Anish: I do want to be careful with backwards compatibility

Noah: well, there is the one new case where no envelope shows up, but you're saying that when the envelope does come back, the rules should be as they were?

Anish: right

Marc: I think Anish is saying "no funky new pseudo-acknowledgement on the response, if the real response is going elsewhere"

Anish: right, especially for the existing request/response MEP

MM: are you talking about David Hull's proposal?

Marc: don't think so

Anish: yes, I recall now, there was some talk about an 'ack' of some sort. Yes, funky.

Marc: agree. We need to stay backwards compatible. If you get an envelope back, that is >the< response

MM: is sense of group to bundle as new requirement for the new work we're doing?
... comments?

Anish: should we do something similar for 33Rec?

MM: good point, but scheduled for discussion next week after input from Yves. We'll point him to these minutes in the meantime.
... Conclusion: We'll make this a new requirement for the new MEP work we're doing, and will so inform the editors.
... This started in ATF. Latest mail from WSA did not mention this. Do we need to coordinate with them on this plan?

<scribe> ACTION: Anish to respond to his xmlp-comments posting, copying WSA, with early word of likely disposition of optional response in the HTTP binding

<scribe> ACTION: Yves to create formal issue for optional response in the HTTP binding

SOAP 1.2 PER specs

MM: skipping for this week

New SOAP MEP/Binding work item

MM: any word from editors?

DaveO: Nothing direct. I spent an hour or two with David Hull of Tibco. May have convinced him that simplified approach is one he can live with, and I also saw some merit in his approach.
... we seemed to be converging on optional request/optional response as a possible approach. Doesn't necessarily reflect views of other editors.

Anish: we now have firm requirements from WSA
.. they are now specifically asking for one way similar to WSD, which raises some question about the optional request/optional response approach

Now discussing requirements in: http://lists.w3.org/Archives/Public/xml-dist-app/2005Oct/0000.html

First issue: Timely Delivery

MM: can someone say what this means?

Anish: speaking for myself...they don't want to be delayed by this binding's availability
... needed for async enablement of MEPs


DaveO: Note what they didn't say...
... They did not say just do the one-way MEP and the binding. They didn't make it a closed set. I interpret this as they said "Do AT LEAST this..."
... don't think they were offering opinion on how to be written

Noah: as written, the requirements says: "Delivery of a one-way SOAP Message Exchange Pattern" If we're going to interpret that as "a change to the existing binding to achieve the function", we should at least check with them that such an interpretation is appropriate

DaveO: I'm sure that's necessary

Marc: are we conflating MEP and bindings. Our binding supports multiple MEPs.

Noah: they actually say: "Delivery of a one-way SOAP Message Exchange Pattern and corresponding HTTP Binding,"

Anish: I thought Dave and Noah were talking about different things. Dave said "they didn't prescribe our notation"; Noah was talking about MEPs and bindings.

DaveO: when we had options on the table at WSA, it was clear to me that they were not precluding that

Noah: all I'm saying is "we should do a quick doublecheck with them if there's any question about whether we're doing what they wanted"

MM: Dave, any problem?

DaveO: no, I'd like a look at the note before it goes out if possible

MM: no problem

<scribe> ACTION: Mike Mahan to send note to WSA clarifying whether an optional request/optional response MEP/binding is an acceptable resolution to their request.

MM: Anything we can do to help the editors?

DaveO: Don't think so. Next step is for us.

<anish> it would be good to clarify that

MM: I'd encourage editors to meet this week and report to us next week. Won't make it a formal action.

Anish: i just realized that Mark's email at http://lists.w3.org/Archives/Public/xml-dist-app/2005Oct/0000.html points to 33rec, I think the WG really meant the ATF issue (of 202 response)
... I don't think this changes anything.

MM: I'll add that to the clarification email.

XOP Issues

MM: Anyone read the issue ( http://lists.w3.org/Archives/Public/xmlp-comments/2005Aug/0004.html ) or Herve's proposal ( http://lists.w3.org/Archives/Public/xml-dist-app/2005Oct/0001.html )?

Anish: the proposal looked good to me

MM: anything else?
... Adjourned

Summary of Action Items

[NEW] ACTION: Anish to respond to his xmlp-comments posting, copying WSA, with early word of likely disposition of optional response in the HTTP binding
[NEW] ACTION: Mike Mahan to figure out F2F plan
[NEW] ACTION: Mike Mahan to send note to WSA clarifying whether an optional request/optional response MEP/binding is an acceptable resolution to their request.
[NEW] ACTION: Yves to create formal issue for optional response in the HTTP binding
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.112 (CVS log)
$Date: 2005/10/28 14:03:13 $