Attendees

hugo haas

glen daniels

david fallside

yves lafon

highland mountain

mark jones

chris ferris

marc hadley

mark nottingham

stuart williams

Minutes

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's proposal

Chris' proposal

MEPs

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?