Re: FW: a question about mustunderstand.

Duglin writes (my apologies if that's not your name...that was my best 
guess from your note):

>> 
>> 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.
Yes, it is reasonable to assume that there will be situations in which 
users wish to catch procesing that is missed because a SOAP message didn't 
go to the intended processing point, but SOAP does not currently attempt 
to solve that problem. 

>>   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.
With respect, in the short run I think it's a question of what the spec. 
says.  It says, "don't do anything at the endpoint if mustUnderstand 
headers for other actors happen to show up. "  You are making the case 
that it should have been written differently, but if we want interop, we 
need to do what the spec says.   Indeed, the protocol workgroup is 
considering mechanisms that would address your concerns, one of which was 
suggested in my earlier note http://lists.w3.org/Archives/Public/xml-dist-app/2001May/0310.html. 

Many of us feel that it would be desireable to provide such function as an 
extension, in the interests of keeping the core protocol small and 
compatible with SOAP v1.1 to the extent possible.  Whether such 
compatibility is achievable is being investigated.

Also, it's my personal belief that doing "mustHappen" (as I call it) 
checking at the endpoint is in general too late.  If headers are directed 
to actors A, B, C, D, E, and A is missed, it can be way to late to notice 
it at endpoint E.   B may do something inappropriate that can't be rolled 
back.  For that reason, I think an effective mechanism will require 
checking at each point along the way.

>> 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.
As I said above, just because it's tempting to read "mustUnderstand" as 
"important and mustHappen", doesn't mean that's what the spec says.  Maybe 
it should, but it currently doesn't.  We are looking for the best way to 
address the need for processing that "mustHappen", which seems related to 
"must happen in the right order", which gets you into questions of message 
routing or at least expressing the dependency graph.

>>   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

To net out my response:  I think we need to analyse this requirement in 
the context of larger issues of message routing.    It's not just 
"mustHappen", it's "mustHappen in the right order".  I personally think 
that MU is definitely useful as it stands in the cases of (a) it' use on 
headers sent to the endpoint, which includes but is not limited to the 
<body> (b) headers sent to "next" and (c) other situations in which one is 
confident of routing and actor naming.  All of these are situations in 
which MU errors will be reliably detected, and so MU can be used for at 
least extensions of this sort.   So, we've got something that has utility 
as it stands.  Changing its interpretation would be a retroactive change 
to the specification and thus break compatibility. 

It is indeed important to provide mechanisms, as you suggest, to ensure 
that essential processing happens in the right order.  The workgroup is 
carefully considering the requirements and possibilities and would welcome 
input on the most appropriate solutions (please do try to read the email 
threads before commenting, as there has been a considerable amount 
discussed already, with quite a range of positions represented.)  By the 
way, there is a workgroup meeting coming up and I wouldn't be surprised 
that some progress will be made on these issues soon.  Thank you.

------------------------------------------------------------------------
Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------

Received on Tuesday, 5 June 2001 02:39:16 UTC