Subject: [Ecrit] [Fwd: Re: [Uri-review] IETF ECRIT Working Group: LoST URI Scheme --- Review Needed]

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 01 Feb 2007 15:49:47 -0500

FYI

-------- Original Message --------
Subject: 	Re: [Uri-review] IETF ECRIT Working Group: LoST URI Scheme --- 
Review Needed
Date: 	Thu, 1 Feb 2007 15:29:40 -0500
From: 	Mark Baker <[email-masked]>
To: 	Hannes Tschofenig <[email-masked]>
CC: 	[email-masked], "Marc Linsner" <[email-masked]>
References: 	<[email-masked]>

I think section 4 should be expanded to follow the guidelines in RFC
4395 (BCP 115); there's a lot of missing information that we need to
properly review it.

Also, as a comment on the protocol, I find it unfortunate that LoST is
using HTTP as a transport protocol when it appears, after a cursory
read through the draft, that HTTP could be used perfectly well as an
application protocol.  If it were, the implications to the URI scheme
would be different of course; you probably wouldn't need a new one,
AFAICT.

If you are going to continue to use HTTP for transport, I think you
should defend that choice with reference to RFC 3205 (BCP 56).

Mark.

On 2/1/07, Hannes Tschofenig <[email-masked]> wrote:
> Hi all
>
> in the IETF ECRIT working group we have done work on a protocol called
> LoST. The description can be found in:
> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-03.txt
>
> In Section 4 we define the LoST URI scheme.
> The IANA considerations can be found in Section 16.5.
>
> We would like to solicit feedback since we are getting close to finish
> the document.
>
> Ciao
> Hannes & Marc
>
>
> _______________________________________________
> Uri-review mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/uri-review
>

-- 
Mark Baker.  Ottawa, Ontario, CANADA.         http://www.markbaker.ca
Coactus; Web-inspired integration strategies  http://www.coactus.com

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Andrew Newton <[email-masked]>
Date: Thu, 1 Feb 2007 16:37:11 -0500

Instead of going down the path of trying to get 4395 compliance, I  
think a better idea is to drop the LoST URI.  I'm unsure when and  
where it would ever by typed in.  It isn't needed for discovery or  
resolution.  And if we find we do need one later, we can always  
register it at that time.

-andy

On Feb 1, 2007, at 3:49 PM, Hannes Tschofenig wrote:

> Subject: 	Re: [Uri-review] IETF ECRIT Working Group: LoST URI  
> Scheme --- Review Needed

---

From: Ted Hardie <[email-masked]>
Date: Thu, 1 Feb 2007 15:16:37 -0800

At 4:37 PM -0500 2/1/07, Andrew Newton wrote:
>Instead of going down the path of trying to get 4395 compliance, I think a better idea is to drop the LoST URI.  I'm unsure when and where it would ever by typed in.  It isn't needed for discovery or resolution.  And if we find we do need one later, we can always register it at that time.
>
>-andy

I disagree, as I think we need that level of indirection now.  At minimum, we would
want to do a provisional, to grab what we think we need (but allow for change).
I've replied to Mark on the uri-review list (reproduced below). 
				Ted

>4395 (BCP 115); there's a lot of missing information that we need to

Sorry about that; I actually put together a provisional registration
some time ago, then decided against sending it, as there were still
some aspects of the URI scheme that were up in the air.  Then the
urn stuff seemed more urgent, and I lost track.  Mea culpa, mea culpa,
mea culpa maxima.

