Re: [wsdm] MUWS - 2.1.2 Message Exchange Patterns

[Sanjeev Kumar <sakumar@attbi.com>]

Geoff, relevant points wrt co-existence with firewalls. More details
below.

Geoff Bullen wrote:
> 
> Hi all,
> I remember as part of the discussion on this section it was suggested that
> if we just specify that we need an asynchronous protocol, then you can
> implement the single request/reply concept on top of this... so therefore
> you don't need to specify both.
> It is my belief that we definitely need to specify a direct request/response
> protocol.  There are a number of cases where using firewalls makes it quite
> difficult to support asynchronous traffic (messages initiated from both
> ends) rather than the simpler request/reply - where messages are only
> initiated from one end.

I think, specifically, maintaining a well-known (inbound) port on both
sides and the connection being persistent should make things
more firewall friendly. If we take the case of MUWS, then the inbound
ports used across the firewall on either end are most likely to be 80,
and we can be explicit about being able to work over HTTP1.1 and
HTTP1.0 w/ Conn:Keep-Alive. There is still the issue of initiation of
the connection, which typically should always be done from inside the
firewall. But async messages sent over HTTP should not have this
problem. [Correct me if my assumption is wrong here.]

> I am not suggesting we should not support async, but I think you should be
> able to create a management solution without it.

Well, if we are to support async, then we have to address co-existence
with firewalls. Given that the transport for WS is HTTP, we will be
at the mercy of the idiosychracies (sp?) of this protocol wrt
firewall-friendliness regardless of the range of message semantics
(sync, async, req-reply) that we address.

My $0.02!
Sanjeev K.