FW: a question about mustunderstand.

If people are not interested in this conversation please say
so and I'll take it off-line - but I did want to discuss it
a little bit more.

Noah,
  You mentioned that because of the "cache manager" scenario
the current targeted-MU semantics of SOAP makes sense and should
stay (paraphrasing a bit).  And I agree that it is a valid
scenario and needs to be supported, however the case of
a targeted-MU that never hits its actor causing a fault once
the message hits the ultimate destination is a valid scenario
as well.
  To me it's a question of what should the default behavior
of SOAP be.  Both can be supported, either by the core spec
or with an extension.  So it seems like it should be a question
of which one should be 'default' and which one would require an
extension.  And of course you know what I think.  8-)
  Let me explain why...given that core SOAP does not allow
the client to route a message he is basically at the mercy
of the SOAP nodes in the message path to route the message
appropriately.  Now, combine this with:
   Elements tagged with the SOAP mustUnderstand attribute
   with a value of "1" MUST be presumed to somehow 
   modify the semantics of their parent or peer elements. 
   Tagging elements in this manner assures that this change 
   in semantics will not be silently (and, presumably, 
   erroneously) ignored by those who may not fully 
   understand it.
from the SOAP spec.  To me this is an admission that MU's
are pretty darn important and ignoring them is a serious
violation - yes I know the above talks about what do to (or 
to not do) within a single SOAP node once the MU reaches
its actor - this does not apply to the entire message or
entire message path as a whole.
  However, when I combine the fact that MU's are important
with the fact that the client has no way of routing 
messages (in the core spec) I'm left with the question of
what would the client like to see happen if a targeted
MU never reaches its actor?  And I just can't help but
think that a vast majority of the cases the client will
want to know that his MU header was ignored.
  So, let me repeat it - I do see your use-case of the
"cache manager" being possible, but it just don't see it
as all that common.  I just can not believe that very 
many clients will want to send out a message with
MU semantics that may or may not be processed, and be
very happy about it.  The entire notion that the client
would be happy if the actor was never hit at all, but
unhappy if the MU semantics were not understood on the
off chance that the actor was hit, just seems strange 
to me.
  It seems to make much more sense to me that SOAP
should take a much more conservative approach and
error on the safer side by saying "unprocessed targeted MU's
reaching the ultimate destination should result in a
fault".  And of course, support the current behavior through
an extension.  It's all just a question of what's the 
default going to be and I'd choose the far more likely
desired behavior.
-Dug