W3C home > Mailing lists > Public > xml-dist-app@w3.org > November 2000

Re: DR8xx

From: Mark Nottingham <mnot@akamai.com>
Date: Mon, 13 Nov 2000 12:12:48 -0800
To: Lucas Gonze <lucas@worldos.com>
Cc: XML Distributed Applications List <xml-dist-app@w3.org>
Message-ID: <20001113121247.C16169@akamai.com>
On Sun, Nov 12, 2000 at 02:50:00PM -0500, Lucas Gonze wrote:

> 3.4:
> "Experience from HTTP and other protocols has shown that intermediaries
> cannot be implicitly defined but must be an explicit part of the message
> path model for any data encapsulation language."
> 
> Per the charter:
> * The envelope and the serialization mechanisms developed by the Working Group
> may not preclude any programming model nor assume any particular mode of
> communication between peers.
> * Focus must be put on simplicity and modularity and must support the kind
> of extensibility actually seen on the Web. In particular, it must support
> distributed extensibility where the communicating parties do not have a
> priori knowledge of each other.
> 
> There may be a contradiction between these.

I think the crux here is "particular mode of communication", which the
working group is interpreting as request/response, publish-and-subscribe,
unicast, multicast, etc. I don't see an inherent contradiction between this
and the goal of simplicity and moduluarity; it must _support_ situations
where there is not a priori knowledge, not require it.


> On example is in section 3.4.2.
> 
[snip]
> 
> Whether the recipient of a message is an intermediary may not be knowable
> in advance.  It is reasonable for an intermediary to make an active
> decision whether to process or forward a message.  An active proxy, one
> which may contain CGI scripts, is one example.  A CGI script that
> optionally may decide to forward a request elsewhere is another example. 
> Because there are instances of both of these in use, this appears to be
> the kind of extensibility actually seen on the Web.

Very true; there's nothing stopping an intermediary from providing its own
processing that's triggered externally, rather than in the protocol.
However, the ability to specify processing instructions for intermediaries
in-message is also useful in some scenarios.


> I suggest that the targeting clause be amended to require that message
> components targeted at intermediaries be orthogonal to message components
> targeted at endpoints.  A time to live header is an example.  It always
> affects nodes acting as intermediaries, and never affects nodes acting as
> endpoints.

Wouldn't it be better to leave that decision to individual components? While
this may be true for what you're visualizing, there may be others that need
this capability.

We're trying to describe a flexible framework, and it artificial limits will
only hamper it.


> I am not a member of the WG, so I hope that this input is appropriate.

Very much so; that's why it's being done in public. 

Cheers,


-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA)
Received on Monday, 13 November 2000 15:13:20 GMT

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