See also: IRC log
<scribe> Agenda: http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2006Jan/0034.html
both actions done
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
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]
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: 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.
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.
Marc: intrigued by the statement that it is not possible to do true faf on a transport like HTTP
<GlenD> +1 Dave
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"
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
<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.
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]