W3C home > Mailing lists > Public > xml-dist-app@w3.org > January 2002

Re: SOAP port number

From: Mark Nottingham <mnot@mnot.net>
Date: Mon, 7 Jan 2002 14:56:10 -0800
To: Eugene Kuznetsov <eugene@datapower.com>
Cc: Mark Baker <distobj@acm.org>, Henrik Frystyk Nielsen <henrikn@microsoft.com>, Krishna Sankar <ksankar@cisco.com>, xml-dist-app@w3.org
Message-ID: <20020107145610.A13818@mnot.net>
Should we also define a port for SOAP over SMTP? What if a HTTP
message is Multipart, containing some HTML, a jpeg and a SOAP
message?

Of course people use ports to control traffic; I do it myself. It
doesn't follow that everything should have a port.

The semantic of a port is "messages sent to and received from it have
a reasonable expectation to comply with a specified protocol."
SOAPoverHTTP messages are in the HTTP format, as specified by the
port registration. Using port as a heuristic to determine what's
happening in the protocol is unreliable. Codifying the use of such
heuristics restricts the ultimate expressiveness of the Web.

It would be interesting to see what IANA would think of the
registration of what is effectively an existing protocol with a
specific payload format, however.



On Mon, Jan 07, 2002 at 04:32:15PM -0500, Eugene Kuznetsov wrote:
> > I would strongly urge the group not to pursue this; although it
> > seems like a good/friendly thing to do, it encourages people to
> > trust (or not trust) traffic by port, which is unrealistic and
> > dangerous.
> 
> I cannot resist pointing out that this is exactly what people do
> with their firewalls and content switches today. Leaving aside
> whether it is proper or dangerous, "unrealistic" is thinking that
> people do not use TCP ports to filter, classify and route their IP
> network traffic.
> 
> Indeed, one of the reasons oft-cited for SOAP over HTTP is
> explicitly the fact that because many enterprise firewalls block
> all incoming ports other than port 80, putting SOAP over port 80 is
> a win! (The "catch-22" again).
> 
> The ability to associate application expectations for traffic on a
> certain TCP port is important. Yes, in itself it is not a guarantee
> of security or correct application behavior -- you may still verify
> those expectations (e.g., "I'm a firewall and I expect HTTP only on
> port 80, verify that to be the case"), but it is a vital part of
> the network infrastructure today.
> 
> 
> \\ Eugene Kuznetsov
> \\ eugene@datapower.com
> \\ DataPower Technology, Inc.
> 
> 

-- 
Mark Nottingham
http://www.mnot.net/
 
Received on Monday, 7 January 2002 17:56:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:05 GMT