As it stands, the registration template would look like this:

 URI scheme name.
    "lost" is requested

   Status.
      Permanent is requested

   URI scheme syntax.
     	
      LoST-URI = "lost:" host

     'host' is defined in Section 3.2.2 of RFC 3986 [7]
	
   URI scheme semantics.

      The "lost" scheme is intended to be used in order to identify
    the target of a LoST query, as described in draft-ietf-ecrit lost.
    Where the host portion of a the lost scheme is not IP address,
    the URI processor is expected to use U-NAPTR [12] using the
   U-NAPTR specification described below to obtain a URI
   (indicating host and protocol) for the applicable LoST service.
   Current work describes the URI target derived from the
   U-NAPTR lookup as either HTTP or HTTPS, but this may be
   extended in the future to other URI schemes if other
   transports are defined.

   Encoding considerations.

     There are no special encoding considerations here, other than
     those set out in 3.2.2 .  The working group expects that a
     lost URI using a registered name will commonly be using
    the DNS, rather than one of the resolution implementations
    mentioned in 3.2.2 and strongly urges hose deploying LoST to follow the
    recommendation of 3.2.2 that: "URI producers should use names
   that conform to the DNS syntax, even when use of DNS is not immediately
   apparent, and should limit these names to no more than 255 characters in length"

   Applications/protocols that use this URI scheme name.

     A lost URI may be carried by any protocol that intends to notify
     the recipient that lost service is available at the specified host.
     Commonly, this will mean in configuration protocols, although
     it might occur in plain text or html as a reference.

   Interoperability considerations.

      No special considerations.

   Security considerations.
    
     The security considerations set out in RFC 3986 apply.  Additionally,
     because this scheme uses U-NAPTR to resolve non-IP address host names,
     the security considerations of RFC 3958 (which U-NAPTR extends) apply.

   Contact Person

   Ted Hardie, [email-masked]

   Change controller.

     The IESG, delegated to the ECRIT WG if still extant.

   References.

I will update the protocol document with this text, after incorporating
any further comments.

>using HTTP as a transport protocol when it appears, after ...
>...snip...
>... protocol.  If it were, the implications to the URI scheme

There are two main reasons why HTTP is not being used as an application
protocol here.  The first is that overall architecture is intended to allow
the key pieces of lost to remain the same, even if deployment proves that
it would be more effective if deployed using a UDP-based transport, some
different TCP-based transport, or its own, dedicated transport.  The use
of u-naptr for resolution is intended, in particular, to allow this, even as
the authors and working group recognize that the quickest deployment path
is to re-use HTTP.  The second reason relates to HTTP's current deployment
characteristics; in many environments HTTP queries are intercepted for
proxy handling of various kinds.  Those interception proxies are a serious
concern for a protocol intended to deliver information about where to
target emergency calls.  They may, in the end, help, but the working group
wanted a way to distinguish the traffic and/or alter the underlying
protocol if that were not the case.
			regards,
				Ted Hardie

>should defend that choice with reference to RFC 3205 (BCP 56).
...snip...

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 01 Feb 2007 21:17:51 -0500

Hi Andy,

I think that the criteria is not whether it will be typed in. The 
AAA/AAAS URI scheme for Diameter is not typed in  --- in fact it is used 
in the very same way as we use it here.

Ciao
Hannes

Andrew Newton wrote:
>> --Mark Baker.  Ottawa, Ontario, CANADA.         http://www.markbaker.ca

---

From: Andrew Newton <[email-masked]>
Date: Thu, 1 Feb 2007 21:47:42 -0500

> I've replied to Mark on the uri-review list (reproduced below).

We can still use U-NAPTR without a URI scheme.  There's nothing in U- 
NAPTR that requires one.  Of course, I do agree that reserving the  
lost: URI scheme name is important.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Thu, 1 Feb 2007 21:50:50 -0500

On Feb 1, 2007, at 9:17 PM, Hannes Tschofenig wrote:

> AAA/AAAS URI scheme for Diameter is not typed in  --- in fact it is  
> used in the very same way as we use it here.

Fine.  URIs can also be used as protocol elements.  What other  
protocols need to pass around LoST URIs in a generic URI protocol field?

-andy

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 01 Feb 2007 22:30:48 -0500

Hi Andy,

> protocols need to pass around LoST URIs in a generic URI protocol field?
Currently, we are focusing on the emergency services use case and there 
I haven't seen a place where we have to use the LoST URIs in other 
protocols.

Btw, the mentioned AAA/AAAS URIs are not used in other protocols either.

If I understood you right then you would like to use a 'host' as is 
defined in Section 3.2.2 of RFC 3986 with the lost URI scheme.

Ciao
Hannes

---

