Minutes of Transport Binding Task Force, 5 October 2001.


Initial Agenda

Review HTTP Binding submitted by Stuart, Oisin and Marc (if I forgot
someone, I apologize)
Each member to state:
How the document succeeds? (+)
What it lacks? (-)

(+) Good start, adds to the Noah, Glen, Highland document
(-) Work needs to be done for the responding node, see Glen's email for

Marc H
(+) Clearly plugs into framework, reads like a framework

(+) Generally happy with this binding
(-) Binding rules out Get (vs Post), see email

(+) Ready to present to the world
(-) Concerned about complexity.  How do you measure conformance, what
conformance rules are to be followed.

(+) Liked it, this activity forced us to identify level of completeness,
helped to identify gaps
(-) URI long names add to complexity

(+)  Good start, stronger tie to framework, good discussion on error codes
and expected behavior.
(-) Let's not forget core framework document and the need to complete it.

Good start.

(+) Likes the approach.
(-) Security should be separate.

(+) Clear agreement on the approach.
(-) General concerns about complexity.

Question to the group: Can we agree to move forward, assuming the issues of
complexity?  Group agreed.  The TBTF will provide something to the WG next

What needs to be changed prior to the wider WG publication:

1 Framework narrative at the beginning
2 MEP desc of single request/response
3 Noah's feedback - clean up the document's presentation.
Glen - add caveats - this document currently is not being prescriptive
4 long names for uri - use of queue names and schema types


URI issue from Noah - Is a change but not sure what Noah means.  Agrees
long names should change.

Stuart - Plans on:

Doing some global, presentation edits
Complete the binding description
State machine description - needs to match up with existing spec - check
errors in detail


Question to Glen - You are in favor of this approach but have concerns?

Glen's answer -check email sent out prior to TBTF:
Some subtle points have come up - We need to be kind to people reading spec
and distill this approach with their world of implementation.

We want to make sure this description reads like an implementation
description but point out that this is an abstract representation of an
implementation. - We need examples to explicitly show that the properties
are  not intended to be literally implemented.

Let's try to simplify the document which is a bit daunting.

Chris Ferris joined the call.

Yves - Would also like more examples.

David - Question for Henrik: How can we make it less complex?

Best thing to do is to go out to the world and publish what we have.  It
would be good to put a stake in the ground and go forward.
We need to deal with the issue of conformance requirements.  What are they?
How do we verify correctness?

We need more examples to call out the difference between the abstract vs.
possible conformant implementations.

Initial reaction ?

Chris Ferris
(+)  Generally step in right direction
(-) Agree with Glen's comments
State machine aspect may need to be put off in an appendix - to simplify.

Noah - Agrees with Chris

State machines are needed and rigor is needed, make this accessible and
intimidating.  Simplify by improving presentation - diagrams, etc.
URI's values should be changed to XSD Boolean vs. URI value

Chris - Don't remove essence of state machine. - Perhaps narrative approach
with the tabular rep in the appendix.

David - Limit complexity, pass off task to the authors, then thrash out
details in tf.

Noah - 3 aspects to limiting complexity
Property names
Type system
What do values look like?

Long names in values - example true vs p:true
Expanded name means uri comma local part -- Type name out of XSD, we can do
our own enumerations

Stuart - Happy to go that route but need help from Noah
Marc - Yes can Noah help in the expression since he has the experience in
this realm.

Noah - He can work on this Tues - XSD is not that tough, just read primer.

Marc - He is not sure what is the request
Noah - We have props whose values are uri's ----- Would rather see type is
enum with xsi w3c/lsl/xsd/request-response/roletype....

Stuart - We can do this
Noah - I plan to  work with them on Tues

David -  publishing to external world has some issues..

1) Currently overall reaction is going to be about its complexity
Suggestion: Let's make changes prior to publishing  + 1 from most of the
date would be....

Glen Will help over weekend, to carve out a chunk of the updates...

Noah - Work needs to be done is presentation , layout, diagrams, types,
general framing text for readers;  is that what Glen plans on doing

Stuart - OK with that

Glen - We should have a TBTF partial review over email - Tues afternoon
prior to WG call.

David = Everyone should vote end of day Tuesday then send it out to dist

Stuart - We already sent it out to the world.

Noah - Discussion to WG explaining plan prior to call highlighting our
current release, query for comments on present form -

David - Not sure about WG agenda
Noah - option open to query for comments

David - He will think about this.  Not sure about an agenda item for
Wednesday, querying for comments, etc.

Glen - It's a good idea to highlight group of the TBTF's progress.

David - Should this be on the WG agenda Wed?

Stuart - Exposing our plan is good

Noah - To plan we need to start working backwards - When does this need to
be done?

David - We go to Last Call ftf last week of Nov - 6 weeks

Noah - Then it should be on the agenda for Wed, we  need to speed up our

David =  The larger tasks for the TBTF are:
1 - What is conformance to the framework?
2 - What do we need to do for the framework document?
3 - Complete the MEP description.

Conformance Issue

Noah - dropping off
Chris = dropping off - one thing is that the discussion of serialization
does not talk about infoset

Noah - Regarding conformance - Lot's of issues - Analogy - TCPIP is a good
comparison - Could be unix or windows , Spec can say please tell me the
stream you are sending, and the packets would be made known  and the stream
can be reconstructed

David - Do we need a statement on conformance?

Noah - Overall - if we get this right on SOAP or at the framework level, as
long as we say the right things to put the information on the wire.

Chris - May help w/ mep or framework or binding. Not sure if he can commit
to time next week.

Stuart - Will work with Chris

Stuart - Revised version of framework - Thursday work with Chris

Chris - MEP document had fragments of information regarding the framework

Stuart - MEP has a description of the framework - bag o bits - information
can be useful to framework updates, number of sources to draw on

Working group's priority is to complete the binding and update the

David - Work items have been determined
Back to conformance...

Glen - General question over our heads - no specific direction
Marc - Tricky, binding itself needs to specify wire format for compliance,
this is a difficult question with current framework since we are not
mandating anything
Glen - Totally agree, you can do anything you want, there is not a way to
verify conformance because we don't specify any implementation details

Stuart - Binding 1.1 or 1.2 conformance is a problem, typically tcp/ip rfc
does not call out conformance
one wants to call out conformance requirements via spec, statemachine is

Henrik - We have attributes with types and names in implementations, how
I figure out state etc

Glen - That is a fine line to walk. You don't have an exact way to do that,
api will virtually provide info idling the requester

Henrik - We don't know what a request means

Glen - To pick any piece of this thing, that prop may never have a rep in
bits - so no conformance
feature are described.

Glen - This framework could be useful for more than just binding specific
stuff. - As blocks with an envelope infoset
SOAP RP this works over HTTP, TCP etc - can that be factored out and spec'd
in a property representation

Next call will be Friday, Oct 12 - Some deliverables Tues and Thursday -
Stuart to set up call.