Minutes of Transport Binding Task Force, 31 January 2002.


Updated Action item list

ALL look through 'discussion' issues (33 57 50 178) and volunteer to
    resolve one or more
DF 165 133 on WG agenda.
CF to write proposal for 178.
SW to write resolution text for 133 by CoB monday BST.

Status of Email/SMTP binding

-- One-way MEP (see point 5 in "Intro and review attached SMTP w/ MDN
   Binding" of [1]).
Subteam notes this is outside their purview, it is dependent on 179 issue

Assign owners to the TBTF work items

NM notes this binding uses HTTP in a particular manner, especially in its
use of POST. It is possible to create bindings that would do otherwise. We
also note that the particular use of even GET is problematic. In principle
one would use GET for a "get stock quote" but if you wanted to track the
number of requests for stock quotes, a POST would be more appropriate. HFN
suggests we use another example other than getstockquote. TBTF will start
with a "no-change spec" approach. SW will propose resolution text by COB
monday BST.

NM proposes to signal agreement with Charter discussion. TBTF unanimously
agreed. He will write resolution text by EOW.

Issue related to end-to-end features, and related mechanisms that can
signal faults e.g. if an intermediate cannot pass along a message.
Glen - end to end feature should be in the envelope not in the transport,
mU on a header
Noah - example of concern - 2 diff features, both are MEP features, rr
(request-response), one being rapid rr mep gives time bound rr to process a
po over smtp, different feature/mep; http can participate in both multi
hop, in principle; contrast http binding feature with longer wait time;
this shows that you really want the binding to have some knowledge of mep
and other issues
Glen - descision made at binding, does not like app level contracts for
intermediary feature interaction
Noah - where does message path come from
Glen - mep's abstactly, there may be constaints on hop by hop
Chris - end to end features should be hdrs, but agrees with Noah that they
could be expressed in a binding; all we need to adress is that end to end
features could be expressed in a binding but that would imply some
explaination of intermediary behavior
Noah - state created by est of message could be used in transfering
message, so if I am writing binding spec, I can say following state is
and that an intermediary - hop count prop (property) - is to be incremented
-- 2 bindings one inbound one out bound, and some rules for the hand off
nodes hold the hop count
Glen - props set but in another spec it specifies the actions on those
Noah - feature spec - inbound - one more than what was sent, hop count -
bindings have no mU construct - no place to mandate what a node does\
HFN - when writing a binding, with a notion of mqseries, etc, which
provides a framework to mandate stuff, but we can't mandate soap processing
rules on
Noah - that is what i meant; 3rd place to put things - additional work, not
triggered by header the node must state that it processes a feature
Stuart - feature has to say how it is handled on an intermediary
Noah - logic can be done somewhere at the node, 3 places:1) contract at
inbound binding 2) outbound binding 3) inbetween - in logic that the node
knows how to handle independent of bindings and soap rules
Glen - rr mep - scenario - intermediary - outbound mqseries inbound HTTP -
mep keeps state at first hop
Noah - if this is dealt with in the env, the node is involved, but is we
want node to be involved outside of env, then has problem having node being
DF - propose discussion for another 5 to 10 minutes and then move onto
issues 102 and 103
HFN - we won't be able to solve in 20 minutes, maybe we should get names on
issues first - issues are gateway related - this is difficult stuff these
discussions will continue as bindings are created
Glen - current compromise precludes a specific scheme of op - we are
explicitly stating that features be stated in the binding end to end
feature can not be writen in a binding
Noah - no, this can be cleared up in the feature spec
Glen - intermediaries can be programed just to pass http msg to mqseries
and hold session open
Noah - more that 2 node involved, then each node must sign up to honor a
feature spec
chris - if a node implements a spec binding -- and a binding supports a
feature then the node supports that feature we should make a recommendation
that end to end features be expressed by soap hdrs, caution features spec'd
outside env; tbf has not dealt with end to end features and this is good
Noah - close to what noah proposed with a warning, it is possible for such
props as part of state used by outbound binding to relay a mesage, outside
the env with warning - but is it possible to talk about state outside the
env, should features state behavior at the intermediary, but we discourage
Chris - the prop are available but soap does not provide mode for
intermediary behavior
ChrisF to write a proposal.


Discussed Stuart's proposed text, and unanimously agreed to the following
modified version:
"The information transmitted from node to node, and in the case of MEPs,
any requirements to generate additional messages (such as responses to
requests in a request/response MEP) rules for the delivery or other
disposition of SOAP faults generated during the operation of the MEP."

Other Issues

Issue 103 needs to be postponed - Marc posted something but it deals with
other issues.
Issue 57 - Chris raised this, but ran out of time.

Decide date of next TBTF telcon

Tuesday 5 feb, 730-830a PST.
[1] http://www.w3.org/2000/xp/Group/2/01/23-tbtf