Re: A tale of two bindings

> > > "make it obvious to firewalls, etc." isn't on that list [of requirements].
> 
> > Yup ...
> 
> I am glad you agree.  Will you now stop saying it's something we should
> do?

No, but I'll stop saying it's in the requirements (not that I recall
doing so, but if you say I did ... ).

FWIW, unambiguously identify SOAP messages has been a known issue
for quite a while, even back in SOAP 0.9 and 1.0 days when it was
*only* used for tunneling RPC.  See;

http://www.develop.com/soap/issues.htm#1

> > R612 ...
> > appears to exclude the possibility of the WG defining a normative
> > binding used for tunneling, as tunneling does not respect HTTP semantics.
> 
> I disagree.  HTTP makes no comment on the data format in a POST.

Of course not.  That's syntax, not semantics.

>  And
> what HTTP semantics are being violated by a tunnel telling HTTP "don't
> worry, be happy, 200" ?

HTTP's POST semantics which mean "accept as a subordinate", which is
*not* the same as "do whatever the heck you want with it".  Also,
the semantics of "200" (though we've had that discussion before).

> If we change SOAP 1.1 to say faults came back as 200 and SOAPAction is
> deprecated, then we meet R612.

Eh?  SOAP 1.1 already meets R612.  You think SOAP 1.1 faults
return 500 just for the heck of it?  It supports the use of SOAP
that I and many others (like Microsoft's Biztalk) want/need.  If
SOAP 1.2 changes that to be only usable for tunneling, it will be
useless to many.

> I don't think I have anything new to contribute to this dicussion, so I
> expect this to be my last post on this topic.

Yah, I'm at that point too.

MB

Received on Friday, 27 July 2001 22:10:44 UTC