Re: Must understand mustUnderstand proposal

My observations...

    > 1.    How do we make sure that the ultimate destination has processed/can
    > process all of the mustUnderstand='1' headers targeted at it? Or do we even
    > need to bother? Will knowing that intermediaries have processed their
    > headers, because there are no headers left in the message that are not
    > targeted at the ultimate destination, be enough?

Only the ultimate destination needs to do the checking.  Any block
that has mustUnderstand='1' and is not targetted at the ultimate
destination is treated as a "mustHappen" violation at the ultimate
destination.

[BTW: I still wonder if it would be useful to allow the blocks marked
mustUnderstand to independently specify whether they mustHappen (the
default could be mustHappen='1').  There may be cases in which the
routing path can permissibly fail to reach an appropriate actor for a
block, but if it does reach the actor the block must be handled.]

    > 2.    Do we want to deal with the 'badly written' XMLP/SOAP implementations
    > that claims to have processed a header but in fact has not? See mail from
    > Frank DeRose[2] for more detail on this question.

Punt on this one.  I agree with Hugo and Stuart.

    > 3.    Does an intermediary *always* remove the headers targeted at it? If
    > not then I think we need some way of annotating them as 'processed'.

Stuart summed this up pretty well, too.  By processing a targeted
block, the intermediary accepts the mustUnderstand contract and
provides the intended semantics (or faults).  Any new inserted blocks
represent new contracts with subsequent actors.

    > 4.    What do we do about ordering? This is an issue particularly at the
    > ultimate destination. What if this header is encountered before other
    > headers marked mustUnderstand='1'? What if it is encountered after?

We had a lengthy discussion about sharing blocks among modules in the
AMG.  It is my understanding that SOAP allows access to other blocks
during the processing of a targeted block.  (These blocks don't have
to even be targeted at the same actor.)  Although the possibilities
aren't really enumerated in the SOAP spec, one can imagine several
mechanisms for a handler to get at blocks in a message:

  (a) an 'id' and 'href'/'idref' mechanism
      (a1) which allows backward references
      (a2) which allows backward references
      (a3) which allows forward and backward references

  (b) an API for crawling over
      (b1) the blocks seen thus far
      (b2) all blocks received at the node

Clearly, these mechanisms have different performance and resource
implications.  (b2) is quite powerful, and seems to be the kind of
thing required here, since the mustHappen task is a kind of
meta-activity that is iterating over blocks of every semantic stripe.
(b1) would be appropriate if you could guarantee block order and can
ensure that the mustHappen checking block follows all other (header)
blocks.

Questions:

 Could we do the checking in the first body block, rather than
 as a header block?

 Where are blocks allowed to be inserted by intermediaries?  If they
 are permitted anywhere, then even if the sender puts the mustHappen
 checking header in as the last header, an intermediary could place
 a mustUnderstand header lexically after it, requiring (b2) rather than
 (b1).

In general terms, more fundamental questions are:

 Is it important for semantic or processing reasons for a processor
 to be able to statically determine or limit which blocks/attachments
 it will need to access?   Alternatively, all such knowledge might
 only be captured procedurally in the handlers, free to access
 anything that a general access API allows.

 Can a processor (intermediary) statically determine which
 blocks/attachments are still needed by subsequent processors?

A processor may also benefit from a model of block access when it
dispatches handlers:

 Is it important for semantic or processing reasons for a processor
 to be able to statically determine or limit which blocks a given
 handler will need to access?


    > 5.    This header needs to be marked mustUnderstand='1' :-)

Right!

    > 6.    This extension must be able to work by examining *only* the message
    > that arrives at the ultimate recipient.

    > 7.    Is processing this at the ultimate destination enough? Or do we need
    > to have evaluate this at every intermediary? <gulp>

It ought to be enough to check at only at the ultimate destination.
We depend on the semantics of mustUnderstand being handled correctly
by the intermediaries and the ultimate destination for targeted
blocks.  We are really only concerned with checking the mustHappen
condition.


Mark A. Jones
AT&T Labs - Research
Shannon Laboratory
Room A201
180 Park Ave.
Florham Park, NJ  07932-0971

email: jones@research.att.com
phone: (973) 360-8326
  fax: (973) 360-8970

Received on Thursday, 3 May 2001 15:15:40 UTC