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

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

-----Ursprüngliche Nachricht-----
Von: Leslie Daigle [mailto:[email-masked]] 
Gesendet: Freitag, 28. Juli 2006 03: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,

(Sorry -- caught up in pre-vacation desk-clearing; btw, I'll be
on vacation and not reading e-mail for 2 (! can it be true?!) weeks come
this weekend...):

Comments in-line:

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

Hmmm... not really; or, while it is certainly true that any URN
will find itself carried along in more than one protocol, it is not the
case that different subtrees of a URN NID will be resolved using
different protocols.  Again, kind of undermines the principle of a
"global resolution service".

Put another way -- the thing you'd want specified in the URN NID
registration document is the one that applies to all URNs in that
NID.

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

Right.  And, while URN resolution systems are expected to operate
on:
	. global knowledge about the URN NID (e.g., that it uses
	  a particular resolution service)

	. the URN itself

	. nothing else

this stuff sounds more and more like what Michael Mealling & I
suggested as "contextualization", once upon a yesteryear.
(Ahhh, gotta love the web!    See

http://www.ietf.org/ietf/00dec/c15n-agenda.txt )

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

See above.

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

Okay, so you certainly *could* implement it, but I guess my question
is more whether that is the *intention* -- are all LoST servers expected
to stay up to date about the full set of service URN types?

If not, I think this can not be considered validation.

Leslie.

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