Subject: [Ecrit] Forward of Off-List Service URN Draft Discussions (4)

From: "Tschofenig, Hannes" <[email-masked]>
Date: Wed, 16 Aug 2006 14:26:35 +0200

-----Ursprüngliche Nachricht-----
Von: Henning Schulzrinne [mailto:[email-masked]] 
Gesendet: Dienstag, 25. Juli 2006 00:06
An: Leslie Daigle
Cc: Marc Linsner; Tschofenig, Hannes; 'James M. Polk'; [email-masked]
Betreff: Re: Moving forward with the Service URN Draft [general]

> But, the question is, is this sort of resolution is applicable to all
> service URNs? -- i.e., it's expected that one be able to do that  
> and get
> a result.
>

Yes, that's the idea. (In principle, it would be possible that there  
are multiple resolution protocols, beyond LoST, for a new service  
type, but I suppose the more-than-one case is true for just about any  
URN.)

> And, then, is there a specific LoST query to carry out that  
> translation?
> (The bit that seems to have fallen between the 2 documents at this
> time).  Or, does it happen as a by-product of a more fully-fleshed
> out LoST query?

I'm not sure I fully understand your question, but the actual mapping  
does indeed happen within LoST. The LoST query contains, inter alia,  
the service URN and the location information. The response contains  
zero or more URLs that provide that service.

>
> What I had (mis?)understood from the documents was that the service
> URN would be passed as one data element in some LoST queries, and
> the LoST response would include the requisite URIs.  I.e., the
> focus is not on the service URN; it's just a piece of data to
> help refine the query.
>

It's one of two key pieces, along with geographic location. I guess  
you could call the latter a form of context; not sure if such context- 
dependent resolution fits the standard URN resolution model.

>> (1) There is no resolution mechanism for a service, anywhere,  
>> because it hasn't been defined yet or there are no servers that  
>> can translate that service. (Say, urn:service:teleportation might  
>> have that quality.)
>> (2) There is no instance of that resource for a particular  
>> location (what you seem to be referring to, e.g., no  
>> urn:service:sos on Antarctica).
>> I guess validation would only apply to the first case?
>
> Yep, exactly.  And it's not clear to me you can achieve it with the
> LoST protocol.

The intent is that you can, subject to the usual false negative  
problem of any distributed directory. (If a server is off-line, I  
can't tell if it might have had the thing I was looking for.) There  
is a second failure case, namely if the domain doesn't know about a  
particular top-level service, which might still exist.

Thus, the validation is somewhat limited.

Henning

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

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 16 Aug 2006 09:02:56 -0400

I believe I am in complete agreement with Henning:

Service URN registration specify resolution protocol
For LoST, Service urn is passed to the server, and used to qualify the
response ("these URIs are the correct ones for the service and location
specified")

Errors need to distinguish "I can't get authoritative information for that
location" from "there is no resolution available for that service at that
location" from "here is a substitute service and URIs for that service"

Brian

> -----Original Message-----
> From: Tschofenig, Hannes [mailto:[email-masked]]
> Sent: Wednesday, August 16, 2006 8:27 AM
> To: [email-masked]
> Subject: [Ecrit] Forward of Off-List Service URN Draft Discussions (4)
> 
> 
>