RE: Proposed Framework Text for F2F (was RE: TBTF: In-context Fra mework Intro.)

Folks,

Apologies for the inconvenience... another drop... put Noah's ednote at the
end of the document rather than after the appropriate paragraphs.
Replacement versions attached with the ednote in the right place... no other
changes.

Regards

Stuart

> -----Original Message-----
> From: Williams, Stuart 
> Sent: 20 November 2001 20:55
> To: 'Noah_Mendelsohn@lotus.com'
> Cc: Chris.Ferris@sun.com; fallside@us.ibm.com; 
> gdaniels@macromedia.com;
> highland.m.mountain@intel.com; hugo@w3.org; jones@research.att.com;
> marc.hadley@sun.com; ohurley@iona.com; ylafon@w3.org; Henrik Frystyk
> Nielsen; 'www-archive@w3.org'
> Subject: Proposed Framework Text for F2F (was RE: TBTF: In-context
> Framework Intro.)
> Importance: High
> 
> 
> Hi Noah et. al,
> 
> The wires that connect HP and Lotus must be very narrow... it 
> took 2hrs 10mins to get here! Fortunately I saw Highland's 
> question in response much earlier which contained your 
> various suggestions. 
> 
> I was on the brink of making an almost identically worded insert to:
> 
> >>MEPs are considered to be a type of feature;  unless 
> otherwise stated, references to the term "feature" apply also 
> to MEPs.<<
> 
> at exactly the same point in the document... so that was reassuring!
> 
> Unfortunately, I have not seen your response to Highlands 
> question, which may have been a simple 'yes' or it may have 
> been a revision to the Ed Note (in which case I have not 
> changed it from your original suggestion).
> I've attached HTML and DOC versions of the revisions I've 
> applied and a diff version from Henriks previous version to 
> speed review.
> 
> The main piece that has given perhaps needs more careful 
> review is the following change:
> 
> <original_version>
> As described above, SOAP can be augmented with optional 
> features (such as reliable message delivery) and with new 
> Message Exchange Patterns (request/response, multicast, 
> etc.). The specification of each such MEP or feature MUST 
> include the following:
> 
> 1.	The information (state) required at each node to 
> implement the MEP or feature.
> 2.	The processing required at each node in order to 
> fulfill the obligations of the MEP or feature.
> 3.	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).
> 
> Every binding specification MUST support the transmission and 
> processing of one-way messages as described in this 
> specification. A binding specification MAY state that it 
> supports additional MEPs and/or features, in which case the 
> binding specification MUST provide for maintaining state, 
> performing processing, and transmitting information in a 
> manner consistent with the specification for those MEPs and features.
> </original_version>
> 
> <revised_version>
> As described above, SOAP can be augmented with optional 
> features, (such as reliable message delivery, 
> request/response MEPs, multicast MEPs, etc.). The 
> specification of each such feature MUST include the following:
> 
> 1.	The information (state) required at each node to 
> implement the feature.
> 2.	The processing required at each node in order to 
> fulfill the obligations of the feature.
> 3.	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).
> 
> Every binding specification MUST support the transmission and 
> processing of one-way messages as described in this 
> specification. A binding specification MAY state that it 
> supports additional features, in which case the binding 
> specification MUST provide for maintaining state, performing 
> processing, and transmitting information in a manner 
> consistent with the specification for those features.
> </revised_version>
> 
> I believe that this all in line with what we agreed on the call.
> 
> Best regards
> 
> Stuart
> 
> > -----Original Message-----
> > From: Noah_Mendelsohn@lotus.com [mailto:Noah_Mendelsohn@lotus.com]
> > Sent: 20 November 2001 18:27
> > To: skw@hplb.hpl.hp.com
> > Cc: Chris.Ferris@sun.com; fallside@us.ibm.com; 
> > gdaniels@macromedia.com;
> > highland.m.mountain@intel.com; hugo@w3.org; jones@research.att.com;
> > marc.hadley@sun.com; mnot@akamai.com; ohurley@iona.com; 
> ylafon@w3.org;
> > Henrik Frystyk Nielsen
> > Subject: RE: TBTF: In-context Framework Intro.
> > 
> > 
> > Proposal to Stuart for the MEP/feature change:
> > ==============================================
> > 
> > Old text:
> > 
> > As part of communicating between SOAP nodes it may be necessary to 
> > introduce a variety of abstract features generally 
> associated with the 
> > exchange of messages in a protocol environment. Although 
> SOAP poses no 
> > constraints on the potential scope of such features, 
> typical examples 
> > include "reliability", "security", "correlation", and "routing". In 
> > addition, the communication may require message exchange 
> patterns (MEPs) 
> > beyond the one-way MEP that SOAP provides.
> > 
> > Proposed change:
> > 
> > As part of communicating between SOAP nodes it may be necessary to 
> > introduce a variety of abstract features generally 
> associated with the 
> > exchange of messages in a protocol environment. Although 
> SOAP poses no 
> > constraints on the potential scope of such features, 
> typical examples 
> > include "reliability", "security", "correlation", and "routing". In 
> > addition, the communication may require message exchange 
> patterns (MEPs) 
> > beyond the one-way MEP that SOAP provides.  >>MEPs are 
> considered to be a 
> > type of feature;  unless otherwise stated, references to the term 
> > "feature" apply also to MEPs.<<
> > 
> > ...then change all(?) references to "features and MEPs" to just say 
> > "features".
> > 
> > Ednote:
> > =======
> > 
> > I was asked to draft an ednote for the end of the 
> introduction.  How 
> > about:
> > 
> > (this is to follow the para reading)
> > 
> > "It is up to the communicating nodes to decide how best to express 
> > particular features and MEPs; often when a binding-level 
> > implementation 
> > for a particular feature is available, utilizing it when 
> > appropriate will 
> > provide for optimized processing."
> > 
> > Editors note: there is still some disagreement as to how best 
> > to represent 
> > the balance of responsibility between binding specifications in 
> > particular, vs. other software at the SOAP node, when dealing with 
> > features that are represented entirely within the SOAP 
> > envelope. The two 
> > paragraphs above may need some additional work to clarify.
> > 
> > --------------------------------------------------------------
> > ----------
> > Noah Mendelsohn                                    Voice: 
> > 1-617-693-4036
> > Lotus Development Corp.                            Fax: 
> 1-617-693-8676
> > One Rogers Street
> > Cambridge, MA 02142
> > --------------------------------------------------------------
> > ----------
> > 
> > 
> > 
>