<font size=2 face="sans-serif">Dear SM&C WG,</font>
<br>
<br><font size=2 face="sans-serif">As mentioned during the technical meetings
in Pasadena and in the last web-ex, we have started the work on ESA side
to define a binding between MAL and HTTP transport.</font>
<br>
<br><font size=2 face="sans-serif">The main motivation for this binding
is to use mainstream Internet infrastructure on the ground.</font>
<br><font size=2 face="sans-serif">HTTP protocol is based on a request/response
model.</font>
<br><font size=2 face="sans-serif">For all MAL interaction patterns except
for INVOKE, PUBSUB and PROGRESS, there is a simple mapping to the HTTP
Request/Response model.</font>
<br>
<br><font size=2 face="sans-serif">It gets more complicated for the above
mentioned three interaction patterns, when the provider needs to asynchronously
initiate a connection to the consumer for delivering a response (request
in the other direction). This is specially problematic when the consumer/provider
are behind firewalls and also when consumers are dynamically added and
removed (hence the firewalls cannot be configured statically).</font>
<br><font size=2 face="sans-serif">The options we have been discussing
are: </font>
<br>
<br><font size=2 face="sans-serif">a) implement a mapping to pure HTTP
request/response model for all MAL interaction patterns. For INVOKE, PUSUB
and PROGRESS use active/long poling if the consumer is not addressable
or behind a firewall (the OASIS WS Make Connection specification can be
the model, which uses additional headers to correlate the messages).</font>
<br><font size=2 face="sans-serif">b) implement a mapping to HTTP request/response
for all MAL interaction patterns except for INVOKE, PUBSUB and PROGRESS.
For these use web-sockets. Web-Sockets are a different protocol than HTTP.
It is a message oriented bi-directional protocol on top of tcp/ip. It uses
HTTP for initiating the connection and then establishes a bi-directional
connection, using the tcp/ip channel below, which was opened by the HTTP.</font>
<br>
<br><font size=2 face="sans-serif">Long polling is clearly less elegant
than web-sockets. At the other side for many of our space domain scenarios
the consumer and provider are known to each other and the firewalls must
be configured anyway.</font>
<br><font size=2 face="sans-serif">If I take the example of ESA data distribution
systems (DDS/EDDS) on the DMZ, even for making a simple http request/response
to the DDS, the consumer IP address must to be added to a white list.</font>
<br>
<br><font size=2 face="sans-serif">The scenarios translate therefore to:</font>
<br>
<br><font size=2 face="sans-serif">1. HTTP Request/Response based mapping
to all MAL interaction patterns: This is either when </font>
<br><font size=2 face="sans-serif">        a)
there are no firewalls involved (not very realistic) : <b><u>No polling
involved, simple http request/response</u></b></font>
<br><font size=2 face="sans-serif">        b)
consumer and provider are known up front and firewalls are configured accordingly
to allow the traffic pass through in both directions (in my opinion more
likely/realistic case): <b><u>no polling involved, simple http request/response</u></b></font>
<br><font size=2 face="sans-serif">        c)
consumers are added and removed dynamically at run-time and firewalls do
not allow out-bound connection initiation from provider side: Only for
this particular case pooling techniques shall be adopted on top of simple
HTTP request/response pattern </font>
<br>
<br><font size=2 face="sans-serif">2. HTTP Request/Response based mapping
to all MAL interaction patterns except for INVOKE/PROGRESS and PUBSUB for
which web-sockets shall be used: this would use web-sockets for any scenario
(even for scenario a and b, where it would not be necessary and one could
do simple http request/response with no polling)</font>
<br>
<br><font size=2 face="sans-serif">3. A mixture of 1 and 2. Baseline is
(1) but for PUBSUB and PROGRESS the consumer can decide if it wants to
use web-sockets or long polling. This would be indicated with a header
field in the initiating HTTP request (which is needed for both cases).
I am not sure if this 3 option is possible without over complicating the
binding.</font>
<br>
<br><font size=2 face="sans-serif">I would like to ask you to</font>
<br>
<br><font size=2 face="sans-serif">a) check the setup of the DMZ and firewalls
in your organisation and tell us if in your today's setup the firwall/IDS
would let web-socket traffic through or would detect and prevent it for
port that is specified as http port (e.g. port 80)</font>
<br><font size=2 face="sans-serif">b) Which of the three options you think
we should take for MAL to http binding.</font>
<br>
<br><font size=2 face="sans-serif">I would appreciate your feedback by
mid September.</font>
<br>
<br><font size=2 face="sans-serif">Kind Regards</font>
<br><font size=2 face="sans-serif">Mehran</font><PRE>This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.
</PRE>