RE: [Uri-review] URI for identifying a host

[Eran Hammer-Lahav <[e-mail]>]

Hi Ted,

I did look at the DNS URI scheme during the last review. While appealing, a DNS URI identifies a DNS record, not what the record means or points to. So an XRD with a subject of a DNS URI described a DNS record (for example, how to update, or when it was first created), not what the record points to.

As for not being globally unique, I can see your point. Is this a show stopper for using URNs?

EHL

> -----Original Message-----
> From: Ted Hardie [mailto:[e-mail]]
> Sent: Friday, May 21, 2010 12:23 PM
> To: Eran Hammer-Lahav
> Cc: [e-mail]; [e-mail]
> Subject: Re: [Uri-review] URI for identifying a host
> 
> Hi Eran,
> 
> A while back I tried to define a node-identifier uri scheme for use in peer to
> peer networks; the draft is expired, but you can see an old copy at:
> 
> http://tools.ietf.org/id/draft-hardie-p2psip-p2p-pointers-01.txt
> 
> One of the issues Vidya and I ran into was the "which overlay is this node in"
> problem, which we attempted to solve by using a context parameter and
> different (also undeployed) URI scheme that identified the overlay.
> 
> I suspect you have a milder version of the same problem here.
> RFC 3986 defines host as either an IP-literal or a registered name.  Some IP-
> literals are not globally unique (think RFC 1918 addresses); so that urn:
> host:10.1.1.10 would not mean the same thing everywhere.  You might be
> able to finesse that, but you also describe your desired outcome as having
> the property of identifying the "entity...across all schemes and ports".
> Unfortunately, the method by which a scheme identifies a host can involve
> additional processing, so that the eventually resolved network address is
> different.  Imagine scheme1 has processing directions that are essentially
> "look up A and AAAA records for host" and scheme2 has "look up available
> SRV records at host and proceed from there" (as Cullen Jenning's proposal
> for http-srv did, see the expired draft at http://tools.ietf.org/id/draft-
> jennings-http-srv-05.txt).
> The upshot, though is that the host in an http scheme and an http+srv
> scheme could have the same form but
> result in different processing.   All the ways I can imagine
> around that (by normalizing on the resulting output after all processing, say)
> end up violating the principle of least surprise.
> 
> That said, have you looked at the dns URI scheme (RFC 4501) for this
> purpose?
> It is more granular than your current proposal, in that it requires you to
> specify the RR, but the default seems reasonable for the current state of
> things, and the granularity it gives you seems a reasonable match to solving
> the context problem I outlined above.
> 
> Just some initial thoughts,
> 
> 
> Good luck,
> 
> Ted Hardie
> 
> 
> 
> 
> 
> On Fri, May 21, 2010 at 7:59 AM, Eran Hammer-Lahav
> <[e-mail]> wrote:
> > I would like to register a 'host' URN namespace for identifying a host (per
> RFC 3986, as the entity controlling all the resources with that URI host across
> all schemes and ports). This urn-nid will be defined in the host-meta
> specification [2].
> >
> > I'm looking for some feedback before I change the host-meta draft to
> include the urn-nid registration.
> >
> > Some background:
> >
> > XRD documents [1] use a <Subject> and <Alias> elements to express what
> the document is describing. These two elements require an absolute URI
> value. The host-meta document [2] uses XRD to describe a host which is
> defined as the entity controlling all the resources with that URI host across all
> schemes and ports:
> >
> > *://host/*
> > *:*@host
> >
> > Because there is no URI scheme to identify such a concept (XRD documents
> must be able to be interpreted without context - host-meta documents are
> not always obtained from /.well-known/host-meta), and after a long an
> exhausting discussion, I decided that the most practical approach was to
> define an extension element <Host> for host-meta.
> >
> > The new problem is that the <Host> element is the only known use case
> for extending the XRD schema which is nice and simple. I am now working on
> a JSON flavor called JRD [3] and the fact that host-meta requires an extension
> is painful because I want to keep JRD non-extensible.
> >
> > If we can solve this without the <Host> element, it will remove the one use
> case for extending the schema and encourage others to find ways to use the
> existing schema for their needs across XRD and JRD.
> >
> > Last year I decided against creating a URI scheme for this because the one
> use case and the potential hassle of doing it didn't seem worth it. With JRD,
> this extension element is standing in the way for a clean and simple JSON
> format (and consistency in general), I want to give it one more chance.
> >
> > I think there are two main options:
> >
> > 1. 'host:' URI scheme
> >
> > host:example.com
> >
> > ABNF (host is imported from RFC 3986):
> >
> > Host-URI = "host" ":" host
> >
> > 2. 'host' URN namespace
> >
> > urn:host:example.com
> >
> > ABNF:
> >
> > Host-URI = "urn" ":" "host" ":" host
> >
> > I think option 2 makes more sense because it more strongly imply that
> there is no protocol for obtaining a representation for this resource (host-
> meta is the host metadata, not the resource itself).
> >
> > Thoughts?
> >
> > EHL
> >
> > [1]
> > http://www.oasis-open.org/committees/download.php/37692/xrd-1.0-
> wd16.h
> > tml [2] http://tools.ietf.org/html/draft-hammer-hostmeta
> > [3] http://hueniverse.com/2010/05/jrd-the-other-resource-descriptor/
> >
> > _______________________________________________
> > Uri-review mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/uri-review
> >