W3C home > Mailing lists > Public > xml-dist-app@w3.org > January 2002

RE: Resolving the Ed Note in Part 1 section 5.1 (was New Issues)

From: <noah_mendelsohn@us.ibm.com>
Date: Mon, 28 Jan 2002 18:58:44 -0500
To: skw@hplb.hpl.hp.com
Cc: "'Henrik Frystyk Nielsen'" <henrikn@microsoft.com>, "Williams, Stuart" <skw@hplb.hpl.hp.com>, xml-dist-app <xml-dist-app@w3c.org>
Message-ID: <OF3B426DA4.D77321D7-ON85256B4F.0082F431@lotus.com>
I think we're close to agreeing on most of the significant points, and we 
can probably work out the rest on the call tomorrow (unfortunately, I am 
booked tomorrow AM US time ahead of the call.)  Anyway, here are a few 

Stuart Williams writes:

>> Hi Noah,
>> In terms of the proposal at the end I have a couple of comments, but 
>> mostly... "can live with".
Good, that's very encouraging, thanks.  I view the proposal as a 
compromise, and I certainly feel no better than "can live with" about some 
of it.

>> In terms of the discussion that precedes the proposal I have some
>> thoughts/comments that probably continue to highlight differences in 
the way
>> we are thinking.
>> > -----Original Message-----
>> > From: Noah Mendelsohn [mailto:noah_mendelsohn@us.ibm.com]
>> > Sent: 26 January 2002 01:58
>> > To: skw@hplb.hpl.hp.com
>> > Cc: 'Henrik Frystyk Nielsen'; Noah Mendelsohn; xml-dist-app
>> > Subject: RE: Resolving the Ed Note in Part 1 section 5.1 (was New
>> > Issues)
>> >
>> >
>> > On today's call, I suggested that I might have a compromise proposal 
>> > would be a reasonable middle ground between those who believe that
>> > bindings shouldn't mess with the envelope, and those who don't want 
>> > same feature (e.g. reliable delivery) to appear incompatibly to
>> > applications depending on whether the binding does or doesn't choose 
>> > help provide the implementation.  Most of what Stuart has proposed 
>> > wording, as corrected by Mark Baker, survives.  The highlights of the
>> > proposal are:
Oops.  I thought I got that out.  I had thought that your original wording 
was surviving, but I actually just rewrote from scratch.  See "proposed 
text"  (I know you didn't catch this, but thought I should point it out 

>> >
>> > Architectural Highlights
>> > ------------------------
>> >
>> > * Stick with the prohibition on bindings changing the envelope 
>> > Bindings are required to deliver the infoset intact to the next node 
>> > we've previously agreed, the actual wire formats used to achieve this 
>> > completely up to the binding, and opaque to the outside.)
>> Ok... personnally, I'd be Ok with just the constraint that 'Bindings 
>> required to deliver the envelope infoset intact, without modification'.
I think we're agreeing...the above was not intended as exact wording 
anyway.  See below.

