See also:IRClog
Yves Lafon
<scribe> Agenda:http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2006Jan/0034.html
both actionsdone
Expectannouncement soon regarding W3M processing of comments
tibco sentcomment about the scope of the one way mep, was notreceive
David will sendto Yves the comments and Yves will make sure they are taken intoaccount
expect decisionon the charter by next week
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 newones
Mike: Noah madea comment against that, proposing a new URI for this, citingwww-tag discussion
Chris, even ifwe handle the URI in a new spec, the concept is coined in thecurrent one.
(from the datedREC)
<cferris> cool URIs don'tchange... 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 SOAPMEP concept with Noah [recorded inhttp://www.w3.org/2006/02/01-xmlprotocol-minutes.html#action01]
Mike: the onlynew issue is the XOP comment. Herve took the action to analyze andpost 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 usea cid: URI in the example, but in a wrong way. We should acceptthis issue, and close it with the proposed change
(change theincorrect examples to use e-mail addresses instead of HTTPURIs)
ACTION: Yves to open theissue wrt XOP comment [recorded inhttp://www.w3.org/2006/02/01-xmlprotocol-minutes.html#action02]
ACTION: Herve to send thespecific resolution for the above new issue [recorded inhttp://www.w3.org/2006/02/01-xmlprotocol-minutes.html#action03]
One wayMEP
Mike: First,lets let David Hull present his Part 2 findings regarding MEPsignalling
[unattributed]:in most scenario, the MEP signaling is not useful but it may happenthat a server or client need to know which MEP is in use
DavidH: it's notapplicable to all bindings, only specific to HTTP.
DavidH:Signalling does not always to be explicit. We don't have adefinitive use case for a MEP signal.
Anish: Signallingis by the HTTP verb
DavidH:Dispatching off the verb method is a one off, for the case ofHTTP
Yves: Explicitsignalling solves R/R vs ROR
DavidH: R/R andROR are similar, yet they diverge.
ChrisF:<discusses signalling in the context of multiple levels ofMEPs)
Yves: if the client knowsbeforehand that the server is able to handle req/opt resp, then itmakes also must understand not very useful
DavidH: in the case ofaddressing, yes to ensure that you are talking to a ws-addressingaware server, then using mustunderstand is safer
<GlenD> I actually don'tagree with that - it's up to the spec author to decide whetherunderstanding one header in a given spec implies understanding allof them, IMO.
<anish> right, as a QNameauthor, we can say that understanding the QName wsa:ReplyTorequires you to understand all the other QNames defined inws-addressing
<GlenD> ("that" was Chris'comment that he didn't like the fact that understanding"wsa:Action" implies understanding anything else in thatnamespace)
<GlenD> +1 Anish, you cansay "understanding any of the headers in this spec requiresunderstanding all of them", and that's fine too.
Chris:Goodchance to discuss where the members are regaridingproposals
Chris: in sync with Noah,removingreponse-onlywould be a big change
Marc: haven't been keeping upwith all the emails. Are the two approaches equivalent and changethings only in terms of documenting what happen on thewire?
Marc: I am fordoing the minimum required to declare victory, going back to aworking draft state is not apealling
Chris: we have a spec thatpeople are already using, so changing the spec for the sake ofhaving another view of the same thing is not worth it
<anish> +1 to marc's 'minwork to decl. victory'
DavidH: I'm in the camp ofdocumenting ror, and do a separate faf one way
<GlenD> I think WSA reallyjust needs ROR, and does not need FAF once we've gotROR.
<GlenD> However I'm notaverse to defining an FAF MEP *after* the ROR work iscomplete.
<GlenD> +1 to Chris -let's do define some kind of proof-of-concept biding for FAF if wedefine that MEP.
<anish> if we do indeed doa true one-way mep, then what is the motivation forrequest-optional-response?
Chris: would be nice to define aXMPP FAF one way
<GlenD> anish - it dependson how you think about it. :) I am of the opinion that we shouldNOT try to bind a "true" FAF MEP to HTTP, but rather use ROR sincethat'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 moveforward
<anish> doing faf on httpand ror on http has the same effect wrt to messages on the wire.true faf has applicability beyond http.
<cferris> I am notsuggesting faf/http
<dhull> Use r-o-r when theunderlying protocol is request-response, FAF for one-wayprotocol.
<cferris> y
Marc: intrigued by the statementthat it is not possible to do true faf on a transport likeHTTP
<GlenD> +1 Dave
<dhull> exactly
chris: it depends at which levelthe MEP is in use. appl level or binding level?
Marc: I think that FAF is notvery different from just definig "one way"
<cferris> +1
anish: the ror proposal giveswsaddr something they can use, but mapping it to UDP is morepainful than mapping one way
... to do ror in UDP you have to provide mechanism for a reply tocome back, if it's not there then you don't have ror. doing thatfor UDP is a lot
<GlenD> You don't do RORfor 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 underlyingprotocol MEP much more accurately than FAF, and avoids the "how doyou know what MEP you're using" problem.
<dhull> +1 toglen
<anish> glen, you can, butif I only want one-way over UDP, i should not have to build higherlevel correlation (i don't need it). If ROR is the only MEPavailable, then I have to do that. If one-way MEP is available thenit is much simpler for UDP like transports when a optional responseis never going to be sent
<cferris> thx
<GlenD> anish: I agreethat a true one-way is the way to go for a UDP binding, and when wehave need of such a binding we should definitely define a one-wayMEP. 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 FAFwork should be considered separately, not that we shouldn't doit.
<cferris> +1 to glen'scomment
Statementscollected 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 surewe need to do it.
Pete: Same asMarc
Suresh: Not muchpreference between FAF or ROR, but want least amount of disruptionto our RECs. Not convinced between FAF and 1way.
-final
[NEW]ACTION: Chris to followup on URI representing SOAPMEP concept with Noah [recorded inhttp://www.w3.org/2006/02/01-xmlprotocol-minutes.html#action01]
[NEW]ACTION: Herve to send thespecific resolution for the above new issue [recorded inhttp://www.w3.org/2006/02/01-xmlprotocol-minutes.html#action03]
[NEW]ACTION: Yves to open theissue wrt XOP comment [recorded inhttp://www.w3.org/2006/02/01-xmlprotocol-minutes.html#action02]
[End of minutes]