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
Chris:
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
silence
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
adjourned