Subject: RE: SOAP/XML Protocol and filtering, etc.

From: "Henrik Frystyk Nielsen" <[email-masked]>
Date: Tue, 8 May 2001 07:27:32 -0700

>> Because it can be hard to deduce from the message - especially as 
>> messages may be composed of many pieces from other places using
SOAP's 
>> modular extensibility mechanism (headers). In a sense this is similar

>> to that a media type can be hard to guess based on the entity alone.
>
>then add that to the SOAP payload that gets passed in the HTTP 
>entity body.  don't penalize HTTP for SOAP's design deficiencies.

It is not for the benefit of SOAP - it is for the benefit of HTTP which
is why it is expressed in a manner that is digestible by HTTP. Your
argument could equally well be applied to media types so does that mean
that you feel the same way about that?

Henrik

---

From: Keith Moore <[email-masked]>
Date: Tue, 08 May 2001 12:31:38 -0400

> is why it is expressed in a manner that is digestible by HTTP. 

it's not for the benefit of HTTP, as HTTP already has a suitable dispatch
mechanism - namely, the request URI.

it *might* be for the benefit of vendors who want to sell upgraded HTTP
servers or client libraries that support the new feature, and force 
customers to upgrade if they want to use SOAP.  but I don't see that as 
an adequate justification.

> Your argument could equally well be applied to media types 

media types aren't intended for dispatching on the server side.

however, the use of media types with HTTP applications brings up a very 
similar issue - if the content-type is orthogonal to the request, and
the server can potentially handle the same request in different formats, fine.
but if the part of the request is communicated by the content-type, this 
makes it impossible to transmit a properly-typed service request 'as data' 
without implicitly requesting the semantics of that service.

Keith