W3C home > Mailing lists > Public > public-ws-addressing@w3.org > February 2005

RE: Thoughts on TAG issue EndpointsRef47

From: <paul.downey@bt.com>
Date: Mon, 7 Feb 2005 20:29:58 -0000
Message-ID: <2B7789AAED12954AAD214AEAC13ACCEF2709DFBE@i2km02-ukbr.domain1.systemhost.net>
To: <Savas.Parastatidis@newcastle.ac.uk>, <tom@coastin.com>, <jmarsh@microsoft.com>
Cc: <public-ws-addressing@w3.org>
+1, seems likely i might want my 'address' to point to a distribution list,
or a pointer redirected via configuration in my server.

	-----Original Message----- 
	From: public-ws-addressing-request@w3.org on behalf of Savas Parastatidis 
	Sent: Mon 07/02/2005 10:27 
	To: tom@coastin.com; Jonathan Marsh 
	Cc: public-ws-addressing@w3.org 
	Subject: RE: Thoughts on TAG issue EndpointsRef47

	Hi Tom,
	> If what Gudge is describing is required, we might consider a multiple
	> Protocol profile structure
	> for the "EPR".   This is what IONA was getting at.  We could represent
	> all the variant
	> transport addresses required in the EPR.
	> Otherwise I am not at all clear on how the "logical" uri gets mapped
	> the various
	> transport addresses required for the variants desired.
	There may not be a need to map the "logical" URI to a specific transport
	address. Imagine a service with a logical address
	'urn:chocolates:service' which sells chocolates. You want to buy a
	chocolate from a peer-to-peer network of services without caring about
	the actual endpoint of the service that will serve you.
	All you have to do is just give this message to the P2P network which
	will know how to do deal with it. No need to go from a logical to a
	transport-specific address for this service. But even if you had to,
	there is a use case for using logical addresses as indexes in registries
	where transport-specific endpoints can be found at runtime ("give me all
	the transport endpoints of the urn:chocolates:service service").

Received on Monday, 7 February 2005 20:28:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:28:23 UTC