F2F on Thursday 2nd. Video conference facilities tested by Hugo. 4 way video conference: Akamai San Mateo, MS Redmond, IBM San Jose, MIT Boston. Probably 8 attendees. Try for 8am PST - 4pm PST.
Glen’s Proposal
David: Glen, please review what was in the proposal
Glen: Current view of model: big bag of info, using term infoset at the moment – this is a point of discussion. Data is contents of envelope and metadata about bindings (facets) like MEP etc. Key thing is that some stuff might get serialised, some not – might just be hints for pieces of code to do certain things.
Binding can be viewed as chunk of stuff that does something. Moving info from point to point, transforming message (encapsulation binding). Binding takes abstract data set and serialises some of it over a wire to a peer. Up to binding how this happens, e.g. serialise to XML. Some binding may not serialise all info, e.g. correlation ID may be implicit in binding.
Question: how to deal with intermediaries and multi-hop message routes. Binding is something we give a name to. It has private facets (protocol specific), public facets (how it relates to externally defined facets like MEP, security, …).
Highland: Need definition of extension.
Glen: Between abstract model and discussion on dist-app, have a good idea about what an extension is.
Stuart: Thinks most of us do, bit fuzzy about behavioural aspects of extension compared to syntactical.
Glen: Agree, but have to walk that tightrope because we don’t talk about implementation.
Stuart: Ways to specify behaviour without talking about implementation
Chris: Difficult because extensions must work within the SOAP processing model whilst some extensions seem to break that.
Marc: An example ?
Chris: ?
Glen: What do you mean by break the SOAP processing model ? Description of how extension mechanism works. Some extensions may be very hard to implement, e.g. ordering extension.
Chris: May not be able to build an extension on top of existing SOAP processor.
Glen: That’s true but may be OK.
Chris: But what about interoperability.
Glen: Interop comes with adoption.
David: would like to back up to synopsis.
Glen: way to go from here – ask if everyone thinks this is the way to go.
Chris: Agree in general, struggle with swallowing of stuff in abstract infoset, can this be applied generally. E.g. correlation through intermediaries. Not sure that binding should take stuff out of envelope.
Discussion of methods for supporting multihop.
Glen: would be nice to emulate what current SOAP has, e.g. implicit correlation.
Mark N: What is message exchange pattern?
Glen: 2, underlying protocol pattern and SOAP pattern built on top of that.
David: Want to define framework and put enough things in framework to convince us that framework is sound but don’t want to describe every possible instantiation of every facet in every binding.
Noah joins the call.
Glen: define positive space, not negative space.
David: how much do we need to describe to convince us that framework is sound.
Mark N: For me binding should hide nastiness of transport, this approach seems to punch a hole in that.
Glen: Not suggesting that we define normative “blocks” for every facet like MEPs. Ie. Not everything we are talking about can be represented in the SOAP envelope.
Noah: reminds me of discussion we had months ago. One can talk in the abstract not only of envelope infoset, but also information agreed upon by applications using our facilities, e.g. MEP. This info could be represented in XML but this might not be necessary or desirable. If you are using a transport that implicitly “knows” the return address then it might not be necessary to include this information in the serialised form of the message.
Glen: You can think about doing cool things if the information is in XML form: transformations, RDF related stuff, …
Noah: Need clear terminology to distinguish between the two types of info.
Chris: Also need to think about binary attachments travelling with the message.
Noah: Yes, these aren’t best represented as XML infoset.
Noah: Original info as XML: transformations OK, binary attachments not. Abstract labelled properties, not necessarily XML infoset. Discussion around the above.
Stuart: Noah’s comments tie in with my concerns. Abstract information, lexical representation not that important.
David: When we define binding for HTTP for Req/Res how would this look in the proposed dual representation
Glen: Abstract data item that says this is req/res. That being there implies another abstract data item: correlation id. That item has an infoset representation. Binding may choose to take the correlation ID and serialise that in the envelope or it may choose to use implicit representation.
Noah: If there’s anything that any binding may need the app will supply that ? Potentially burdensome…
Chris: Lets try security. Digitally sign a message. App is free to construct envelope and put signature in there. Alternatively the binding may do that for me, app just supplies private key.
Noah: We will identify abstractly information items that a binding relies on and those that may optionally be supplied to enable some functionality.
Chris: E.g. correlation ID, can be app supplied or may be defaulted by binding.
David: Sounds like we are reaching some agreement here. Would like to see some text that describes this that can be put in spec. If we can have a draft by Thursday then we can work on it then. Do we have enough information to do that.
Noah: the info needed to send a message as well as the info available when receiving as message is modelled abstractly as a set of named typed properties some of which may be representable as standard XML infoset entries. Some such info will be mandatory for all bindings. Specifications for particular bindings and message exchange patterns can require additional such properties and can provide additionally for properties that are optional.
Discussion around nested bindings and mix-ins. Is everything a binding ?
Glen: coming to view that a binding isn’t different to an extension.
Noah: but all extensions are not bindings. Bindings are related to moving a message from one place to another a message exchange pattern. Bindings are a specification for how a message moves from node to node. A binding is a specification for the way messages are moved from node to node using a particular underlying means (protocol).
David: coming to end of time. Need to discuss agenda for Thursday F2F.
Marc: Can we arrange a conference call so those who can’t attend can check progress during the day.
David: Marc, Stuart, Hugo, Chris to organise a bridge via mail.
Stuart: Some parts of this discussion resonate with the contents of the abstract model.
Glen to generate pre-meeting reading list.
Stuart to post pointers to links between discussion and abstract model.
David’s phone dies…
Glen: what is goal for Thursday ?
David: candidate for abstract framework and example of applying framework to e.g. HTTP and/or SMTP
Glen: also valuable to play with framework and explore some of the facets that have arisen, e.g. MEPs.
Discussion around MEPs