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

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
> --------------------------------------------------------------
> ----------
> 
> 
>