Summary of positions on LC #227/#228 re: Web Method Feature

It seems from the minutes that I have an (implicit) action to summarise the
discussion on LC Issues #227/#228.

> 227
> Henrik: Wait for Stuart. Just too many emails.
> DavidF: Stuart should provide a summary of discussion.
> Postponed. Wait for Stuart.
> 228
> MarcH: related to 227.

The thread [0] that arose from my posting [3] is large and in places
blossoms into discussion of: extension and layering of protocols; REST and
tunnelling; and protocol agnostisism. Many postings are not focussed
directly on the LC comments in [3]. Most of the focussed discussion has
occurred between Stuart, Mark Baker, Noah and Marc. Other WG members (and
former members) have participated in the discussion: Jean-Jacques, Jacek,
Mike Champion, Chris Ferris and Glen Daniels.

I have tried to offer a fair summary of the main positions held and
apologise to anyone who feels that I have unfairly represented their
position (or indeed my own) or who feels that have made important points or
statements of position that I have failed to capture.


Stuart Williams

Summary of email thread on Web Method Feature [0].

The bulk of this summary is focussed on positions with respect to Last Call
Issue 227 [19]. 

There seems to be reasonable concensus [8, 10] that the spec. would benefit
from further editorial clarification on the dependencies between the Web
Method feature and the Request-Reponse and SOAP-Response MEPs, Issue #228

Stuart W:
Our framework[1] sets the expectation that users of a binding can make use
of the binding provided features that they understand without *having* to
use those binding provided features that they don't understand or that they
choose not to use.

Our HTTP binding, as specified, runs counter to that expectations because it
requires (implicitly due to 1st row of table 15 [2]) that the binding user
understand and *use* the Web Method feature in order to successfully use
either SOAP-Response or Request-Response. The behaviour of the binding is
at-best undefined if the feature is not used to initiate a message exchange.

The change requested [3] is for Part 2 Table 15 to include defaults of POST
and GET for the HTTP method when used in conjunction with the
Request-Response and SOAP-Response MEPs respectively *iff* a message
exchange is initiated without the Web Method feature being used. These
defaults are in line with the narrative in Part 2 Section 6.4.3 [4]. If the
Web Method feature is used, it takes precidence in the selection of HTTP


Marc H:
Supportive of Stuart's position [5]. Would also like to see http method
selection based on MEP and more abstract feature/properties such as the
'safety' expectations of the initiating SOAP node [5,6]. Web Method and MEP
are not really othogonal [6].


Jean-Jacques and Jacek
Have both indicated some support for the change requested by Stuart


Mark Baker:
MEP and (web?) method are 'a priori' orthogonal [7] meaning that in
principle any (Web?) method may be used with any MEP, however, the act of
creating a binding to a particular MEP introduces further constraints
specific to that binding[8]. Inference of MEP follows from chosen method (at
least for HTTP) .The inference cannot be drawn the other way round [7].

Would support some editorial clarification of the dependencies between MEP
and Web Method feature imposed by HTTP binding [8].

Strongly opposes Marc H's position on refactoring Web Method feature as a
'safe' exchange feature [13].

Strong preference to retain the status-quo or even strengthen requirement
that the Web Method alway be used in conjunction with the HTTP binding [14].
Cites agreement with Sam Ruby (Apache Axis developer) on this point[14],
however, Sam questions whether agreement was in fact reached [21].


Noah Mendelsohn:
Supports Mark Baker's position [9,10] regarding inference of Method from

Preference to maintain the status-quo. "...the design is fine as it stands."
[10]. Willing to 'live' with requested change [3] "if and only if it does
not risk sending us to last call again." [15]

The requested changes really only affect our abstract description and make
no really requirements on a typical user [11] [Stuart concurs with this last

Would support some editorial clarification on the allowable
combinations/dependencies between MEP and Web Method feature. [10]

Opposes Marc H's position on refactoring the Web Method feature as a 'safe'
exchange feature [18] on the grounds: 1) "I think that 
"safe" is not what we're trying to say, although it is part of it."; and 2)
that it risks going back through last-call.

Chris Ferris
Supports Noah's position in opposition to Marc's position on refactoring Web
Method as 'safe' exchange feature [22].


Received on Tuesday, 16 July 2002 07:40:58 UTC