RE: Some basic (naive?) questions about mustunderstand.

Hi. 

There is an alternative to #1 instead of a public directory. This is to
allow only the endpoint to verify that all the must understands=1
have been consumed. Intermediaries that do not execute headers targeted to
them do not generatea fault. This way the sender 
gets all faults at the same time and can do something intelligent much more
easily. However there is still an issue with #2. 

thanks
jay kasi

> -----Original Message-----
> From:	Kasi, Jay 
> Sent:	Wednesday, May 09, 2001 5:25 PM
> To:	xml-dist-app@w3.org
> Subject:	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:42:13 UTC