W3C

XMLProtocol

01 February 2006

Agenda

See also: IRC log

Roll call

Attendees

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

Chair
Mike Mahan
Scribe

Yves Lafon

Contents


<scribe> Agenda: http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2006Jan/0034.html

both actions done

charter discussion

Expect announcement soon regarding W3M processing of comments

tibco sent comment about the scope of the one way mep, was not receive

David will send to Yves the comments and Yves will make sure they are taken into account

expect decision on the charter by next week

WSD request - URI for concept of SOAP MEP

http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0103.html

Chris: WS-D use URI to define (in the RDF mapping) the MEP in use in SOAP
... sounds reasonable, and we probably don't need to define new ones

Mike: Noah made a comment against that, proposing a new URI for this, citing www-tag discussion

Chris, even if we handle the URI in a new spec, the concept is coined in the current one.

(from the dated REC)

<cferris> cool URIs don't change... I suggest that the URI used be: http://www.w3.org/TR/2003/PR-soap12-part1-20030507/#soapmep

<scribe> ACTION: Chris to followup on URI representing SOAP MEP concept with Noah [recorded in http://www.w3.org/2006/02/01-xmlprotocol-minutes.html#action01]

SOAP 1.2

Mike: the only new issue is the XOP comment. Herve took the action to analyze and post that to list. Herve please take us through it.

<herve> http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0114.html

Herve: the issue is that we use a cid: URI in the example, but in a wrong way. We should accept this issue, and close it with the proposed change

(change the incorrect examples to use e-mail addresses instead of HTTP URIs)

ACTION: Yves to open the issue wrt XOP comment [recorded in http://www.w3.org/2006/02/01-xmlprotocol-minutes.html#action02]

ACTION: Herve to send the specific resolution for the above new issue [recorded in http://www.w3.org/2006/02/01-xmlprotocol-minutes.html#action03]

One way MEP

Mike: First, lets let David Hull present his Part 2 findings regarding MEP signalling

[unattributed]: in most scenario, the MEP signaling is not useful but it may happen that a server or client need to know which MEP is in use

DavidH: it's not applicable to all bindings, only specific to HTTP.

DavidH: Signalling does not always to be explicit. We don't have a definitive use case for a MEP signal.

Anish: Signalling is by the HTTP verb

DavidH: Dispatching off the verb method is a one off, for the case of HTTP

Yves: Explicit signalling solves R/R vs ROR

DavidH: R/R and ROR are similar, yet they diverge.

ChrisF: <discusses signalling in the context of multiple levels of MEPs)

Yves: if the client knows beforehand that the server is able to handle req/opt resp, then it makes also must understand not very useful

DavidH: in the case of addressing, yes to ensure that you are talking to a ws-addressing aware server, then using mustunderstand is safer

<GlenD> I actually don't agree with that - it's up to the spec author to decide whether understanding one header in a given spec implies understanding all of them, IMO.

<anish> right, as a QName author, we can say that understanding the QName wsa:ReplyTo requires you to understand all the other QNames defined in ws-addressing

<GlenD> ("that" was Chris' comment that he didn't like the fact that understanding "wsa:Action" implies understanding anything else in that namespace)

<GlenD> +1 Anish, you can say "understanding any of the headers in this spec requires understanding all of them", and that's fine too.



Discussion regarding member position regarding 1-way work

Chris:Good chance to discuss where the members are regariding proposals

Chris: in sync with Noah, removing reponse-only would be a big change

Marc: haven't been keeping up with all the emails. Are the two approaches equivalent and change things only in terms of documenting what happen on the wire?

Marc: I am for doing the minimum required to declare victory, going back to a working draft state is not apealling

Chris: we have a spec that people are already using, so changing the spec for the sake of having another view of the same thing is not worth it

<anish> +1 to marc's 'min work to decl. victory'

DavidH: I'm in the camp of documenting ror, and do a separate faf one way

<GlenD> I think WSA really just needs ROR, and does not need FAF once we've got ROR.

<GlenD> However I'm not averse to defining an FAF MEP *after* the ROR work is complete.

<GlenD> +1 to Chris - let's do define some kind of proof-of-concept biding for FAF if we define that MEP.

<anish> if we do indeed do a true one-way mep, then what is the motivation for request-optional-response?

Chris: would be nice to define a XMPP FAF one way

<GlenD> anish - it depends on how you think about it. :) I am of the opinion that we should NOT try to bind a "true" FAF MEP to HTTP, but rather use ROR since that's closer to what's really going on in the protocol.

<cferris> r-o-r satisfies, I think, all that is needed to permit WS-A to move forward

<anish> doing faf on http and ror on http has the same effect wrt to messages on the wire. true faf has applicability beyond http.

<cferris> I am not suggesting faf/http

<dhull> Use r-o-r when the underlying protocol is request-response, FAF for one-way protocol.

<cferris> y

Marc: intrigued by the statement that it is not possible to do true faf on a transport like HTTP

<GlenD> +1 Dave

<dhull> exactly

chris: it depends at which level the MEP is in use. appl level or binding level?

Marc: I think that FAF is not very different from just definig "one way"

<cferris> +1

anish: the ror proposal gives wsaddr something they can use, but mapping it to UDP is more painful than mapping one way
... to do ror in UDP you have to provide mechanism for a reply to come back, if it's not there then you don't have ror. doing that for UDP is a lot

<GlenD> You don't do ROR for UDP, btw - or rather you don't if you're doing things smartly. For UDP you do FAF and build req/resp correlation at a higher level (WSA). For *HTTP* though, ROR correctly abstracts the underlying protocol MEP much more accurately than FAF, and avoids the "how do you know what MEP you're using" problem.

<dhull> +1 to glen

<anish> glen, you can, but if I only want one-way over UDP, i should not have to build higher level correlation (i don't need it). If ROR is the only MEP available, then I have to do that. If one-way MEP is available then it is much simpler for UDP like transports when a optional response is never going to be sent

<cferris> thx

<GlenD> anish: I agree that a true one-way is the way to go for a UDP binding, and when we have need of such a binding we should definitely define a one-way MEP. I'm just saying that I think defining ROR for the current case (WSA/HTTP) is the minimum nec. to declare victory, and that the FAF work should be considered separately, not that we shouldn't do it.

<cferris> +1 to glen's comment

Statements collected during above conversation:

DavidH: For ROR, do minimum, define FAF

ChrisF: For ROR, do minimum; if we define FAF, we should define a binding (email, XMPP,...)

MarcH: For ROR, do minimum; not sure if FAF is necessary yet

Herve: For ROR, do less disruptive proposal; For FAF, interesting to do, not sure we need to do it.

Pete: Same as Marc

Suresh: Not much preference between FAF or ROR, but want least amount of disruption to our RECs. Not convinced between FAF and 1way.

-final

Summary of Action Items

[NEW] ACTION: Chris to followup on URI representing SOAP MEP concept with Noah [recorded in http://www.w3.org/2006/02/01-xmlprotocol-minutes.html#action01]
[NEW] ACTION: Herve to send the specific resolution for the above new issue [recorded in http://www.w3.org/2006/02/01-xmlprotocol-minutes.html#action03]
[NEW] ACTION: Yves to open the issue wrt XOP comment [recorded in http://www.w3.org/2006/02/01-xmlprotocol-minutes.html#action02]
 
[End of minutes]


Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2006/07/26 20:55:13 $