>> > * Architecturally separate application level extensions (using 
>> > from binding level "features":  when we say feature, we mean an 
>> > capability implemented by one or more binding specifications.
>> > >> Features must be defined in terms of non-envelope properties of 
>> > state machines at each node, except that features can make read-only
>> > access to information in the envelop infoset property.<<
>> I have some mixed feeling about this, but am mostly ok. I think my 
>> is centred around the distinction between a feature (eg. 
>> corelation) and the mechanism used to provide/implement the feature (a
>> binding/binding specification).
That's a distinction we could make too, but I think it's implicit in what 
we've already put in about features.  It seems to me very clear that we've 
allowed individual binding specifications great latitude in how to express 
a feature.  The new exception is that bindings are NOT allowed to express 
features in terms of headers (except insofar as read-only access is 

>> If we had more time... I think that we could use the concepts of 
>> and properties to describe SOAP extensibility more formally than we 
have to
>> date. 
I agree.

>> I also think that it would be tenable for a SOAP module spec'd on
>> single hop basis (ie. one where the headers were alway labelled with
>> actor='../next') to provide semanitically identical functionality to
>> functionality provided directly by a binding. For example, consider
>> functionality (a feature?) named
>> ion. Our existing SRR transport-mep could be said to directly provide 
>> functionality/feature. Likewise, it is conceivable that a module named
>> ay could be defined for use inconjunction with a one-way TMEP to 
>> identical functionality. The module would also modify the fault 
>> behaviour of the one-way TMEP (assuming that the one-way TMEP allows 
>> overriding). I think that with more effort and F2F time that we could 
>> this one... but I think that we're out of time (probably).
Yes, one could try and express such equivalence, but I think it's a mess 
to try to impose it at the SOAP level, or to assume that middleware will 
be written to paper over the kludge.  I've gradually come to the opinion 
that we have two choices (a) if we want to have such equivalence between 
header-based and transport based implementations of a capability, then the 
right way to do it is to let the bindings mess with the headers, deeply 
integrate the processing models, and let bindings benefit from mU or (b) 
avoid any general notion of equivalence.  If the spec for a module wants 
to claim equivalence with the spec for a feature, that's fine, but I 
suggest we leave it to others to generalize the equivalence concept.  The 
majority of the TBTF has strongly shied away from (a), which was my 
original position.  I am therefore proposing (b) as what seems to me the 
clean, simple alternative.

>> I continue to have a lingering discomfort with the blending of the 
>> feature and mep. I find myself conceiving of an mep as a context in 
>> features/functionality can be delivered. Request/Response corelation,
>> message authentication, message privacy (encryption), delivery 
>> all have the feel of being features/functionality that get provided 
>> the context of some message exchange, and that for me sets MEPs aside 
>> features.
>> There is also the re-emergence of the distinction between 
transport-meps and
>> meps at higher levels (either within the SOAP node or synthesised 
higher up
>> in the application) [1].
I think I'd stand by the answer above.  In general, the approach we're 
taking (I.e. the compromise proposed) is going to be quite weak in getting 
the bindings involved in anything that is specified as a multi-hope 
abstraction, like an end-to-end req/resp through intermediaries.  We lose 
that, gain simplicity.

>> > * Eliminate from Stuart's proposal the notion that there are multiple 
>> > to provide a feature, and that nodes have discretion in choosing 
>> > them.  Instead, we say that each binding specification implements 
zero or
>> > more features.  For any given feature, all bindings that implement 
>> > feature do so compatibly as seen in the state machine (bullet above). 
>> > other words, the application has a consistent model of how reliable
>> > delivery is requested and achieved, regardless of which
>> > binding is chosen.
>> This works for the module/binding distinction when we define features 
>> such a way that only bindings can provide them. However, at a given 
>> node ther may still be multiple bindings that are capable of providing 
>> range of features required for a given message exchange and the SOAP 
>> (possibly influenced by the application in some mannere unspecified) 
>> discretion over which particular binding it uses for a message exchange 
>> those circumstances where more than one are capable of doing the job 
>> reaching the next ImmediateDestination :-)).
>> So... I would content that even if we restrict ourselves to just 
>> (as is our scope as the TBTF) there remain multipe ways in which a 
>> may be provided at a given node (multiple bindings conforming to the 
same or
>> different binding specs.).
Agreed, but as I said above, I think that's covered.  I think our spec 
already calls out a notion of feature that can be re-implemented by 
various binding specs.  I think it's easy to see how description languages 
and middleware will offer the right information and options to 

>> > Some Implications
>> > -----------------
>> >
>> > Consider a feature such as "reliable delivery".  We want to provide 
>> > same feature on two different transports, MQSeries and UDP.  MQSeries
>> > gives us lots of help in assuring reliability, UDP will require lots 
>> > work in the binding.  In this compromise design, each binding
>> > specification tells how it will get the job done on the wire.
>> >  The UDP binding is presumbably going to have to explain lots of
>> sequencing,
>> > acknowledgement, retry, and perhaps even how state must be
>> > stored on disk if reliability is to be across system crashes.  Unlike 
>> previous
>> > proposal, the UDP binding cannot insert into the envelope
>> > headers that would be seen by the "chapter 2" processing logic at the
>> > receiving node. So, the UDP binding will have to describe properties
>> (perhaps
>> > in the form of XML fragments, perhaps of other type) as well as the 
>> > packets to be sent in each case.
>> The alternative would be to define a "reliable delivery" module that 
>> used wholly above the binding and is subject to the chapter 2 
>> logic and may be used over some defined set of (T?)MEPs (including
>> unsequenced lossy one-way). Which would seem like the right thing to 
>> and could be extended to cover end-2-end reliable delivery.
>> > So, the integrity of the envelope is preserved, but we also get
>> > applications and nodes out of the business of trying to determine 
that two
>> > extensions, one in a binding and one in headers, are somehow
>> > equivalent.
>> I'll agree that assertion of equivalence is hard - it may not be 
possible -
>> it would probably take more time than we have to demonstrate this one 
way or
>> the other. My own belief is that there are features for which such
>> equivalences (between binding/module provision) can be asserted.
>> Demonstrating this would take a while!
I think it brings implementation (and testing) complexity as well as 
specification complexity, hence my reluctance.

