Present: Roger, David, Doug, Hugo, Mike_Mahan, Zulah, Daniel, Eric, Paul
Regrets: Chris, Ugo
Chair: Mike Champion
Scribe: Mike
Scribe: Champion
... Date: 21 Aug 2003
Scribe: CONSENSUS: We can live with the proposed definition, but let's discuss tweaks to clarify "request/response" in light of various comments.
SeveralPeople: Let's distinguish between synch/asynch at the protocol level and at the SOAP/WSDL/user level. For example, email is usually considered "asynchronous" but SMTP is a request/response protocol.
David: Proposed defintion
Scribe: [["An interaction is said to be asynchronous when the
associated messages are chronologically and procedurally decoupled. For
example, in a request-response interaction, the client agent can process the
response at some indeterminate point in the future when its existence is
discovered, for example, by polling, notification by receipt of another
message, etc. An interaction is said to be synchronous when the participating
agents must be available to receive and process the associated messages from
the time the interaction is initiated until all messages are actually
received or some failure condition is determined. The exact meaning of
"available to receive the message" depends on the characteristics of the
participating agents (including the transfer protocol it uses); it may, but
does not necessarily, imply tight time synchronization, blocking a thread,
etc."
... ]]
... ACTION: Hugo will update the glossary with the proposed text and bring it
to the WG's attention
PaulD: Wishes to change "client agent" to "requester"
Scribe: ACTION: MikeC will ast the WG to revisit the client/server requester/provider consumer/supplier terminology issue
David: This was not an oversight, we wanted to avoid the QName vs URI rathole.
Roger: Sanjiva posted a good explanation of why this isn't as bad a rathole as we thought.
Scribe: CONSENSUS: We can discuss the URI issue without re-opening
the ur-Troutpond
... ACTION: Mike will respond with our explanation for removing URI.
... ACTION: Roger will harvest Sanjiva's explanation for the architecture
document.
David: Have editorial suggestions and will send them to the list
Scribe: ACTION: Daniel will present the proposed project plan to
the working group soon.
... ACTION: People should check to see that anything they sent to our list is
in the archive; if not, resend.
... ACTION: MikeC will put Hao's proposed reliable messaging text on the next
telcon agenda
... (adjourn)