Re: Abstract Model contribution for Intermediairies (repost)

Jean-Jacques,

A few comments. First of all, is this an abstract model (something to
help understand the concepts), or is it a proposal for specification?


>   2. The XML Protocol message specifies a set of intermediaries to
>      visit, and the order in which they will be visited. The list of
>      intermediaries, as specified by the sender, is called the
>      initial path.

It would probably be good for us, in all documents, to refer to them
explicitly as XMLP Intermediaries, rather than generic
'intermediaries'. There are many kinds of intermediaries at many
different layers, and their use is often intertwined; we need to be
precise about what we're talking about (I'm very guilty of this!)


>   3. An XML Protocol intermediary may modify the path before
>      forwarding the message to the next intermediary in the chain,
>      and hence possibly change this next intermediary. This permits
>      to cater for cases where the full path is not known in advance,
>      for example where there exists a proxy or caching server along
>      the way.
>
>   4. An intermediary may only add to the path. More precisely, it
>      may only add one or more nodes to visit before the original
>      next hop.

These seem to contradict each other. Please explain?

>   5. An intermediary must record its identity/address within the
>      message, before forwarding it to the next intermediary in the
>      path.  This permits to record the actual route followed by the
>      message.
>
>   6. An XML Protocol response follows the same path as the
>      corresponding request, but in reverse order.
>
>   7. The recorded route is used to compute the reverse path.

Does this imply that the request reciever will impose an XMLP-layer
path on the response message? If so, how? 

I think you're trying to say that the response should follow it's
natural path through an intermediary; if the transport binding (e.g.,
HTTP) defines a request/response pattern on the connection, XMLP
Messages should follow it.


>   8. When a fault occurs at an intermediary, further message
>      forwarding is cancelled, and the fault is delivered as a
>      response through the reverse path.

These are all good ideas for a particular kind of interaction, but
they unnecessarily restrict the use of XMLP intermediaries. Some
applications may wish to have XMLP intermediaries with different
behaviours, such as different fault-handling behaviour, it may not
need route recording, etc.

We need to specify enough to enable the protocol to function, but no
more; the test we should use is whether features such as these enable
the protocol to meet its requirements. 

Cheers,



-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA USA)

Received on Tuesday, 13 March 2001 14:57:30 UTC