XMLP Working Group Transport Binding Task Force Teleconference: 26 July 2001, 2pm-4pm EDT



much discussion regarding selection of location for f2f. East coast location was least offensive to most. Boston, probably MIT Aug 2 or 3 is most likely choice. TF to work out details via email in next couple of days.

David: let's set the agenda as:

Highland: need a definition, go through proposal and select which parts are binding and which are application?

Outline for what we're calling a binding:

Highland: MEP - Message Exchange Patterns Supported

all: yes

Glen: binding may support some MEP but others might be possible

Highland: Referenced Protocol Specification Documents (RFC's, etc)

MarkN: How you can combine bindings

Glen: binding is just an encapsulation? do we believe an encapsulation is a binding or something different

Hugo: If it is just encapsulation, you define that. If it is transport, you define that and identify encapsulation.

David: that's still a TBD

Highland: Compression

david: that's not in the charter

Highland: Security?

David: not in our charter

Highland: Reliable Messaging

Highland: Error Reporting and Handling

Glen: can't do this until we specify routing

Highland: Message Correlation, is it in or out

MarkN: all of this gets into whether your characterizing a transport or not. Do we characterize correlation as normative or non normative. Have we decided this yet?

David: we haven't decided that yet. if you're going to do request/response you must have correlation. Therefore, correlation must be core.

Marc: only if we want to support that MEP over a transport that doesn't provide it

Glen: it might make more sense in a general way to express in the binding anything you want as custom and refer to in the binding the facets that are named and say this is how thius binding achieves this functionality

Marc: agrees... there is a space where you talk about correlation where transport doesn't natively support request/response

Glen: agrees, but if there's a defined normative definition for an MEP... binding supplies virtual information for these facets

David: keep in mind that this list is for the abstraction not the instance of...

Glen: yes... If you do UDP, you might just do oneway and not discuss correlation

David: how do we divide things up between core and extensions? outline of where the peices go... Would help WG as a whole. Next weeks call we will be discussing the possible split between core and extensions like RPC and encoding...

Highland: this refers to what I found under the ebXML example... may be too detailed or concrete.

Chris: provides rationale for what ebXML team did

Mark: I disagree

Chris: discusses http headers

Glen: if I want to write the orange juice cans with string...

MarkN: SOAPAction, definitely need to specify


Glen: wonderful world where interoperation is achieved without apriori knowledge... gotta be a way for getting the contract communicated that we should discuss.

Chris: right, that was direction I was taking my proposal

Highland: do we need more discussion? do we have a section that...

David: not quite clear... issues one with regards to "normativeness". thought we were on track to give each a particular name. If you use that named binding, you MUST ... Whether you have to use THAT binding is not stated, we might recommend that it be used

MarkN: can be multiple bindins for any underlying protocol

Highland: for each we decide to...

Glen: if you decide to use SMTP at all then you use a specific binding can be normative SMTP binding, but that is no guarantee that any node speaking SMTP uses/supports that binding.

MarkN: need to say here's the bindins I'm using

david: we will do the "obvious one"

MarkN: hopefully, all other HTTP bindings would be special case ones

Marc: yes, if someone comes up with something better, that's fine

Highland: are we going to cover it in those definitions?

David: more general description of a binding... we keep switching between those two

Glen: more comfortable with abstract definition of what a binding template looks like, shouldn't necessarily call out everything

David: for each of these headers, should there be something in the template? also answer second question as to whcih instances of a binding they might apply?

Highland: start over?

Glen: what exactly is a binding? a binding is something you hand a message to... all this information is in the infoset of the binding (who, what, where, etc...) it does some abstract thing for you...
a binding also includes concepts of message correlation, etc. if that's also part of what a

MarkJ: sent this out in a note... when you have encapsulation layers... we sometimes call these bindings as well. need to give a name to the thing that is taking responsibility as a whole... we sometimes take binding to mean "transport" binding

Glen: not sure you need to

MarkJ: may be different strategies even with same transport binding...

Glen: everything in infoset of message in box. moves to transport binding how this is implemented, virtually binding spits out serialization on the wire...

MarkJ: there might be other things... something needs to be in control to a compatible set of features.

Glen: that is out of scope for us. design a framework to describe these features so people can write code that does it

MarkJ: concerned that we are clear about what that thing is. It may only be given a portion of the infoset

Stuart: sorry, I messed up on the hour, have I missed much?

Glen: catches Stuart up

David: can we resummarize?

MarkJ: message infoset... all knowledge that process has binding is a mapping of a subset of this information

Chris: says a bunch of stuff that he can't recall after the fact

Glen: i'm thinking of a pull model that you dump the entire infoset to something you drop a message and the binding pulls what it needs and passes on to the next set up chain of handlers...

MarkJ: who's targetting these peices of information? seems like a very deterministic thing like a pipelining model

Glen: talks about how correlation might work

Highland: are we talking about the characterization of data that is in this infoset?

Glen: infoset like big hashtable, these semantics tied to this data...

MarkJ: uncomfortable with characterizing as infoset, prefers metadata

Highland: yes

David: regardless of whether we characterize as infoset, the issue is how we specify what behavious apply to that information

MarkJ: some rendition of infoset

MarkN: traditionally protocols have metadata

Glen: considers correlation... this is the XML block that does this...

Chris: says a bunch of stuff that he can't recall

Glen: what I do is specify in my spec... this provides the semantics of the normative correlation id in this way. (this jives with what I said above)

MarkN: these things shouldn't be expressed by us


Highland: what we've been doing has been useful?

all: yes

David: we started out looking at a concrete instance of a binding and then abstract up from there. we started that path using Highland's model. I wonder if we shouldn't try to have a proposal for the abstraction. Should we do this?

all: yes

David: like the idea of metadata, prefers expression as infoset 'cuz he's an XML guy... really like to see that structure in more detail to help him evaluate these conversations.

Chris: agrees.

Glen: (after coaxing) I could do that. email I sent out starts (sort of) down this path.

MarkN: are we having another call?

David: yes

MarkJ: I have to go soon

David: next call will be (drumroll...) how 'bout Monday?

all: that's fine

David: RPC call Monday at 8 pacific, Stuart, can you arrange call?

Stuart: yes

david: need to get an abstract together, glen can you get it out by friday?

Glen: Monday, but not by Friday

David: like to see abstraction and instance of a binding

MarkN: will it include status codes, ports, etc?

David: at some point we're going to have to bite the bullet on these

some discussion regarding getting rid of SOAPAction... much agreement

Marc: I thought we had come to an agreement already

David: there are two who strongly oppose and are threatening a minority opinion which is unfortunate

MarkN: withhold food at next f2f until a decision is reached/agreed

Highland: one option was to tighten up the spec

MarkN: ietf opposition SOAPAction considered harmful

Chris: have two HTTP bindings and let people choose which they want to use

David: that's an interesting proposal
what we could do is define an HTTP binding that doesn't have SOAPAction and that is not to say that someone else could define on that did. You can have two that have SOAPaction with different semantics and you have built-in interop problem...

Highland: I'll keep that reasoning in mind

Stuart: would like to see it derivable from envelope. would be more concrete if defined in a similar way.

david: we've not been able to define what it is

Chris: says some profound stuff

MarkN: agrees completely

Marc: also agrees

David: also agrees, minor qualification... different people have different needs, given a bucket which has multiple meanings and they put stuff in it to serve their needs.

MarkN: right, URI and content-type

David: Highland, please have talk with Randy

Highland: yes, I will

david: back to the meeting after that useful diversion so, we didn't get any other offers to draft the abstraction, glen, can you come up with something for monday?

Mark, I'm certainly going to comment...

David: proposed agenda:
1) discuss Glen's abstraction cum binding architecture

Glen: a binding is something that does this... and I'll write a paragraph... I'll give it more thought...

MarkN: will this land in the specification or the AM?

David: we still need to work out how we bring the AM forward

Marc: also need to deal with John Ibbotson's email about splitting up the spec: core/extensions

Glen: I think that's cool

David: yes, there's much agreement on this on the list

Stuart: I thought we were making good progress on SOAPAction...

Glen: I've been thinking about how this all fits with RDF. Some good potential with how this all fits with Semantic Web...

David: I think we're done for today

Hugo: Stuart, I found a bridge, you don't need to set it up

Stuart: great