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

Re: Abstract Model contribution for module processing and also for attachments

From: marwan sabbouh <ms@mitre.org>
Date: Wed, 14 Mar 2001 09:27:51 -0500
Message-ID: <3AAF7FE6.13AD3910@mitre.org>
To: Mark Nottingham <mnot@akamai.com>
CC: Yves Lafon <ylafon@w3.org>, Jean-Jacques Moreau <moreau@crf.canon.fr>, "Mark A. Jones" <jones@research.att.com>, "Marc J. Hadley" <marc.hadley@sun.com>, Ray Denenberg <rden@loc.gov>, Ray Whitmer <rayw@netscape.com>, Henrik Frystyk Nielsen <frystyk@microsoft.com>, Stuart Williams <skw@hplb.hpl.hp.com>, David Fallside <fallside@us.ibm.com>, xml-dist-app@w3.org

We are discovering the need for some blocks to be processed by more than
one intermediaries.  An example would be context information, such as
the type of access device, or privacy constraints.  Is there a way for a
header to be read by all intermediaries along the processing path?


Mark Nottingham wrote:
> On Tue, Mar 13, 2001 at 01:45:30PM +0100, Yves Lafon wrote:
> > On Tue, 13 Mar 2001, Jean-Jacques Moreau wrote:
> >
> > > I think there are cases when processed blocks should not be
> > > removed from messages. For example, consider a message that goes
> > > through several intermediaries, and that contains some form of
> > > identification (user/password, certificate, digital signature,
> > > whatever), carried as a block, and used by at least two
> > > intermediaries. It would be wrong for the first intermediary to
> > > remove the block from the message, as it is also needed by the
> > > second intermediary.
> >
> > In that case, targeting information should explicitely say that
> > this particular block is intended for multiple processors.
> I think the client should be *able* to say that it should be removed,
> but won't some modules want to handle this decision internally (i.e.,
> it's in the intermediary's interest to remove the module, not the
> sender's)?
> > If a block has been added for a specific intermediary, and if it
> > doesn't impact on the main one, then it can be safely removed (note
> > that auth can have an impact on cacheability)
> I think that depends on the nature of the auth and caching modules
> defined... while this is a behaviour of the HTTP, it doesn't have be
> be for XMLP, because we have an opportunity to describe how the cache
> should store the object in a much richer fashion.
> --
> Mark Nottingham, Research Scientist
> Akamai Technologies (San Mateo, CA USA)
Received on Wednesday, 14 March 2001 09:28:04 UTC

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