From: Ted Hardie <[email-masked]>
Date: Thu, 1 Feb 2007 20:51:03 -0800

At 9:50 PM -0500 2/1/07, Andrew Newton wrote:
>Content-Type: text/html
>X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier
>	0.53.3
>
>
>>I think that the criteria is not whether it will be typed in. The AAA/AAAS URI scheme for Diameter is not typed in  --- in fact it is used in the very same way as we use it here.
>>
>
>Fine.  URIs can also be used as protocol elements.  What other protocols need to pass around LoST URIs in a generic URI protocol field?
>
>-andy

I think it would be better if provisioning mechanisms passed along the full lost
URI, since that allows for providing multiple targets (potentially with different
transports) after U-NAPTR is invoked.  Some aren't going to have generic URI slots,
but I think it is better for those that do (and yes, the link on the web page or
provider provisioning may end up playing here).

I also believe that it's appearance in the findServiceResponse is pretty useful;
I want to tell you the authoritative source--without tying it to which one
of the target URIs served the answer to me.  You know, in other words, which
source you went through (if resolver) or gave the answer (if authoritative); I don't
have to know which host it was--something that might be difficult to map
back into source if that was what was captured instead (especially if the

					Ted

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 2 Feb 2007 07:35:30 +0100

On 2 feb 2007, at 05.51, Ted Hardie wrote:

> transports) after U-NAPTR is invoked.

URIs is, I claim, the way we in IETF describe unique name for an  
object on the Internet. Given a URI, we also define mechanisms for  
how to retrieve that object (if the object is retrievable).

I do not think it is good that a protocol like LOST is defined where  
data in the protocol itself include things like "unique names of  
objects", "referrals" etc and there is no URI definition for the data  
passed around in those protocol primitives.

Note that definition of URIs is one thing, using them in the protocol  
is another. Take mailto: URI for example that is a well defined URI  
scheme that is used a lot, but the SMTP protocol do not use the URI.

    Patrik

---

From: Andrew Newton <[email-masked]>
Date: Fri, 2 Feb 2007 03:20:58 -0500

To answer all 3 responders at once...

On Feb 2, 2007, at 1:35 AM, Patrik Fältström wrote:

> I do not think it is good that a protocol like LOST is defined  
> where data in the protocol itself include things like "unique names  
> of objects", "referrals" etc and there is no URI definition for the  
> data passed around in those protocol primitives.
>
> Note that definition of URIs is one thing, using them in the  
> protocol is another. Take mailto: URI for example that is a well  
> defined URI scheme that is used a lot, but the SMTP protocol do not  
> use the URI.

Hannes is correct in that all we need is the "host" portion of the  
URI.  It isn't a "host" but a domain name, and  that is the input  
value to U-NAPTR.  The output is multiple HTTP/HTTPS URIs, not LoST  
URIs.

A domain name is all the current LoST scheme specifies.  There is no  
difference between passing around a LoST domain name and a LoST URI,  
other than the first five characters which are always "lost:".  The  
only reason we might need a LoST URI is to put it in a place that  
generically takes URIs, and that use case hasn't surfaced.

And I disagree with the characterization of URIs above.  The tel:,  
data: and file: URI schemes certainly don't fit the description of  
"unique name for an object on the Internet."  And creating a URI  
scheme just because there is some sort of tradition of doing so  
doesn't help with interoperability one iota.  In fact, creating  
protocol widgets without a clear reason for doing so generally causes  
more harm than good.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 2 Feb 2007 04:38:12 -0500

I suspect that configuration protocols are one likely customer for  
this, depending on how they organize information, i.e., whether  
expect a URL or a host name.

On Feb 1, 2007, at 9:50 PM, Andrew Newton wrote:

>> AAA/AAAS URI scheme for Diameter is not typed in  --- in fact it  
>> is used in the very same way as we use it here.
>

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 2 Feb 2007 12:00:28 +0000

>    apparent, and should limit these names to no more than 255 characters in length"

253 characters.

The limit is 255 octets for the encoded form, which consists of labels each
preceded by a length octet, ending with a zero-length label. That is,
www.example.com (15 characters) is encoded as:

    3  'w' 'w' 'w'  7  'e' 'x' 'a' 'm' 'p' 'l' 'e'  3  'c' 'o' 'm'  0

