Re: Abstract Model contribution for Intermediairies (repost)

Mark,

Thanks for your comments. Details below.

Mark Nottingham wrote:

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

This was an attempt at summarising, consolidating, and solidifying some of
the ideas/concepts that have been floating around. It was not intended as
a specification, but more as a summary of the concepts that the
specification might be built on, in a manner similar to Mark Jones'
earlier draft on modules. I am sorry this came across differently.

> 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 [...]

Point taken.

> >   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?

Point 3) is the more general statement, it allows XMLP Intermediaries to
make arbitrary changes to the path. Point 4) is a restriction on 3), with
the aim of constraining what XMLP Intermediaries can do. The two options
are there so we can think about the issue, and later on make an informed
decision.

> >   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?

Yes, this is what I had in mind. I would prefer if there was as much
symmetry as possible between the behaviour of requests and that of
responses. In particular, I am concerned by the fact that a response might
otherwise travel through an entirely different set of XMLP Intermediaries
on the way back, or through no XMLP Intermediaries at all. Also, I would
like support for the scenario where an XMLP Intermediary processes some of
the blocks in the response, and adds blocks of its own, much like it can
do for outward requests already.

> >   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.

Hum... I understand what you are saying; but there is also probably a
watershed somewhere, and I am slightly hesitant to cross that line, and
end up with a protocol that is so "liberal", that it becomes easy to shoot
oneself in the foot.

> 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,

Jean-Jacques.

Received on Wednesday, 14 March 2001 05:27:33 UTC