RE: XP Service URIs

Hi Henry,

Sorry for the delay...

> You've done an excellent analysis of the various combinations
> underlying transports (for XP) and intermediaries.

Thank you!

> I think, however, you are suggesting that, rather than having
> one approach to handling URIs in XP, that it should be done
> in various ways depending on the transport protocol and/or
> whether intermediaries are involved.  Please correct me if I
> have misunderstood what you say.

The point is not so much that it *should* be done in several ways but
rather that when XP is used in combination with protocols that are not
transport protocols but application protocols (like for example HTTP and
SMTP), XP inherits the application semantics from these protocols. For
example,

   * From HTTP we get request/response message path model
   * From HTTP we get digest authentication
   * From SMTP we get store and forward with a certain reliability
   * etc. etc.

In fact, this extends to real transports as well like SSL where we get
encryption as one of the services; reliable streams from TCP and so on.

Replicating information in XP headers that is already carried in the
protocol that XP is bound to, can cause consistency problems. For
example, an HTTP redirection status code can change the Request-URI but
if this is replicated in the XP header then that would have to be
updated too.

As an example, your argument could as well have been applied to the
request/response matching that HTTP provides by serializing requests and
responses on the same TCP connection. Without a mechanism for matching
requests with responses expressed as an XP header, it can't easily be
sent over SMTP, say, where there is no "natural" request/response matching.

The good thing is that because we have a "mustunderstand" flag, a service can
of course require the use of putting a URI in an XP header but it is also
possible not to require it but to inherit it from the protocol binding. That
is, we don't loose interop with ebXML as we support it through the
composability model of the envelope.

Henrik

Received on Monday, 27 November 2000 11:48:24 UTC