RE: [getf] Proposal for Web-friendly representation of RPC's in SOAP

Hi Henrik,

> -----Original Message-----
> From: Henrik Frystyk Nielsen [mailto:henrikn@microsoft.com]
> Sent: 30 May 2002 00:10
> To: noah_mendelsohn@us.ibm.com; xml-dist-app@w3.org
> Subject: RE: [getf] Proposal for Web-friendly representation 
> of RPC's in
> SOAP
> 
> I think there are many good points in this... I have tried to summarize
> my comments rather than scattering them throughout. If there is some
> agreement then I think we can quite easily provide updated wording.
> 
> 1) We should make a sharp distinction between the SOAP HTTP binding and
> the RPC convention. One can happily live with the SOAP HTTP binding
> without using RPC. I don't think this is much different from what you
> write already but I think should be kept as clear as possible. 

+1

> 2) When you say that one should use PUT for creating a resource, we
> should make it clear that this doesn't involve a SOAP message as such.
> The semantics of PUT is that the entity-body in the request represents
> the state of the resource to be created. If the operation succeeds and I
> perform a GET I get the resource that I just PUT. The PUT request
> doesn't "execute" the SOAP message. The reason I said "as such" is that
> it is of course perfectly valid to PUT a SOAP message and subsequently
> do a GET on it.

If this "doesn't involve a SOAP message as such." what has it got to do with
SOAP?

This seems like regular HTTP, using PUT to write to some storage and GET to
retrieve it. Don't really understand why we would have to say anything at
all about this, other than remind folks that the can use HTTP as HTTP. 'The
PUT request doesn't "execute" the SOAP message.' implies that the SOAP
message processing model does not apply which IMO further reinforces the
notion that this usage is plain HTTP with a SOAP message as a content format
- nothing more.

I'm not arguing against regular HTTP, just that SOAP is something different
- but then, maybe the title of part 1 doesn't mean anything.

> 3) HTTP POST has been explicitly defined to deal with "extraneous"
> semantics and can carry parameters such as the ones defined by a SOAP
> message. There are only a few other methods like OPTIONS that enables
> this. That is, it is not the case in HTTP that the entity-body always
> can be used to carry additional parameters, it is up to the particular
> method.

Is that:

a) not all HTTP methods allow an entity-body in the HTTP request message, or

b) of those HTTP methods that do allow an entity-body in the HTTP request,
not all such methods allow additional parameters to be carried in that
entity body.

If b) (or a and b) what constitutes 'a parameter' in once sense the whole
entity body is a complex parameter to the HTTP method. The narrative of
RFC2616 places some very 'fuzzy' restrictions on the sort of information
that might be conveyed in particular entity bodies. But it's not clear to me
what is meant by "additional parameters" and what HTTP method based
restrictions apply to the particular content of an entity body.

> 4) As to what HTTP method one is to use, I think we should leave that to
> the HTTP spec as it defines the semantics of its methods. To me, the
> absolutely most important part is that it is ok to use SOAP in
> combination with HTTP in ways that doesn't require a SOAP message in the
> request AND a SOAP message in the response.

Well... in that case I think we have stepped outside of the "SOAP 1.2 part 1
Messaging Framework" and we are doing HTTP with SOAP Messages just another
content format.

If that's what we want to do... we should say so... but I wouldn't then wish
to call it a messaging framework.

> 5) In many ways, I think the proposed text conveys the difference
> between HTTP and RPC rather than SOAP. As such it seems more to be a
> description of how to use HTTP vs. RPC than a description of how to use
> SOAP. Maybe having it in a section called "RPC and the Web" or some
> such?
>
> 6) I agree that we should not provide a mapping of SOAP into URIs as
> this is IMO not the point of this exercise. Rather, it is to enable SOAP
> usage in combination with non-SOAP messages.

Oh... I thought that the point was to encourage the use of URIs as the means
of identifying resources and to provide a means of making use of HTTP GET to
do things that are known to be 'safe' within HTTP binding for the SOAP
Messaging Framework.

I believe that we primarily need to describe the behaviour of SOAP nodes
interactiong with SOAP nodes. 

I think its also important that we discuss the behaviour of a SOAP node when
interacting with something that is not a SOAP (if indeed it is possible for
a SOAP node to tell the difference). 

I don't think it is our role to describe the behaviour of things that are
not SOAP nodes.

> Hope this makes sense,
> 
> Henrik

Cheers,

Stuart

Received on Thursday, 30 May 2002 05:26:29 UTC