W3C home > Mailing lists > Public > xml-dist-app@w3.org > February 2001

Re: INT: Re: Intermediary Discussion

From: Martin Gudgin <marting@develop.com>
Date: Wed, 7 Feb 2001 08:38:21 -0000
Message-ID: <002501c090e1$56223e60$0300a8c0@arbitrary>
To: "Mark Nottingham" <mnot@akamai.com>
Cc: "XML Protocol Comments" <xml-dist-app@w3.org>

----- Original Message -----
From: "Mark Nottingham" <mnot@akamai.com>
To: "Martin Gudgin" <marting@develop.com>
Cc: "XML Protocol Comments" <xml-dist-app@w3.org>
Sent: Wednesday, February 07, 2001 12:13 AM
Subject: Re: INT: Re: Intermediary Discussion

> > Open questions/issues...
> >
> > Do XP Intermediaries also sit between the sender of the response
> > and the ultimate receiver of that response? And hence also process
> > the response message assuming one exists.
> I think it depends very much on the transport binding, the message
> exchange pattern, and the nature of the intermediary. Some will
> require both messages to pass through the intemediary (e.g., HTTP
> requires request/response), while it's conceivable that another
> MEP/transport binding could do asymetric routing.

I guess I should have said 'Can XP Intermediaries also sit...' rather than
'Do XP Intermediaries also sit...'. MY point being that if we allow for the
possibility then we need to have a design that supports that possibility.

> I think this is why I'd like to see formalized requirements for
> transport bindings as a class, and a detailed description of the
> constraints they put on XP and the higher-level application,
> especially thorugh the message exchange pattern(s) implied by the
> binding. A lot of it will be obvious, but some won't.

One of the things the Stuart Williams, John Ibbotson and I have discussed is
the idea of defining an abstract model for transport bindings; what are the
properties of bindings in general. Then of course we need to provide
mappings onto concrete transports.

> Whether or not the messages will be processed on both the request and
> response is yet another issue; some will do just requests, some just
> responses, some both. Some may choose not to modify the message at
> all, based on its semantics, the time of day, phase of moon, etc.
> Seems more of an Web Service-level issue than XP.

The last sentence seems to argue against intermediaries in the 'XP Layer'
and for intermediaries at a higher layer. Was this your intent?

> > If a given intermediary is the 'target' for more than one extension
> > block in an XP message does a processing order need to be defined
> > and is so how do we define it?
> I think so. Good question ;)
> > 1.    Taken from Hugo's mail ( thanks Hugo! )
> I like this one the best.
> > 2.    Slight amendment to the above to add notion of addressability
> It can be addressable, but this implies that it must be. An
> intermediary may need/want to perform processing that isn't
> explicitly triggered in the message.

I think I would argue that if an intermediary cannot be 'addressed' from
within an XP message then that intermediary *must* be above the 'XP layer'
and therefore our spec will have little ( if anything ) so say about it.

> > 3.   Slight amendent to 3 to make the possibility of multiple
> > intermediaries more explicit
> "towards" in #1 implies multiple intermediaries, but I see your
> point.


Agreed entirely, I wasn't saying that Hugo's initial wording didn't cover
multiple intermediaries, I was just being more explicit here...


Received on Wednesday, 7 February 2001 03:42:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:11 UTC