Re: Intermediary Discussion

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
them.


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