(which is 17 octets). So the 255 octet limit is a 253 character limit.

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
THUS plc            |                            |

---

From: Ted Hardie <[email-masked]>
Date: Fri, 2 Feb 2007 12:13:40 -0800

At 3:20 AM -0500 2/2/07, Andrew Newton wrote:
>Hannes is correct in that all we need is the "host" portion of the URI.  It isn't a "host" but a domain name, and  that is the input value to U-NAPTR.  The output is multiple HTTP/HTTPS URIs, not LoST URIs.
>
>A domain name is all the current LoST scheme specifies.  There is no difference between passing around a LoST domain name and a LoST URI, other than the first five characters which are always "lost:".  The only reason we might need a LoST URI is to put it in a place that generically takes URIs, and that use case hasn't surfaced.
>
>And I disagree with the characterization of URIs above.  The tel:, data: and file: URI schemes certainly don't fit the description of "unique name for an object on the Internet."  And creating a URI scheme just because there is some sort of tradition of doing so doesn't help with interoperability one iota.  In fact, creating protocol widgets without a clear reason for doing so generally causes more harm than good.
>

So, Andy and I talked some more about this this morning, and we agreed that there
were compelling cases where a LoST URI would be useful.  Unfortunately, it turns
out to meet the compelling use cases, we actually need to add something to the
URI syntax.

Here's one example:

I'm writing a web page of advice for teens, and I want to include something
that contains a pointer for a counselling service.   If there were a single, global
counselling service for depressed teens, I could use its sip URI and tell them
to call the service.  But such things are not global; they are local.  So I want
to use lost to get them access to the local service.

<html><head><title>Advice</title><head>
<body>

If you are thinking of hurting yourself, <a href="urn:service:counselling.suicide">
GET HELP</a>!  Don't try to get through it alone!<p>
</body>
</html>

This will not work, though, if the browser doesn't invoke LoST when encountering
that URN.  So we need a way to tell the browser what protocol mechanism to invoke.
A URI scheme is a way of doing that (there are others, but this is a clear one).

So I could modify this to:

<html><head><title>Advice</title><head>
<body>
If you are thinking of hurting yourself, <a href="lost://referringserver.example.com/"> GET HELP</a>!  Don't try to get through it alone!<p>
</body>
</html>

But this doesn't work either, as once I've done the U-NAPTR look up and gotten a target
server, the referring server doesn't know what to response to give me, because
I didn't tell it what service I'm seeking.  To make it work, I have to
combine the two with something like:

<html><head><title>Advice</title><head>
<body>
If you are thinking of hurting yourself, <a href="lost://referringserver.example.com/parameter=urn:service:counselling.suicide"> GET HELP</a>!  Don't try to get through
it alone!<p>
</body>
</html>

"Parameter" needs a better name, obviously, but you get the idea.  With that
functionality, there is enough there to give the teen a referral to an appropriate
counselling service.

This leaves the current use of the LoST URI as a valid, and available for any
provisioning protocol that simply wants to use at as a marker of what is being
provisioned.  But it extends in a way that may help the deployment of
LoST into new types of service.  By allowing the LoST URI to contain a
parameter that names the service, you allow someone to deploy a LoST
service which may not be initially resolvable by the local (emergency-centric)
LoST resolvable, embedding that URI into common provisioning mechanism,
including the ever-popular web page.

My next steps on this are to re-work the URI portion of the LoST draft.
I'm hoping to get suggested text to the author team today or tomorrow,
as I don't want this to hold us up.

				Ted

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 2 Feb 2007 15:32:02 -0500

I have a problem with this line of thinking.

No current anything knows how to do anything remotely like what you are
describing.  Worse, the easiest possible analog to this would be:
<html><head><title>Advice</title><head>
<body>
 
If you are thinking of hurting yourself, <a href="sip:suicidehelp.org>
GET HELP</a>!  Don't try to get through it alone!<p>
</body>
</html>

No browser I am aware of knows what to do with "sip:".

