MM: Agenda is at: http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2006Feb/0007.html
YL: New charter is now in place. Your
AC rep needs to renominate you in 45 days under the new charter (or
you will be "thrown out" of the WG :-) )
... No other W3C announcements.
MM: Welcome Vikas Deolaiker
MM: F2F still on for Mandlieu in less than 4 weeks
CF: I'll be dialing in to that
MM: Yves, do we need to set up Zakim? Do we have a phone in the room?
YL: I think I requested it.
<scribe> ACTION: Yves Lafon to ensure phone in Mandlieu room and zakim availability [recorded in http://www.w3.org/2006/02/08-xmlprotocol-minutes.html#action01]
Dave Orchard and Pete Wenzell have joined the call.
MM: Will Marc Hadley be on the call?
PW: probably not
AK: Anish is on the call as well
MM: Version at http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2006Jan/0030.html should include corrections.
RESOLUTION: Minutes of 18 January 2006 at http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2006Feb/att-0003/2006-01-18-minutes.html are approved
<mikem> http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2006Feb/0006.html
<mikem> http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2006Feb/0006.html
MM: We'll hold off on approving minutes of 1 Feb http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2006Feb/0006.html
<mikem> revised 18 jan minutes: http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2006Feb/0003.html (Scribe notes that the link provided here by Mike is actually to the email announcing the minutes. The URI in the resolution above is a correct link to the actual approved minutes.)
2006/02/01: Chris
Followup on URI representing SOAP MEP concept with Noah
CF: No progress
MM: Let's close this; we'll discuss it on the call today.
NOTE: Since we were not able to get to this item today, the chair will reask Chris to get with Noah regarding this issue.
----
2006/02/01: Yves
Open the issue wrt XOP comment
YL: Openned as Rec40. I also added the proposal from Herve to it.
<Yves> http://www.w3.org/2000/xp/Group/xmlp-rec-issues.html#x40
CF: Noah and I had a private communication from the commenter. Suggest that in general when we get issues against the Rec. that we explicitly respond, thanking for the input, and following up on progress.
MM: Yves, what's our policy.
YL: no fixed policy, but it would be a good thing to respond with issue number, etc.
NM: I note we're about to resolve
this particular one in a minute.
... Suggestions: 1) agree with Chris that we be more responsive in
general 2) in this case we inform of progress made today.
YL: well, I just sent one note, but we can send another if we make progress. Perhaps we'll be able to say it's closed.
MM: Yves, between you and me, we'll have to remember to communicate with those who submit comments in the future.
YL: Maybe just point to the issue in the list?
MM: Can take awhile to get into the list, perhaps we should respond as soon as we pick up consideration.
NM: Happy for chair and Yves to use good faith in deciding which state transitions a commenter would want to know about.
---
2006/02/01: Herve
Propose the specific resolution for the above new XOP issue
HR: DONE
MM: What happened with the charter?
YL: There were small clarifications made, e.g. explaining what an MEP is.
<scribe> New charter is at: http://www.w3.org/2005/07/XML-Protocol-Charter
<Yves> http://www.w3.org/2005/07/XML-Protocol-Charter.html
MM: So, you defined MEP in italics in the deliverable section. That's one change. Any others.
dhull: Looks like deliverables were made a bit more flexible.
<dhull> that was me
YL: Yes, gave option to modify part 2 or perhaps other documents.
>From the deliverables section:
"The Working Group also expects to publish a separate and/or updated Recommendation that provides for one-way SOAP messaging (at least a binding over HTTP). This could consist of a new Message Exchange Pattern (MEP) and/or a new or revised SOAP HTTP Binding(s). The solution may also provide for other use cases described by the Web Services Addressing Working Group, such as request-response using 2 HTTP connections.
A SOAP Message Exchange Pattern (MEP) is a template that establishes a pattern for the exchange of messages between SOAP nodes."
<dhull> brb
AK: When do we need to sign up?
YL: Starting now.
NM: Note that earlier it was noted that we have 45 days
YL: Right, 45 days from the date the new charter became effective (starts calculating...
AK: Might be important for those who have real IP issues to work through.
<Yves> around 24 march
YL: Roughly March 24 is the deadline.
MM: Thanks to Yves and team for the
work on improving the charter.
... Dave Orchard, do you want to spend your limited time on
discussing the URI for the concept of MEP.
DO: Not really. It's an interesting issue, but one-way is more interesting for now.
MM: had a good discussion last
week
... Dave, your thoughts?
DO: Charter has left it open how to
describe MEPs and what MEPs will produce.
... I strongly like the simplified style of MEP descriptions,
particularly if we will have new MEPs that won't be deployed in
HTTP.
... Glad charter gives us the option to go that way.
<dhull> +1
<dhull> (+ 1 on reduced charter niggling. More neutral on style)
DO: I have no problem keeping the
SOAP response-only MEP if that convinces people to use simplified
style. I think it's unnecessary, but can live with it.
... On fire and forget, I don't see why we can't have
request/optionalResp
... Options: we can have true FAF
... I think Noah is saying, there's a response at the protocol
level, but not at the envelope level.
... third way is that both the protocol and envelope are optional,
which is where I (Dave) have been
... What concerns me about introducing a true FAF is that what they
think is that they have a true one way, but in WSDL they're going
to have to deal with two MEPs if they deploy over both a true one
way transport and a request/response.
... I still don't see why option #3 doesn't suffice.
(Speaking for self, not as scribe, Noah says: because #3 breaks HTTP, in particular with proxies)
<anish> i'm begining to think that req-optional-res made sense if we were going to fix just the rec and be done with it. But we are creating a new rec track doc. Therefore, I'm begining to think that one-way mep is sufficient. And request-optional-res is not necessary.
DH: That was helpful, and I think I
see where the distance is coming from.
... You set out 3 options: true FAF, required response but with
optional envelope, response entirely optional
... Those are the right ways to break down wrt/ HTTP.
<anish> if we have req-res mep, soap-res mep and one-way mep and we have a HTTP binding that supports all three. From an http perspective, we have everything we need. There is no need to say in the binding for one-way mep that a soap env is not allowed in case of 202
DH: I think different protocols will define different MEPs.
<anish> i.e., it satisfies the wsrx case
<anish> and then we have a one-way mep that is more broadly useful for other transports like smtp/udp
<Yves> plus there is no backward compatibility changes
DH: In the case of WSDL I can see this is an in-only operation that's bound to HTTP. I know what to do as it's bound to HTTP, which might know that it's envelope request with non-optional response. When I see the same operation bound to SOAP over Jabber, then the WSDL operation is exactly the same, but the glue code that's binding-specific knows to use true FAF.
<cferris> +1 to DH scribed comment
(Noah speaking for himself) +1 Dave H. has it right, I think.
DH: Similarly for trying to do in/out over a one-way transport, though there I may have some work to do to address the response.
MM: Response from Dave Orchard?
DO: I question why two meps. From the WSDL I see "in only". For Request/optional response I know to wait for HTTP resonse. In WSDL 2.0 you have option of saying which MEP you're using.
<cferris> I think david hull expressed my thoughts effectively
DO: If if I've got a one way, why
wouldn't I want to use one MEP for both cases?
... The software you'll write will know what to do.
DH: Who's going to know?
DO: The binding.
DH: When I see that the WSDL operation is bound to HTTP I'll know to wait for the response because I see which binding I've got.
DO: So, you'd know in that case to wait for the response.
DH: How in this case would you know whether you can deal with the case where the response endpoint is anonymous.
GD: So, request/optional response is written to make the response appear truly optional
DO: Yes.
NM: So, a properly written binding to HTTP in particular would always send the response, even though the MEP didn't require it?
DO: yes.
NM: Very interesting.
GD: very interesting.
<cferris> takes over scribing temporarily
NM: I have summarized my general position at http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2006Jan/0035.html
<anish> Scribe: cferris
<noah> NM: which points to http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0165.html
NM: I assumed that when we said
request-optional-response that it meant that in the case of http
that it had to deal with knowing whether to wait for a response and
signaling on the wire that none is coming.
... Anyway, I propose we put aside question of how we document the
MEPs (simple or status quo), and first concentrate on which MEPs we
want.
... Still, although I do not think that refactoring of the
docmentation style is really what we were chartered to do, I will
not stand in the way and will work to ensure success if a majority
of the workgroup wants to redocument the MEPs.
... It seems that we have now come closer to an agreement that no
matter how you layer, you do have to send a HTTP-level response in
order to use the protocol correctly. You can't just close the
connection at either sender or receiver, without risking problems
with proxies (among other problems).
<GlenD> I will likely (unfortunately) have to leave in the next few minutes. If I don't get a chance to speak, I'd prefer that the ROR MEP mirror the optionality that actually exists in HTTP, rather than adding yet more layers of optionality.
<GlenD> In other words, ROR should mean there will always be SOMETHING that comes back, but it may not be SOAP.
NM: Hopes that the discussion we've
been having on the mailing list has demonstrated that violating the
underlying protocol not a good idea, and that one way and Req/Resp
are indeed fundamentally different in their correct use.
... References his note from this morning in response to Anish's
note (http://lists.w3.org/Archives/Public/xml-dist-app/2006Feb/0014.html
).
<GlenD> That, I believe, makes the abstraction easier to deal with and more accurate for the situation we really need it for. It correctly deals with the true REQ/RESP nature of HTTP (and other protocols potentially).
NM: When you send request out over
HTTP, under the covers it will be retried and you will get a
response. That causes lots more traffic than you'd get from true
fire and forget.
... It is modelled as an error in HTTP when a response is not
received
<GlenD> +1 to Noah, incidentally
NM: It's a mistake to build an
architecture that allows you not to send HTTP response in a
non-error case.
... Thus, the R/R mep we have presently mapes well to HTTP, tweak
that by making the envelope optional in the response, and we are
done IMO.
... Thinks also true in principle that if we want to support
datagram protocols, would be a good thing, and we'd need a true
one-way MEP fire/forget... not sure if needed to declare
success.
... Thinks David Hull had it exactly right as best I understand
it.
... Daveo is interested in a true req-opt-resp MEP, as I understand
him.
... Crucially, I'm trying to understand how the optionality of the
response is handled at the responding end when we're using
HTTP.
... Scenario: a message sent from client to server...we all agree
how that works so far.
... If we're using an API that models true FAF, then the receiving
application will never signal anything back to the binding. But, if
the same MEP is used to support an optional response, the
application might respond after all. How does the binding code know
whether to wait for the app to generate a response, or conversely
when to go ahead and send back a 202?
DO: you are receiving according to HTTP binding
NM: No.
... The whole point of MEPs was to abstract across all bindings.
The application is coded to an API that models the MEP, independent
of the binding. This is crucial; it was the motivation for
MEPs.
... If you have 2-3 separate bindings, you have a good change that
the app wouldn't need to know the difference.
... Importantly: >A binding that implements an MEP must
implement all the capabilities of the MEP. The binding can't know
in advance which features of the MEP a given application will
choose to use. If the MEP makes the response optional, then all
bindings must support both the case where a response is to be sent
and the case where no response is to be sent, and must allow the
application to choose (unless some other means of choosing is
provided.)
... all the oneway transports in the world should look the same
... So, all the req/resp would look the same.
... Doesn't see why we have to go to all this trouble.
... I do have some sympathy with wsdl problem, which is that you
want to be able to talk about "in only" without worrying about how
that's carried over bindings that may need a non-envelope response
to keep the plumbing happy.
... SOAP came first... if WSDL is having difficulty, maybe they
should change it.
... wsdl:input/wsdl:output should be all you need
DO: Really wants to respond but realizes there is a queue.
<Zakim> noah, you wanted to state general position
<Zakim> GlenD, you wanted to note that Req/OR seems nicer if it mirrors HTTP-type semantics (always at least protocol response).
<noah> CF: +1 to what Noah and David Hull said
CF: +1 noah and dave hull's thoughts
<scribe> scribenick: noah
NM: Note that Glen has dropped, but said in IRC "I gotta run. My apologies, folks. Sounds like Noah is pretty much championing my position,"
DH: We're dealing with cases where either there's always some resonse or one way
(not sure I'm scribing this right)
DH: I think Noah's and Dave's approaches are isomorphic, which is good news.
(Noah speaking for himself, is not convinced, for reasons he just stated.)
DH: We're disambiguating
syntactically when it's OK to reply to anonymous. With things like
HTTP it makes sense.
... If you don't then not.
... Likewise for waiting for response.
... The question is how you note it.
... I wanted to respond to Noah asking whether we need one way to
declare success.
... Speaking for myself, not officially for WSA, they voted (albeit
closely) to ask for a one way.
... I think it would be a shame not to do it.
... SOAP is inherently one way
... WSA builds well on one-way
<cferris> I am still unclear as to why ws-a wg feels they need a true oneway
DH: DaveO, you seem to feel that request-optionalResponse meets the need. If that's right, then I'm OK, because I just need to meet the use case.
DO: I think it's a description style issue, of whether there is one URI for all cases.
<dhull> chris: The need is to be able to use one-way messages as a building block, and secondarily to know whether anonymous will work
DO: As Noah points out, if you have
one URI for an uber MEP, then you need some sort of parameters to
determine which subcase you have, and whether e.g. a response needs
to be sent.
... Question is strongly vs. weakly typed MEPs.
<cferris> if true oneway, then seems to me that wsa:ReplyTo makes no sense anyway
<dhull> I believe language mavens prefer "latently typed" to "weakly typed" in this case
(Noah for self)I agree with Dave's characterization of strong and weak, but I "strongly" support strong typing. Otherwise, for a given binding, you are on a slippery slope as to which subcases to support.
<cferris> unless there's a "none" URI
<dhull> ? There *is* a "none" URI
DO: I think the multiple MEPs case is harder for WSDL
<cferris> yes, I thought as much
DO: Don't agree with Noah saying that because SOAP came first, we don't have to worry about WSDL.
<Zakim> anish, you wanted to respond to noah's comment
(Noah for self) Yeah, but I do want the SOAP story to stand on its own rigorously, and I don't think an uber MEP with a zillion parameters, some of which some bindings will support and some of which others will support is a good design.
<cferris> +1
AK: Not sure if what's on my mind is best talked about now.
<scribe> scribenick: cferris
NM: DO's characterization of strongly
vs weakly typed hits the nub of the issue
... at the extreem, we have the whole notion that has one URI and
every binding supports it to a varying degree
... e.g UDP binding supports req/resp but in a degraded manner
<dhull> +1 (this is the "cheese sandwich with no bread" argument)
NM: we should understand that the xmlp wg adopted the notion of MEP to describe what a binding would support
<anish> +1 to what noah just said. I don't think uber-MEPs are useful abstractions, as they pretty much allow anything (as Yves said in his email about request*/response*)
NM: when a binding supports an MEP,
it should support in its entirety
... any binding that supports oneway MEP will do it completely and
correctly.
... That means I am free in my application to use any feature of
the MEP, regardless of underlying transport.
... When we say the envelope is optional, I know that I can write
an application using an API that models that MEP and the binding
will be capable of handling that MEP.
... That is why I am strongly in favor of strngly typed MEPs.
DO: almost which way you are looking at the MEPs
<dhull> very happy to see understanding of sources of disagreement
<noah> DO: I'm starting to understand why we differ.
<noah> Noah agrees :-)
<scribe> scribenick: noah
DO: you're looking bottom up from the
bindings. You are looking for consistency across bindings that
supports that MEP. You get tranparency across bindings.
... I look at two MEPs, true fire and forget and SOAP Optional
Response the application will see that as a difference.
... I think that's bad.
... I therefore go the other way.
<scribe> scribenick: cferris
NM: The thing DO is missing, I think,
is that there is a level of this that you should not hide from
application.
... For example, there is a timing issue of telling binding when
you are done.
... I think it is a good thing that some level of software thet
DOES recognize when it is dealing with a certain MEP like req/resp
so that it can tell the binding with certainty when it is done.
... To meet your (DO's) need, it is a matter of mapping to wsdl
in/out pattern.
... I think you can write a wrapper API that maps to the WSDL
patterns such as in-only, and calls a lower level API that knows
the differences in the SOAP MEPs.
... I'm wondering if the right way to layer this is to make APIs
that match the WSDL
... it gives them the control to do what the binding expects
CF: I think that the wsdl binding to soap mep is broken
<scribe> scribenick: noah
Chris: is that last statement your personal position or an attempt to scribe me
<Zakim> noah, you wanted to talk advocate strongly typed MEPs and to talk about timing issues, which is what I think Dave O loses
CF: I think the whole notion of WSDL
trying to describe a SOAP MEP is broken. I've said that for a long
time and I still believe it.
... The purpose of the SOAP MEP is to "inform" the binding. It's
not up at the application layer where WSDL is.
... Especially when you add in something like addressing, it makes
a mess if you throw in anonymous ReplyTo: URIs and then try to pick
a SOAP MEP, then you get trouble.
<dhull> +1
<Yves> if you use ws-addressing, you know at the app layer what you are doing, so you select the right MEP...
CF: I've gradually come to believe we need to keep MEPs as they are
AK: +1 to what Chris said, and also
+1 to Noah saying that uber MEPs not that useful
... I'm still not sure what Noah's saying about fire and forget
... We've added layers on top of the core internet that simulate
FAF or req/resp
... there is nothing wrong with creating an abstraction in
MEPs.
... they can be implemented on multiple transports.
... we can create a SOAP one-way MEP and create an HTTP binding for
it.
... even though it's one way it will work.
Noah notes that his concern is not with the one-way-ness, it's with the fire and forget aspect.
AK: I don't see anything wrong with
it.
... Up to know our MEPs have focussed on transporty type
things.
... You don't have to design them for particular transports
<dhull> but if you try to bind req-rep over UDP, you can do it, but you'll have an impedance mismatch (a.k.a. "leak")
<Yves> even at the http level you have a leak
<dhull> what kind of leak, and when?
<Yves> when the tcp connection goes down
<cferris> then, it is a failure as Noah described earier
<dhull> failure is part of *every* MEP (even F&F over UDP)
AK: API-level argument is weak in multiple threads case
<cferris> +1
<Yves> well if you were in the one way case, maybe, or maybe not
<dhull> +1 to what?
<cferris> your failure is part...
<dhull> if I try to send UDP to example.com, it will fail
<dhull> (at least in a decent impl)
<cferris> yves, in the case of true oneway mep, then a communications failure would only be on the inability to open a socket
<cferris> in ALL cases
<cferris> which is why it would be a bad idea to run a true oneway mep over a req/resp protocol like http
<Yves> you can do a one way by sending a pointer in a shared mem region :)
<dhull> who's scribing?
<cferris> oops!
<scribe> scribenick: cferris
NOTE: we may have a hole in the minutes here. NM was speaking.
<Yves> "true" one way is one way with the additional property that you don't have an ack
NM: I have less trouble saying we can
do oneway over HTTP than we can do FAF
... an omniscient obsever would note the wait until the far end has
done something
... in a true FAF, the binding does not depend on any action on the
part of the receiver
... we need to be very careful with them
AK: seems like we are actually quite close
NM: the long thread I started was not
about oneway but about FAF
... ultimately there is an obligation on the part of the sender at
least on the part of the sender
AK: don't think we should have FAF at all
<scribe> scribenick: noah
AK: I don't think we should have a FAF MEP, maybe we should have a oneway MEP
<cferris> NM: has to do with whether the respnder is involved
DH: Timing is tricky to talk about
NM: the question is whether ther responder is involved.
DH: right.
<cferris> MM: action on one of the three to frame conscisely
<cferris> NM: difference between oneway and faf
<cferris> AK: anyone actually advocating for a faf?
AK: Is anyone advocating a fire and forget MEP
<cferris> DH: yes, me
DH: Yes.
<scribe> ACTION: Dave Hull to frame discussion of fire and forget vs. one way MEP [recorded in http://www.w3.org/2006/02/08-xmlprotocol-minutes.html#action02]
CF: Nothing to add
MM: good discussion
MM: We'll put off URI for SOAP MEPS and the XOP issue until next week.
CF: Possible regrets for next week
MM: adjourned