W3C home > Mailing lists > Public > xml-dist-app@w3.org > November 2000

RE: XP Service URIs

From: <Noah_Mendelsohn@lotus.com>
Date: Wed, 29 Nov 2000 15:19:11 -0500
To: "Henrik Frystyk Nielsen" <frystyk@microsoft.com>
Cc: hlowe@omg.org, ohurley@iona.com, xml-dist-app@w3.org
Message-ID: <OF9C92CBDA.5940D4EB-ON852569A6.00521C41@lotus.com>
I would like to strongly second Henrik's general principle that  encoding 
the destination of a message  (I.e. identification of transport endpoints, 
if that is the right terminology) be done in a binding specific manner, 
and not in the XP header.  Indeed, the web architecture suggests that most 
modern bindings will/should do this using URI mechanisms, but where they 
actually put the URI in a message (or whether they need to transmit it at 
all) should be binding specific.  Indeed, one can imagine transports 
(point-to-point links, for example) in which the target need not be 
carried in the message at all.

At least as important is the fact that there can be processing overhead in 
"cracking" the XML-format XP header.   I think it is undesireable that, 
when running in an environment such as HTTP that has its own headers and 
addressing mechanisms, we would require routing code to parse the XP 

One other point:  we are designing wire formats, not APIs.  If someone 
ever kicks off, for example, a workgroup to define a standard Java API for 
sending XP messages in a transport independent manner, I would strongly 
suspect that such an API would indeed be biased toward representing 
endpoints as URI addresses.  However, the implementations of that API 
would rely on the particular XP bindings to determine the means, if any, 
used to represent the address "on the wire".

Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
Received on Wednesday, 29 November 2000 15:27:17 UTC

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