If we make new browsers that know what to do, then what you want is your
first example, and the resolution to a service urn is to invoke LoST, pick a
communications protocol, and resolve the appropriate URI.  It's not LoST
that is the URI, it is the service URN.  Resolving a service URN means you
have to take several steps including invoking LoST.

Brian

> -----Original Message-----
> From: Ted Hardie [mailto:[email-masked]]
> Sent: Friday, February 02, 2007 3:14 PM
> To: Andrew Newton; "Patrik Fältström"; Hannes Tschofenig
> Cc: ECRIT
> Subject: Re: [Ecrit] [Fwd: Re: [Uri-review] IETF ECRIT Working Group:
> LoSTURI Scheme --- Review Needed]
> 
> >Hannes is correct in that all we need is the "host" portion of the URI.
> It isn't a "host" but a domain name, and  that is the input value to U-
> NAPTR.  The output is multiple HTTP/HTTPS URIs, not LoST URIs.
> >
> difference between passing around a LoST domain name and a LoST URI, other
> than the first five characters which are always "lost:".  The only reason
> we might need a LoST URI is to put it in a place that generically takes
> URIs, and that use case hasn't surfaced.
> >
> >And I disagree with the characterization of URIs above.  The tel:, data:
> and file: URI schemes certainly don't fit the description of "unique name
> for an object on the Internet."  And creating a URI scheme just because
> there is some sort of tradition of doing so doesn't help with
> interoperability one iota.  In fact, creating protocol widgets without a
> clear reason for doing so generally causes more harm than good.
> >
> 
> If you are thinking of hurting yourself, <a
> href="lost://referringserver.example.com/"> GET HELP</a>!  Don't try to
> get through it alone!<p>
> </body>
> </html>
> 
> If you are thinking of hurting yourself, <a
> href="lost://referringserver.example.com/parameter=urn:service:counselling
> .suicide"> GET HELP</a>!  Don't try to get through
> it alone!<p>
> </body>
> </html>
>

---

From: Andrew Newton <[email-masked]>
Date: Fri, 2 Feb 2007 15:46:57 -0500

On Feb 2, 2007, at 3:13 PM, Ted Hardie wrote:
> To make it work, I have to
> If you are thinking of hurting yourself, <a href="lost:// 
> referringserver.example.com/ 
> parameter=urn:service:counselling.suicide"> GET HELP</a>!  Don't  
> try to get through
> it alone!<p>
> </body>
> </html>
>

I also thought up the case where a LoST URL could point to a specific  
service boundary reference.  Put into a web page, it could allow  
Pizza Hut to express their service area:

<a href="lost://pizzahut.example/sbref=UUID">Click here to see if you  
are in our service area</a>

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 2 Feb 2007 16:01:30 -0500

Again, why would you imagine a browser being built that would have that
behavior?  This is very bizarre behavior at that, specifically knowing that
this "sbref" parameter means invoke LoST, and if you get a URI, render some
kind of positive indicator.  Where is the specification for that? Why
wouldn't you use some form of "href=urn:service.pizza.pizza-hut/someparam"
for that if you define that kind of behavior in some future spec?

I don't think LoST is the kind of protocol that gets put in a URI.

Brian

> From: Andrew Newton [mailto:[email-masked]]
> Sent: Friday, February 02, 2007 3:47 PM
> To: Ted Hardie
> Cc: ECRIT
> Subject: Re: [Ecrit] [Fwd: Re: [Uri-review] IETF ECRIT Working Group: LoST
> URIScheme --- Review Needed]
> 
>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 02 Feb 2007 18:54:18 -0500

The problem with using an "urn:" URI in this use case is that it doesn't 
give the browser (or other using application) any clue about what to do 
-- it just identifies a service, without an implied means for delivery. 
  That's OK when it's in the To: header of a SIP message, since the To: 
header implies the usage of the URN, but not in this more general case. 
  As Andy and Ted's examples illustrate, there are at least two 
interpretations for a "urn" URI in this use case.

In any case, I don't understand how allowing for URI of the form 
"urn:service.pizza.pizza-hut/someparam" is any better than defining a 
"lost:" URI scheme, since that would require modifying the "urn:" URI 
scheme.

