Re: another approach to status codes, etc. in HTTP binding

Rich,

Rich Salz wrote:
> 
> > But it isn't, it's a
> > protocol that extends application protocols.
> 
> Some would disagree.  I view the bindings more as a "tunneling"
> mechanism, a way of carrying new traffic in old bottles.

Yep, I acknowledge that many others believe this.  A thought on that
below.

> This is one of those elegant theories that fails in the real world. You
> cannot get identical semantics across different network layers.

I don't understand what you mean.  Identical semantics to what?

> Except that the HTTP/1.1 RFC says "User agents SHOULD display an
> included entity to the user" (sec 10.5).  Display to user doesn't match
> "deliver to soap engine." In particular, it allows for the entity to be
> dropped (it's a SHOULD not a MUST, so caches and proxies could drop
> and/or rewrite it, e.g) or otherwise modified.

SOAP processors, even those using HTTP, are not HTTP user agents so are
not bound by this requirement.

> When SOAP has something to communicate to a SOAP peer, it should use the
> underlying protocol mechanisms to say "here is data for you."

So what's wrong with using the application semantics of the protocol so
that SOAP/HTTP means "accept this SOAP message as a subordinate", and
SOAP/SMTP (guessing) means "deliver this SOAP message", and SOAP/FTP
(also guessing) means "store this SOAP message"?

I ask because the application semantics have to come from someplace.  So
it seems that the alternative is that either;

1) we have to define the application semantics of what it means to
transfer a SOAP message, or
2) every use of SOAP defines its own meaning (as with RPC)

#1 is against our charter (and not what the WG has been doing so far),
and #2 is just plain scary.

MB

Received on Wednesday, 18 July 2001 20:57:37 UTC