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

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

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

Leslie,

thanks for your comments. Please see inline for some additional  
questions and a few answers.

On Jul 21, 2006, at 7:16 PM, Leslie Daigle wrote:

>
> Except.
>
> It's not at all clear to me that LoST is the resolution service for
> service URNs; rather, it seems service URNs are used as data elements
> in the LoST specification, and maybe they are useful in doing service
> discovery for LoST servers.  Neither of those is URN resolution.  So,
> maybe "no resolution service available" is the right answer in this
> URN nid registration.
>

I don't know if there's a canonical definition of what resolution is,  
so maybe the best way is to ask you whether this fits the definition:

(1) S/U-NAPTR is used to find a LoST server (which can depend on the  
top-level service).

(2) The LoST server translates (resolves, if you like) the service  
URN (and location) to one or more URLs pointing to "service  
resources", such as an HTTP, SIP or XMPP URL.

I'm happy to declare "no resolution", since that would remove a  
normative dependency, assuming the IESG lets us. I just don't want to  
have the document get thrown back into our lap at IESG review time.

>
> Comments on draft-ietf-ecrit-service-urn-03.txt:
>
>
> See comments above -- I think this becomes something like "there is no
> global resolution process for service URNs; they are used by other
> protocols to identify services and acquire relevant local  
> information."

I'm not exactly sure what a "resolution" definition is in that case.  
I thought resolution translated a generic, network-address- 
independent identifier into a specific instance of that resource,  
accessible by a retrieval or access protocol. That pretty much  
describes the service URN + LoST approach.

>
>
>>   Validation mechanism: Validation determines whether a given  
>> string is
>>       currently a validly-assigned URN [15].  The S-NAPTR  
>> mechanism also
>>       allows to determine if a mapping protocol for a particular top-
>>       level service exists.  The mapping protocol itself would then
>>       answer the question whether the service identifier exists.   
>> (The
> [header snipped]
>>       issue of whether a particular combination of service and  
>> location
>>       yields a usable answer is beyond the scope of this  
>> specification.)
>
>
> I suggest there is no validation mechanism, and this section should
> say that (plenty of URN namespaces do).  As I understand it,
> LoST will yield a highly localized result -- something may provide
> a result in one context, but not another (e.g., if there is no
> 911 service?).  It's not right, then, to say that the 911 service
> URN is invalid.  This is not a validating function.
>

There are two cases of invalid services:

(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?

I will comment on the more detailed issues you raise separately.

Henning

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