As a final note, let's not get hung up on browser capabilities, since 
these are often extended in different ways.  Mac OS, for example, has a 
registry of handlers for different URI schemes that applications can 
call on if they don't know how to handle a URI.

--Richard

---

From: Andrew Newton <[email-masked]>
Date: Fri, 2 Feb 2007 20:10:10 -0500

I agree with Richard's response, but would like to address this point  
specifically:

On Feb 2, 2007, at 4:01 PM, Brian Rosen wrote:

> This is very bizarre behavior at that, specifically knowing that
> kind of positive indicator.

It is not bizarre behavior.  LoST supports service boundary  
references and has a specific and distinct mechanism for retrieving  
them.  Rather than being just some kind of indicator, the result  
would be a service boundary -- either civic or geo.  A location-aware  
device (or browser plugin) could use that information to determine if  
it was near or in the service area.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 3 Feb 2007 06:15:18 -0500

> No browser I am aware of knows what to do with "sip:".

This is only roughly true. All modern browsers allow users to add new  
URI schemes. We did this for IE 5/6 a long time ago, via a one-line  
registry entry performed as part of the SIP client installation. IE  
would then pass the URL to the SIP client, so that "click-to-dial" is  
possible. As far as the user was concerned, the browser indeed knew  
what to do with the URI scheme.

Thus, this is somewhat orthogonal as to whether this is useful for  
LoST or not.

Henning

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 03 Feb 2007 13:52:45 -0500

Hi Henning,

I was just referring to Diameter as an example where URI schemes were 
also introduced and the usage environment is extremely similar to the 
one we previously discussed (without considering the webpage proposal 
mentioned by Ted and Andy).

Ciao
Hannes

Henning Schulzrinne wrote:
> this, depending on how they organize information, i.e., whether expect 
> a URL or a host name.
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 3 Feb 2007 15:06:13 -0500

I share Brian's concern; this seems like a real stretch. If all you  
want to do is retrieve a boundary polygon, a plain HTTP request, with  
appropriate XML content type, seems much easier to implement, for all  
parties concerned.

Previously, we had numerous instances where features were deferred  
since there was no immediate need based on our charter and  
requirements documents. Now, we suddenly, at the last minute, invent  
new requirements that are fanciful at best.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 3 Feb 2007 15:10:34 -0500

I think the correct solution is to use the service URN in that case.  
This is what we'd be publishing for emergency services and put in  
address books. LoST is implied by that, just like DNS is. We don't  
put DNS URLs in web pages, either, just because getting an HTTP page  
also requires performing a DNS resolution operation.

The browser has to understand how to resolve service URNs in any event.

This mechanism also does not work since LoST servers are meant to be  
operated locally, not globally. You do not want every suicide  
candidate to hit one global LoST servers, as that's fundamentally  
opposed to the LoST caching and scaling mechanisms.

I'm strongly opposed to this extension. We have no requirements for  
this in our charter or in the ECRIT requirements documents.

Henning

On Feb 2, 2007, at 3:13 PM, Ted Hardie wrote:

> href="urn:service:counselling.suicide">
> referringserver.example.com/"> GET HELP</a>!  Don't try to get  
> through it alone!<p>
> </body>
> </html>
>

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 5 Feb 2007 11:20:21 +0100

On 2 feb 2007, at 09.20, Andrew Newton wrote:

> "unique name for an object on the Internet."

Ok, sorry for being fluffy with what words I use. URIs of course also  
can name endpoints for services.

> And creating a URI scheme just because there is some sort of  
> tradition of doing so doesn't help with interoperability one iota.   
> In fact, creating protocol widgets without a clear reason for doing  
> so generally causes more harm than good.

This I completely agree with.

I just *thought* an object in LOST was identified by two things, the  
LOST URI (containing only a hostname, that is resolved using U-Naptr  
algorithm) and a unique identifier, and that it suited to instead  
create a URI scheme so that the uri with both host and unique  
identifier was embedded in it.

I misunderstood. Sorry.

    Patrik