RE: FW: LC Comments: Web Method Feature

Just to follow up on my previous note, I would probably not make the 
change Stuart suggests below, but I can live with it if and only if it 
does not risk sending us to last call again.  This has been my position 
right along, and I wanted to make clear it hasn't change.  My earlier note 
was WRT the proposal to replace the WebMethod feature with a safe/not-safe 
switch.  Thanks!

Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142

"Williams, Stuart" <>
Sent by:
07/15/2002 06:29 AM

        To:     "'Mark Baker'" <>, Jacek Kopecky <>
        cc:     Marc Hadley <marc.hadley@Sun.COM>, "''" 
<>, (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        RE: FW: LC Comments: Web Method Feature

Hi Mark,

> Hi Jacek,


> Well, as it stands right now, the Web method is exposed as a property.
> So you're suggesting replacing it with a "safe" property and removing
> any mention of the method?  This is my understanding of Stuart and
> Marc's positions.

I have *NOT* proposed the removal or renaming of the Web Method feature.

I have *NOT* proposed that it be made optional for the HTTP binding to
*support* the Web Method feature.

What I have proposed in [1] is that *if* the user (ie a piece software 
to the binding) does not recognise or use the Web Method feature when
initiating a message exchange, that the HTTP method used be default to 
in the case of the Request-Response MEP or GET on the case of the
SOAP-Response MEP. This is entirely in-line with the narrative in section
6.4.3 [3].

Applications SHOULD use GET as the value of webmeth:Method in conjunction
with the 6.3 SOAP Response Message Exchange Pattern to support information
retrievals which are safe, and for which no parameters other than a URI 
required; I.e. when performing retrievals which are idempotent, known to 
free of side effects, for which no SOAP request headers are required, and
for which security considerations do not conflict with the possibility 
cached results would be used. Except in unusual circumstances, other
operations SHOULD be performed using POST in conjunction with the 6.2
Request-Response Message Exchange Pattern. Other methods SHOULD not in
general be used. For example, use of PUT would suggest storing the SOAP
envelope Infoset as the created resource, as opposed to processing in the
manner required by the SOAP processing model.

As the HTTP binding is currently drafted, the behaviour of the binding is
at-best undefined if the Web Method feature is not used (ie the
webmeth:Method property is not set or not present in the initiating 
exchange context). IMO it is legitimate for the webmeth:Method property to
be absent or unset because we *do not* require that the user of a binding
understands and uses ALL the features that a given binding provides... 
those that it choose to use.

> In addition to my strong objection, I'd note that this would be a
> substantial change to what we agreed to go to Last Call with, so would
> presumably set us back to Working Draft status.

I do not believe that the change that I have proposed in [1] is as
substantial as you suggest. 

It is primarily about the way we use the framework we have developed to
describe behaviour. I have already agreed with Noah [2] that the change I
have requested makes no practical difference to real implementations. 

> > * All of the properties are abstractions anyway.  None of this 
> > typical user to bother or not bother with anything.
> I certainly agree on the implementation pragmatics here. 

It does however make a (positive IMO) difference aligning with the intent 
the framework that we created - such that binding clients can make use of
bindings that support/provide features that they understand, without 
to know and use binding provided features that they do not.

> MB
> -- 
> Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> Ottawa, Ontario, CANADA.     



Received on Monday, 15 July 2002 10:10:39 UTC