- From: Eugene Kuznetsov <eugene@datapower.com>
- Date: Mon, 7 Jan 2002 13:06:32 -0500
- To: "Mark Baker" <distobj@acm.org>, "Henrik Frystyk Nielsen" <henrikn@microsoft.com>
- Cc: "Krishna Sankar" <ksankar@cisco.com>, <xml-dist-app@w3.org>
Discussion on this issue is always a catch-22: "SOAP over HTTP is good because we can traverse firewalls over port 80" followed by "SOAP over HTTP is bad because it causes security problems and puts further burden on already-overloaded port 80". Naturally, anyone looking at the problem "from the bottom up" (e.g., from the standpoint of network infrastructure, as opposed to applications), will always see the need for lower-level network traffic classification opportunities -- be it a SOAP-specific HTTP header marker or a SOAP-specific TCP port. Which is I think where Krishna is coming from, please correct me if I'm wrong. If so, I very much agree -- it's easier to pre-classify traffic for routing or filtering at lower levels. > Which is great from my POV. But I don't think that precludes us > defining an alternate port in the default HTTP binding that folks can > use in place of 80. Right, I'd just like to know which "alternate port" someone will be using if they choose not to use port 80. I don't care if it is port 10, 90 or 512 -- but I think there is value in guiding users to a specific port. \\ Eugene Kuznetsov \\ eugene@datapower.com \\ DataPower Technology, Inc.
Received on Monday, 7 January 2002 13:01:36 UTC