Re: Proposal: 'tag' URIs

From: Michael Mealling <michael@bailey.dscga.com> · Date: Fri, 27 Apr 2001 14:06:00 -0400

On Fri, Apr 27, 2001 at 09:41:51AM -0700, Tim Kindberg wrote:
> At 10:50 AM 4/27/2001 -0400, Michael Mealling wrote:
> >And that's why we have URNs. Its a framework within which you can
> >define your own namespace but which defines a more specific set of
> >semantics (persistence, location independence, etc) than URIs in the general
> >case.
> 
> Location independence is the wrong assumption for my applications: we 
> require contextual resolution (the opposite).

Not really opposite. Location independence just means its not tied to
any particular network node by some network identifier being in the name.
I.e you don't have to talk to the DNS to have the identifier be usable.
Tag does this simply by using the DNS as unique identifier creation service,
not as a required network service.  Contextual resolution can happen 
regardless of whether a given identifier is location independent or not. 
Its just a matter of who you ask the question of. We actually had a BOF 
on this two IETFs ago called c15n or Contextualization. See 
http://lists.research.netsol.com/mailman/listinfo/c15n
for the mailing list. In the case of URNs all NIDs defined to date 
have to use contextual resolution because none have defined a way to resolve
it even if you wanted to (for a list see http://uri.net/urn-nid-status.html).

> And yet you said:
> At 11:32 AM 4/27/2001 -0400, Michael Mealling wrote:
> > > Tags are specifically intended to be 'agnostic' with respect to any
> > > particular resolution scheme. It's not that they will not get resolved (in
> > > CoolTown, resolution, usually to URLs, is precisely what we do with them)
> > > -- but we want all resolvers to be equal, and for the choice of 
> > resolver to
> > > be made in context, not mandated as a simple function of the given URI.
> >
> >URNs made that exact same determination many years ago....
> 
> So I'm confused!

I think your confusion may come from the common misunderstanding that URNs
are resolvable. They don't define that concept at all. A URN is simply
a persistent name. If you want to 'resolve' it then you get to define
what that means. If your application specific definition of 'resolution'
is one that includes context (or what some people call the 'appropriate
copy' or Harvard Problem) within the resolution step then so be it. That's
your business.

A few of us have defined one way in which you could resolve a URN as part
of a generic URI Resolution application defined in 
draft-ietf-urn-uri-res-ddds-03.txt but that's just one method among 
probably several. IMHO, a Contextualization service would be extremely
powerful and useful (hence the BOF). So in that regard it would also
be yet another way of resolving a URN, if that's what you were after. 
But if you wanted to roll your own then that's fine to...

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  michaelm@netsol.com