RE: SOAP and the Web architecture

Jeff, I understand your point of view. Asking people to reconfigure
their firewalls is much harder than just tunneling something through
the existing ports. As a product strategy, it's a bad idea.

However, it's a bad idea to then ignore the characteristics of
the software that is often placed to intercept traffic on those
ports, including limitations on the length of URLs, filters that
are looking for adult content in text/* MIME types, virus filters,
denial of service attacks, etc.

What I'm objecting to is trying to have it both ways.

I also believe that it's reasonable for a Recommendation from
W3C to take a different approach than a product design. Not
because recommendations are theoretical while product designs
are practical, but because Recommendations are intended to
be permanent and future-looking, while product designs are
transient and can change from one release to the next.

A Recommendation can recommend good practice (using a
unique newly registered SOAP port) even while acknowledging that
for practical considerations and compatibility with existing
implementations it might be reasonable for SOAP servers
to listen on multiple ports (including 443 and 80), and for
SOAP clients to try them in order. This would let those
folks behind firewalls run by intransigent administrators
interoperate, but would move most of the traffic away
from unwanted interception proxies. This would help with the
practical interoperability problems that will result from
interaction with the growing practice by ISPs of compulsory
HTTP proxy/caching of traffic on port 80.

For example, our VPN software just came out with a
"NAT transparency mode" that used a different port than
port 80, along with a message from the person who was
supporting it:

# The *huge* (from my perspective) improvement in the [xxx] client family is
# that it now permits a configurable NAT Transparency Mode port, instead of
# being stuck at TCP/80.  If you have a Mac and a NAT box and your ISP is
# doing compulsory proxying/caching of HTTP (see experiment PS below), this
is
# the client you've been waiting desperately for.  The Ethernets in many
# hotels also are behind NAT boxes and enforce compulsory proxying/caching
of
# HTTP, so with the new client family plugging into a hotel Ethernet should
# now be completely successful.

Now, if VPN "NAT transparency mode" using port 80 has
resulted in a large number of calls to our help desk complaining
about odd network problems from travelers, won't SOAP on port
80 present the same problems?  And won't the support problems
come to our admins, because the software works fine when tested
in more ideal circumstances?

Why should W3C recommend a practice that is known to have
practical deployment difficulties?

# Those sequestered in their ivory towers would do well to step out, smell
# the air, and recognize this.

You will note that I have made no reference to the design principles
of my ivory tower, despite my unfortunate sequestering therein.

Regards,

Larry
--
http://larry.masinter.net

Received on Wednesday, 29 August 2001 10:34:42 UTC