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 bound
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 POST
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 are
required; I.e. when performing retrievals which are idempotent, known to be
free of side effects, for which no SOAP request headers are required, and
for which security considerations do not conflict with the possibility that
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 message
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... only
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 requires
> > 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 of
the framework that we created - such that binding clients can make use of
bindings that support/provide features that they understand, without having
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 06:40:54 UTC