- From: Mark Nottingham <mnot@akamai.com>
- Date: Tue, 13 Mar 2001 08:34:23 -0800
- To: Yves Lafon <ylafon@w3.org>
- Cc: 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>, Marwan Sabbouh <ms@mitre.org>, Henrik Frystyk Nielsen <frystyk@microsoft.com>, Stuart Williams <skw@hplb.hpl.hp.com>, David Fallside <fallside@us.ibm.com>, xml-dist-app@w3.org
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 Tuesday, 13 March 2001 11:34:54 UTC