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

I'd imagine this would be a form of targetting where a special URI
pointed to all intermediaries. For example:

<SOAP-ENV:Header>
  <t:foo actor="xmlp-intermediary-scheme-first-guess:all-intermediaries">
    [...]
  </t:foo>
</SOAP-ENV:Header>

Or somesuch, combined with the ability to either a) know that the
handler won't strip the element, because of the module's
specification, or b) say that the handler shouldn't strip the
element.

SOAP talks about contractual relationships between intermediaries,
and the inability for a particular intermediary to extend a contract
given by a previous hop. I suspect that the intent was that
targetting could be passed down the chain by using the loophole
inherent there - rewriting a new contract that exactly matches the
old one. However, this approach requires the intermediary
applications to know enough to re-target the block when appropriate.


On Wed, Mar 14, 2001 at 09:27:51AM -0500, marwan sabbouh wrote:
> Hi;
> 
> 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?
> 
> marwan
> 
> 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)

-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA USA)

Received on Wednesday, 14 March 2001 14:28:00 UTC