Attendees
- Henrik Frystyk Nielsen
- Mark Nottingham
- Highland Mary Mountain (chair / scribe)
- Stuart Williams
- David Fallside
- Glen Daniels
- Marc Hadley
- Hugo Haas
- Yves Lafon
- Mark Jones
- Chris Ferris
- Noah Mendelsohn
- Stuart Williams
Minutes
Review of First Cut
Stuart, Noah and Hugo provided email feedback to First Cut.
Henrik provided a properties analysis of HTTP, SMTP and TCP.
?.destination - There may be a need to have 2 uri properties,
one determining the binding spec, the other being the messaging
endpoint. Binding should be known to the sending node.
SOAP.ENV will allow users of ebXML and WSDL constructs to
communicate transaction choreography and application orchestration
within the envelope template, while the SOAP binding addresses
message transport concerns.
Henrik - Atom should not be thought of as the MEP but should be
derived from the Application.
Glen - A primer will be needed.
Noah - We do not want to design API's
There was no objection to the First Cut direction. There is a
large amount of work ahead to resolve the open issues and pull
together a spec to share with the larger WG. Not sure if we will be
ready by the Face to Face in Sept.
Open Issues:
- ISSUE 1: What is the structure of property names? URIs, short
names, etc? This structure needs to be defined early.
- ISSUE 2: Should the app provide a "template" envelope which
potentially gets modified by pieces of the SOAP system
(extensions,bindings), or a more abstract set of stuff which gets
built into an actual SOAP envelope only at a very late stage in the
processing (typically right before engaging the wire).
- ISSUE 3: If the application is handing down pieces of XML into
the "engine", we need to deal with potential conflicts with
prefixes/ids/etc. - this can get hairy. We need to decide how much
latitude the app has over this stuff. This arises at least for
headers + bodies, and is a potential problem regardless of whether
the app hands a "complete" (to some degree) envelope to the SOAP
processor or just fragments.
- ISSUE 4: No firm resolution to correlation/extensions, more
discussion is needed. Correlation and the utility/wisdom of
expressing a canonical XML serialization + rules for a generic
req/resp extension as opposed to just leaving this up to the
binding.
Protocols may have inherent(natural) ways to represent correlation
while others may not. These natural methods may serve one MEP, and
not another. We need to optimize the general cases, while guiding
the user toward extensions for "unnatural" correlation
scenarios.
- ISSUE 5(new): MEP Abstraction - Where does this prose/activity
belong? How are protocol properties folded into MEP's?
Next Steps
- TF Status to WG Wednesday, August 15 (Noah)
- TF emails distributed to dist-app (Hugo)
- Produce Request/Response HTTP/SMTP/TCP Sample Bindings
(schematics) by Friday, Aug 17 - Keep issues in mind while working
Samples
- Henrik - HTTP, TCP
- Highland - SMTP - using Henrik's Protocol Analysis
- Address Issues
- MEP Abstraction Prose/Structure
- Specific protocol instances and develop intermediary
scenarios
It is not clear who will do the lion's share of this work. It
could be the TF members or a group working in parallel.
Next meeting August 17, 11 EST/8 PST. David to set up this
call.