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

[Keith Moore <[e-mail]>]

I haven't seen the proposal itself (I didn't get the original message in
this thread), but I thought I'd respond to the topic of trying to create
a set of identifiers to identify hosts.

IP addresses are poor host identifiers for several reasons, including:
RFC 1918 addresses, host mobility, multiple interfaces on a host, NATs
resulting in different addresses for a host in different locations of
the network, the practice of grouping lots of hosts together behind a
single IP address, etc.

DNS names are also poor host identifiers for somewhat different reasons:
multiple hosts are sometimes associated with a single DNS name,
different hosts can be used for different services associated with the
same DNS name (SRV and MX records, also IPv4 A vs. IPv6 AAAA), lack of
universal use of DNS, etc.  DNS names were originally intended to be
used only for host names, but IMO it has been anachronistic to think of
them that way for at least ten years.

Some people like to use IEEE MAC addresses or similar L2 interface
identifiers to identify hosts.  That probably works better in practice
than either DNS names or IP addresses.  But network cards can migrate
from one host to another, and you probably don't want to assume that the
host identity migrates with the network card.  Similarly, some CPUs have
hardware serial numbers, but CPUs can also migrate while the things that
really define the host's identity and function (programs, data files)
tend to be in secondary storage.

These days, with widespread use of virtual machines, you can get
multiple virtual hosts per physical host, and with high availability
setups, you get a single virtual host that spans multiple physical
hosts.  These are getting more and more popular all the time as they
provide a simple and convenient way to solve several thorny problems.

We used to know what a host was - it was a box with power and data
cables connected to it, with lots of components inside.  It had a clear
physical location and clear physical boundaries.  These days a "host" is
less of a piece of hardware and more of an abstraction. 

So the best kind of identifier for a "host" is probably something like a
UUID -- something that can be generated anywhere without coordination;
something not tied to any piece of hardware; something that doesn't
imply anything about the purpose of, or services provided by, the host
(which can migrate independently of the host); something that doesn't
imply anything about the relationship of the host to administrative
domains.  At least, it appears that that's the only kind of "host"
identifier that could reasonably be used with all hosts.

The only remaining question is whether or not it should be visible in
the identifier that such an identifier is associated with a host.  But
we have generally avoided trying to embed type information in URIs. 

Keith


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