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

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

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

Howdy,

Sure, follow-up comments in-line:

Henning Schulzrinne wrote:
> 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.

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.

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 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.

And, maybe it is -- depending on the answer to the questions above,
especially the first one.

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.

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

Yep, exactly.  And it's not clear to me you can achieve it with the
LoST protocol.

Leslie.

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

---

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

I think the registration of the service URN specifies the resolution
protocol, LoST being the protocol to resolve sos.

Of course, you DO pass the service urn to LoST, because its response is
service dependent.  That is not necessarily true of any other protocols that
might be used to resolve other services.

Because the urn is defined as a tree with levels, it will always be that
case that you can have an invalid service passed to a resolution protocol
(indeed, you could pass something not even registered), so LoST needs an
error to say "not a service I handle".  That error needs to be distinguished
from "There is such a service I resolve, but for this location, I don't have
one", which is itself distinguished from "I don't have that service for this
location, but I've been told to give you this replacement service and it's
URI".

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 (3)
> 
> 
>