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

Sorry for the slow response...I never did answer Highland (I'm 
theoretically on vacation...and it's moot now). Bottom line: I think the 
decisions you made are just fine, a significant improvement to what we had 
this morning.  Thanks for pulling it together so quickly!

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







"Williams, Stuart" <skw@hplb.hpl.hp.com>
11/20/01 03:55 PM

 
        To:     "'Noah_Mendelsohn@lotus.com'" <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 <henrikn@microsoft.com>, "'www-archive@w3.org'" 
<www-archive@w3.org>
        Subject:        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
> --------------------------------------------------------------
> ----------
> 
> 
>