W3C home > Mailing lists > Public > xml-dist-app@w3.org > October 2001

Re: TBTF: Four possible points of concensus

From: <Noah_Mendelsohn@lotus.com>
Date: Wed, 17 Oct 2001 09:45:58 -0400
To: Christopher Ferris <chris.ferris@sun.com>
Cc: xml-dist-app@w3.org
Message-ID: <OF16C3BDB7.76AB4F6F-ON85256AE8.004C6B2C@lotus.com>
+1.  I think I agree pretty much with all your comments and 
clarifications.  Thanks.

Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142

Christopher Ferris <chris.ferris@sun.com>
10/17/2001 08:02 AM

        To:     Noah_Mendelsohn@lotus.com
        cc:     xml-dist-app@w3.org
        Subject:        Re: TBTF:  Four possible points of concensus


Nice write-up. Some comments follow. Sorry I missed the call,
sounds like quite a bit of progress was made.



Noah_Mendelsohn@lotus.com wrote:

> Concern #1:  are we inventing duplicate mechanisms (soap processing vs. 
> framework state machine)?
> Proposed resolution:  no, it's one combined state machine...TB machine
> covers message flow, and provides input to and takes messages from the
> processing logic in SOAP chapter 2.

Sounds reasonable.

> Concern #2: one could model all features in the envelope.  The design in
> [1] also allows for properties outside the envelope to be modeled.  This
> does not leverage SOAP as much.  Should we stick with it?
> Proposed resolution:  yes.  Features can be modeled in the envelope
> property, in other properties, or both.   Either way, a binding can 
> in" and do a customized implementation (e.g. secure delivery over https,
> reliable delivery over MQSeries).  If the feature is purely in the
> envelope, then the binding need not do anything special to get the 
> to work.   Reasons for these choices:  (a) in SOAP 1.1 we've already 
> what are effectively properties outside the envelope.  These include the
> destination URI for http, and also SOAPAction (b) you also need to model
> state local to the node (retry counts) as well as data to be sent in a
> message--that's hard to do with an envelope-only model.

Again, sounds reasonable. However, I think that some careful wording
that strongly encourages features be modeled within the SOAP envelope
where possible and appropriate might be needed. Maybe some prescriptive
language along the lines of what you describe as being "outside"
the envelope would be in order.

> Concern #3:  Does that mean we need to invent a new equivalent to
> "mustUnderstand" so an application can find out whether the binding in 
> supports the features it needs?
> Proposed resolution:  No.  The mustUnderstand we have deals with
> communication from node to node, and it's appropriate for that purpose. 
> a given node, such as a sender, it's your business to make sure the
> software you use (such as a binding implementation) supports the 
> you need (reliable delivery.)  If such features must be agreed between 
> nodes, and if they are modeled outside the envelope, then the binding
> implementations are implicitly obligated to negotiate the required 
> or else they wouldn't be compatible implementations of the same binding.
> In short: no explicit SOAP mechanism needed.  Keep it simple.

Agree on KISS;-) However, it also suggests that specifics regarding
extra-envelope feature negotiation should be called out in the framework.
Maybe it is in the Feature specification, or maybe in the Binding
Framework, but somewhere, it needs to be said that "features that are
expressed external to the SOAP envelope that require bilateral
behavior of the two SOAP nodes (Sender and Receiver) MUST provide
for negotiated understanding/agreement either through specific out-of-band
means or through a specified negotiation aspect/mechanism of the 

> Concern #4:  SOAP chapter 2 state machine works within a node.  The 
> introduced in [1] effectively goes to the next hop.  Where do we find 
> that covers an entire path?  Where are end to end semantics for features
> such as encryption?
> Proposed resolution:  these will show up above the SOAP core.  For 
> MEP's can be created that build on the mechanisms above to provide an
> overall state machine for a message routed through intermediares.  On 
> of such an MEP, a feature specification could describe end-to-end 
> for some particular feature such as encryption.  Also:  many features 
> be built purely using mechanisms within the envelope, and these also 
> on the normal SOAP processing model (and possibly also on some
> intermediate-aware MEP).
> We also agreed that it remains important to make the presentation of the
> state machines and the architecture yet clearer and more accessible.


> TBTF members: did I get this about right?
> [1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Oct/0146.html
> ------------------------------------------------------------------------
> Noah Mendelsohn                                    Voice: 1-617-693-4036
> Lotus Development Corp.                            Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------------
Received on Wednesday, 17 October 2001 09:55:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:16 UTC