- 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>
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 UTC