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

[Ted Hardie <[e-mail]>]

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
>