- From: Henry Lowe <hlowe@omg.org>
- Date: Wed, 22 Nov 2000 13:23:40 -0500
- To: "Henrik Frystyk Nielsen" <frystyk@microsoft.com>
- Cc: Oisín Hurley <ohurley@iona.com>, <xml-dist-app@w3.org>
Henrik, You've done an excellent analysis of the various combinations underlying transports (for XP) and intermediaries. 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. In the interest of eliminating complexity (and possible protocol layering violations), I would suggest that we adopt one way of dealing with URIs, i.e., put them in the header -- the URI is then available for routing (in the case of intermediaries) and any sort of software mapping XP to whatever form of transport. Of course, this also has advantages for interop with ebXML :-) Best regards, Henry ------------------------------------------ At 07:40 AM 11/22/2000 -0800, Henrik Frystyk Nielsen wrote: >> >Allowing optional expression of destination URI sounds like >> a good idea. >> >> In fact, I think mandatory expression of the destination URI is even >> better. There has been some conversation about the need to identify >> the service instance endpoint in a separate manner to the protocol >> instance endpoint. That is, to identify the XP processor for whom >> the message is intended. > >I like the idea of requiring that there be a *description* of how the ><ultimate XP receiver> can be obtained from either the <xp binding> or >the <xp message>. I don't like the idea of requiring that the >request-uri must be in the <xp message> - it is just as valid that it be >indicated by the <xp binding>. > >Note, that I have emphasized the terms defined by [1] by using <foo> >notation - I encourage people to use these terms (and to comment on the >terms document [1]). > >There is an illustration of the <xp message path> model in [2]. An <xp >receiver> is identified by a URI and the <ultimate xp receiver> is an ><xp receiver> as any other receiver in this regard. That is, we only >need one URI for the <ultimate xp receiver>. > >The next question is where to carry that URI. If using XP in combination >with HTTP, SMTP or similar, it makes sense to use the mechanisms already >defined by these protocols to indicate the destination. The reason is >that because HTTP, SMTP etc. indicate the destination of HTTP and SMTP >messages themselves, it doesn't matter what is written in the <xp >message>: > > xp sender ---> ultimate xp receiver > http >or > > xp sender ---> ultimate xp receiver > smtp > >However, if there is no such mechanism (for example if running XP >directly on top of TCP) *or* one wants to use multi-hop links with >multiple <xp bindings> like this > > xp sender ---> xp intermediary ---> xp intermediary ---> ultimate xp > http smtp http receiver > >then it makes sense to say that there must be a mechanism within the <xp >message> indicating who the <ultimate xp receiver> is. > >Sp, as it depends on the <xp binding> and the <xp message path> where to find >the URI of the <ultimate xp receiver>, it makes sense to have a mechanism >defined as an <xp module> where it can be marked as either optional or >mandatory. That way, it can be used when needed and not used if not needed. > >Henrik > >[1] http://www.w3.org/2000/xp/Group/xp-terms-01.html >[2] http://www.w3.org/2000/xp/Group/xp-terms-01.html#N3030 > > >
Received on Wednesday, 22 November 2000 13:05:41 UTC