>> > In the example above, the HTTP and MQSeries bindings warrant that 
they do
>> > inded implement the SAME feature.  Now we have a good base for 
>> > things like WSDL descriptions, pluggable middleware, etc., without 
>> > the application involved.  What we've lost compared to my earlier 
>> > is the ability to apply the SOAP processing model, with 
mustUnderstand and
>> > the like, to extensibility of the bindings themselves.  We've also 
lost a
>> > lot of the ability to define features that go multiple hops in a way 
>> > can be in the envelope on some hops, but optimized on others.
>> >  That's a compromise I can live with in the interst of simplicity.
>> Basically, I think that we have more work to do to understand the 
>> of bindings and modules and the features/functionality they provide in
>> multi-hop scenarios. This stuff is just hard... if you want to be 
>> precise.
>> I'd certainly agree that there are some features that work simply by
>> extension across multiple hops... but I'm not sure that that is the 
>> case. I thad been forming a view that there is an 'infoset' associated 
>> a feature and that the operation of the feature in a sense has to
>> communicate the values of those 'infoset' items between peers along a
>> message path. The description of a feature can then speak in terms of 
how to
>> relay those properties across an intermediary (subject to possible
>> modification) to be re-expressed along with the relayed envelope. Over 
>> given hop a choice would be made (IMO by the node) whether to delgate 
>> feature to a binding or to use a module over the next hop.
>> I don't know how we get to have this discussion in focussed enough for 
>> enough that we can reach some common articulation of the abstractions 
>> we are dealing with.
>> > Proposed text:
>> > --------------
>> >
>> > (I don't have time to check the rest of the spec, so this may need 
>> > work for integration.  I think the sense of it is right.)
>> >
>> >
>> > SOAP binding specifications MAY provide for support of SOAP 
>> > and each specification MUST indicate the features supported.
>> Agreed.
Good, thanks!
>> >  For each such feature, the specification must provide for 
>> > state (in the state machines) and transmitting information from node 
>> > node in a manner that is fully conformant with the specification for 
>> supported
>> > features.
>> I think I agree... however, it may be the case that at crucial points 
>> exchange some invariants must hold with respect to the values held in a
>> bunch of properties rather than it being imperative that some 
>> through a state-machine be followed.
Right, but I don't think we have to do anything to make that possible.  If 
I write my feature spec to highlight such invariants, or to be only in 
terms of such invariants, then my specification can be written that way. 
Why call it out as general to all of SOAP?

>> > Thus, SOAP nodes (applications) are assured that features are
>> > supported compatibly when implemented by more than one binding.
>> Agreed.
>> > The specification for a binding MUST provide for transmitting the 
>> > envelope infoset, without modification of any kind, to the next node 
>> > the message path.  The specification MAY also provide for 
>> > additional information (derived from properties of the state machine) 
>> > or from the next node as necessary for the implementation of 
>> > features.  Envelope infosets MAY be inspected before transmission or 
>> > receipt, but MUST NOT be altered by any SOAP binding.
>> I'd be ok to relax the last clause to: "but MUST be delivered unaltered 
>> the next node."
>> ie. emphasis that what is delivered is what was sent... but interms how 
>> infoset is encoded on the wire and whether it gets 'annotations' that 
>> removed  etc... we remains silent.
We can wordsmith according to preferences of the group.  The point is, 
soap chapter 2 "runs" and prepares an infoset.  The binding recreates the 
infoset at the next node, using any desired wire representation, including 
multiple small message exchanges, etc.  Note that while the infoset itself 
always flows to the next hop, I believe that bindings can also send 
information the other way at any time.  Binding-level ACKs are an 
example...they update the sender's state machine.
>> >
>> > ---------------
>> >
>> > I know this will need some cleanup, but I hope it will help to move 
>> > toward concensus.
>> >
>> > ------------------------------------------------------------------
>> > Noah Mendelsohn                              Voice: 1-617-693-4036
>> > IBM Corporation                                Fax: 1-617-693-8676
>> > One Rogers Street
>> > Cambridge, MA 02142
>> > ------------------------------------------------------------------
>> Regards
>> Stuart

Thanks for your careful comments.  I'm encouraged that we seem to be near 
agreement on the major points. 

Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
Received on Monday, 28 January 2002 19:13:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:11:45 UTC