RE: TBTF: Four possible points of concensus

+1 also.

Thanks,

Stuart

> -----Original Message-----
> From: Noah_Mendelsohn@lotus.com [mailto:Noah_Mendelsohn@lotus.com]
> Sent: 17 October 2001 14:46
> To: Christopher Ferris
> Cc: xml-dist-app@w3.org
> Subject: Re: TBTF: Four possible points of concensus
> 
> 
> +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
> 
> 
> Noah,
> 
> Nice write-up. Some comments follow. Sorry I missed the call,
> sounds like quite a bit of progress was made.
> 
> Cheers,
> 
> Chris
> 
> Noah_Mendelsohn@lotus.com wrote:
> 
> <snip/>
> > 
> > Concern #1:  are we inventing duplicate mechanisms (soap 
> processing vs. 
> TB
> > 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 
> "reach
> > 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 
> feature
> > to work.   Reasons for these choices:  (a) in SOAP 1.1 
> we've already 
> seen
> > 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 
> use
> > 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. 
> At
> > 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 
> features
> > you need (reliable delivery.)  If such features must be 
> agreed between 
> two
> > nodes, and if they are modeled outside the envelope, then 
> the binding
> > implementations are implicitly obligated to negotiate the required 
> feature,
> > 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 
> underlying
> protocol."
> 
> 
> > 
> > Concern #4:  SOAP chapter 2 state machine works within a node.  The 
> machine
> > introduced in [1] effectively goes to the next hop.  Where 
> do we find 
> logic
> > 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 
> example,
> > MEP's can be created that build on the mechanisms above to 
> provide an
> > overall state machine for a message routed through 
> intermediares.  On 
> top
> > of such an MEP, a feature specification could describe end-to-end 
> behavior
> > for some particular feature such as encryption.  Also:  
> many features 
> can
> > be built purely using mechanisms within the envelope, and 
> these also 
> build
> > 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.
> 
> 
> Agreed.
> 
> 
> > 
> > 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 12:56:02 UTC