Re: Comments on XML Protocol Reqs

Hugo Haas writes:

>> I think that it is more a simplicity problem. An 
>> optional/mandatory bit is easy to define; a 
>> combination of and's and or's is more complex
>> to represent and process.

Like Martin, I agree with what Hugo has written, but I think there is a 
perspective from which one can even more strongly support Hugo's case that 
a single mustUnderstand is an effective trade-off:

The nature of an extension must be clearly identified.  In SOAP extensions 
are identified by a URI name, and we may reasonably expect a similar 
mechanism for XP.  mustUnderstand on a header signals that the recipient 
must "understand" the significance of the extension, not necessarily that 
it must blindly choose any particular means of dealing with it.  So, I 
claim that it may be in the nature of "understanding" header "B" to 
realize that it obviates the need to do any explicit processing on header 
"A", even if A itself is marked mustUnderstand. 

Consider two extensions I will call "stronglyAuthenticate" and 
"weaklyAuthenticate", with the former marked mustUnderstand.

        <xp:XP>
                <xp:Header>
                        <wa:authenticate xlmns:wa="...uri for weak auth 
header ..."
                                      xp:mustUnderstand="1">
                                ...
                        </wa:authenticate>
                </xp:Header>
                <xp:Header>
                        <sa:authenticate xlmns:sa="...uri for strong auth 
header ..." >
                                ...
                        </sa:authenticate>
                </xp:Header>

                ... body here...

        </xp:XP>


The recipient is required to understand the significance of weak 
authentication.  A more capable recipient might notice that strong 
authentication eliminates the need to do anything explicit for weak 
authentication, even though that recipient does "understand" the 
significance of weak authentication.

I am not trying to say that one cannot conjure up sensible use cases for 
which some sort of combinatorial  logic might be useful, just trying to 
strengthen the argument for a simple mustUnderstand as a reasonable 80/20 
trade-off that covers a lot of of interesting situations.

Also, a related point: we should be very reluctant to introduce any 
notions of negotiation that involve repeated message exchange, as I 
believe that such negotiations are essentially in conflict with our 
requirement:

R502 
The specification developed by the Working Group must support either 
directly or via well defined extension mechanisms different messaging 
patterns and scenarios. The specification will directly support One-way 
and Request-response patterns as part of permanently and intermittently 
connected scenarios. 

Doing negotiation via repeated message exchange generally does not work 
well in an intermittently connected scenario.  mustUnderstand does work 
reasonably well in such situations.

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

Received on Saturday, 6 January 2001 11:00:10 UTC