Re: Comments on XML Protocol Reqs

The primary thing is meeting the user expectations and needs for reliability,
interoperability and availability.  Simplicity through avoidance of repeated
messages suggests the initial negotiation must also support continuation of
intermittently connected scenarios and the potential changes in bindings
or state.  As one solution, an appropriate URI scheme may avoid costly
exhaustive options-negotiation, leverage external supports, and allow
encapsulation of error information or status.

> Re: Comments on XML Protocol Reqs
>
> From: Noah_Mendelsohn@lotus.com
> Date: Sat, Jan 06 2001
>
> *Next message: David Ezell: "DR305 -- proposed disposition"
>
>    * Previous message: Dave Winer: "SOAP meets RSS"
>    * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
>    * Other mail archives: [this mailing list] [other W3C mailing lists]
>    * Mail actions: [ respond to this message ] [ mail a new topic ]
>
>   ------------------------------------------------------------------------
>
> From: Noah_Mendelsohn@lotus.com
> To: Hugo Haas <hugo@w3.org>
> Cc: duerst@w3.org, frystyk@microsoft.com, xml-dist-app@w3.org
> Message-ID: <OF72CC8FF2.04F07065-ON852569CC.0057D0E2@lotus.com>
> Date: Sat, 6 Jan 2001 10:50:10 -0500
> Subject: 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
> ------------------------------------------------------------------------
>
>   ------------------------------------------------------------------------
>
>    * Next message: David Ezell: "DR305 -- proposed disposition"
>    * Previous message: Dave Winer: "SOAP meets RSS"
>    * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
>    * Other mail archives: [this mailing list] [other W3C mailing lists]
>    * Mail actions: [ respond to this message ] [ mail a new topic ]

Received on Monday, 8 January 2001 17:56:57 UTC