Some basic (naive?) questions about mustunderstand.

Hi. 

I am new to this working group. I am following the discussion on
mustunderstand. I dont claim to have read all of it (they are long 
threads and I joined in the middle!!!!), but some questions immediately pop
out at me as a practicing architect building BtoB 
exchanges.

1. I believe the main reason for an extension mechanism is a way for the
sender and receiver and every router in between 
    to be able to operate different versions of software. This is truely
important in a distributed system. However how is the 
    sender ever supposed to know if some header with a mustunderstand=1 will
work or not? This is a game of russian 
    roulette. He will have to keep track of all previously rejected messages
and keep adjusting the mustunderstands to 
    send a single message. He has to constantly keep retrying different
options as they get rejected, and this is not a reliable 
    way to communicate. It seems to me that the way around this is for the
sender to discover the capabilities of the endpoint 
    and all hops in between through web public directories (possibly ebXML
R&R, UDDI or others) so it knows definitely what to 
    specify before generating the message in the first place. It does not
seem to me that mustunderstand=1 is useable. 
2. We seem to be leaning towards the endpoint checking if all the
mustunderstand=1 has been consumed. 
    This implies that all actors who consume it have to somehow note in the
header that they have consumed 
    it. This is probably done by changing the corresponding
mustunderstand=1. Doesnt this interfere with 
    signing? We are forced to use XMLDSIG and exclude these fields instead
of PKCS#7.  
3. We seem to be leaning towards a partial order of execution of must
understand. It seems to me that the endpoint 
    that sent a message is just a dumb application (say a moble device) and
should not have control over when for example 
    logging gets done, when billing events are generated, when
nonrepudiation events are generated, etc. These are policy decisions 
    controlled by the middleman in a brokered exchange. In the case of a
direct point to point exchange, the sender or receiver 
    executes these. If it is the sender, clearly there is no reason for
partial order specification. If it is the receiver, it probably
    wants to impose a uniform policy across all senders.

Received on Wednesday, 9 May 2001 20:25:52 UTC