W3C home > Mailing lists > Public > xml-dist-app@w3.org > February 2001

Re: Intermediary Discussion

From: Mark Nottingham <mnot@akamai.com>
Date: Wed, 7 Feb 2001 13:09:33 -0800
To: Bob Cunnings <cunnings@lectrosonics.com>
Cc: xml-dist-app@w3.org
Message-ID: <20010207130929.A29221@akamai.com>

Some devices may not have the application-specific knowledge to
process blocks in the correct order. For example, if a message
includes an "encryption" block and a "add user context" (say, from a
database) module, and they're being processed by an intermediary
that's configured by the client add these services, the intermediary
won't know the proper order to apply the services in; it just has a
collection of service modules available to apply when clients request

On Wed, Feb 07, 2001 at 01:38:15PM -0700, Bob Cunnings wrote:
> Just curious... what is the reasoning behind this assertion? I only
> ask because the (currently undefined) interface between XP
> processors and XP Module processors will be profoundly influenced
> (I think) by this requirement.  I suppose that in the simplest
> case, the extension blocks would be considered to be orthogonal to
> each other and the module processor(s) involved wouldn't care about
> ordering. On the other hand, of course it may be true that
> dependencies exist between the extension blocks. But why not let
> the XP processor sort all that out, since it has the required
> app-specific knowledge, and dispatch to the module processors as it
> sees fit? My worry is that such a rule might lead to fragility in
> the presence of intermediaries who manipulate the header contents.
> They might then inadvertently break the ordering intended for
> "other" actors downstream. A sufficiently robust system might be
> quite complicated.
> I am assuming that you are talking about application level
> extension block processing, not XP level. Please let me know if I
> am misunderstanding the scope of the question above.

Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA)
Received on Wednesday, 7 February 2001 16:10:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:11 UTC