DR8xx

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.

On example is in section 3.4.2.

3.4.2:
> To enable the interposition of processing intermediaries into the message
> path, two core requirements must be met;
>
> * Targeting - XML Protocol must define mechanisms to enable identification
>   of message components to be processed by a particular processing
>   intermediary. Message components must be able to be targeted at one or
>   more processing intermediaries.  [R806]

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.

Maintaining separate codebases for active proxies and forwarding servers has
tradeoffs.  For the many P2P designs using symetrical message formats, there
would not be a simple transform between their protocols and product of this WG.

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.

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

_________
Lucas Gonze
WorldOS Corporation
109 Ainslie Street
Brooklyn, NY 11211
(917) 805-4391
lucas@worldos.com
www.worldos.com


> -----Original Message-----
> From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]On
> Behalf Of Mark Nottingham
> Sent: Friday, November 10, 2000 9:58 PM
> To: XML Distributed Applications List
> Cc: Henrik Frystyk Nielsen
> Subject: Proposed changes to 8xx
>
>
>
> Comments welcome. I've tried to incorporate ballot feedback; if you still
> have issues w/ intermediaries, please bring them to the group ASAP.
>
> Changes:
>   R 800 - dropped (redundant)
>   DR 811 - new (explict requirement for processing intermediaries)
>   DR 805 R807 DR809 DR810 - moved to use cases (to be presented)
>   R802 R803 R806 R808 - light massaging (no semantic changes)
>
> [EDs: Please respect bullet list formatting.]
>
>
> <requirements>
>
> 3.4 Intermediaries
>
> Intermediaries are essential parts of building distributed systems that
> scale on the Web. Because XML Protocol separates the message envelope from
> the transport binding, two types of intermediaries are possible; transport
> intermediaries and processing intermediaries.
>
> 3.4.1 Transport Intermediaries
>
> Transport intermediaries are interposed by a transport binding, as part of
> the message exchange pattern that it implies. They do not define a
> processing model for messages; they only operate as part of the transport
> binding. Transport intermediaries are typically used as message routing
> mechanisms.
>
> XML Protocol must not preclude the use of transport bindings that define
> transport intermediary roles such as store-and-forward, proxies and
> gateways. [R803]
>
> 3.4.2 Processing Intermediaries
>
> Processing intermediaries are XML Protocol processors; they process the
> message, but are not the ultimate recipient of it. They may be colocated
> with transport intermediaries, using them as a routing mechanism, or they
> may use in-message routing mechanisms. Processing intermediaries are
> typically used to transform, partially process or add functionality to
> messages en route.
>
> XML Protocol must define and accommodate processing intermediaries. [DR811]
>
> To enable the interposition of processing intermediaries into the message
> path, two core requirements must be met;
>
> * Targeting - XML Protocol must define mechanisms to enable identification
>   of message components to be processed by a particular processing
>   intermediary. Message components must be able to be targeted at one or
>   more processing intermediaries.  [R806]
>
> * Reporting - XML Protocol must enable the generation of status and/or error
>   messages by processing intermediaries, and enable propagation and proper
>   identification of status and/or error messages through processing
>   intermediaries.  [R808]
>
> XML Protocol must also enable processing intermediaries to locate and
> process the portions of messages intended for them without reading or
> processing the entire message. [R802]
>
> </requirements>
>
>
>
> --
> Mark Nottingham, Research Scientist
> Akamai Technologies (San Mateo, CA)
>
>

Received on Sunday, 12 November 2000 14:58:41 UTC