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

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 21 May 2010 07:59:49 -0700

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/

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 21 May 2010 13:49:02 -0700

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:[email-masked]]
> Sent: Friday, May 21, 2010 12:23 PM
> To: Eran Hammer-Lahav
> Cc: [email-masked]; [email-masked]
> 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
> <[email-masked]> 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].
> >
> > 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 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
> > _______________________________________________
> > Uri-review mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/uri-review
> >

---

From: Ted Hardie <[email-masked]>
Date: Fri, 21 May 2010 12:22:53 -0700

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:

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.

Good luck,

Ted Hardie

---

From: Keith Moore <[email-masked]>
Date: Fri, 21 May 2010 19:43:59 -0400

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

---

From: Keith Moore <[email-masked]>
Date: Sun, 23 May 2010 09:55:18 -0400

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 23 May 2010 08:56:36 -0700

Thanks. I guess I'm back at looking at a URI scheme then.

EHL

From: Keith Moore [mailto:[email-masked]]
Sent: Sunday, May 23, 2010 6:55 AM
To: Eran Hammer-Lahav
Cc: Ted Hardie; [email-masked]; [email-masked]
Subject: Re: [Uri-review] URI for identifying a host

---

From: David Booth <[email-masked]>
Date: Sun, 23 May 2010 14:56:23 -0400

> > show stopper for using URNs?

Huh?  A URN can be used to name *anything*.  Global uniqueness has
nothing to do with whether or not you base your naming on URNs, it has
to do with how your specification chooses to allocate names *within*
your naming scheme.  Globally unique names can certainly be allocated
within the URN naming scheme.  There is no need for a new URI scheme.

-- 
David Booth, Ph.D.
Cleveland Clinic (contractor)

Opinions expressed herein are those of the author and do not necessarily
reflect those of Cleveland Clinic.

---

From: Keith Moore <[email-masked]>
Date: Sun, 23 May 2010 21:41:46 -0400

On 5/23/10 2:56 PM, David Booth wrote:
> Huh?  A URN can be used to name *anything*. 
Incorrect.

---

From: David Booth <[email-masked]>
Date: Mon, 24 May 2010 08:19:14 -0400

> > Huh?  A URN can be used to name *anything*. 

I can only assume that either we are somehow talking about different
things, or you are unaware of the universal intent behind URIs as names
(and hence URNs).  

I do not know exactly what you're trying to do with URNs, but in general
URNs can be used to name *any* kind of resource, where the term
"resource" means, essentially, *thing* -- any kind of thing, real or
imaginary.  It does *not* merely mean "web-accessible thing" or
"physical thing".  If this seems unclear, please see the RFC 3986
section 1.1 definition of "resource"
http://tools.ietf.org/html/rfc3986
which attempts to make that point unambiguous.
RFC 2611 builds on the general notion of URIs and does not further
restrict what can be named with a URN.  *Any* resource can be named with
a URN, i.e., *anything* can be named with a URN -- including people,
dogs, unicorns, hosts and web pages:
http://www.ietf.org/rfc/rfc2611.txt

---

From: Keith Moore <[email-masked]>
Date: Mon, 24 May 2010 11:12:44 -0400

> things, or you are unaware of the universal intent behind URIs as names
I'm saying that URNs have very specific properties that do not apply to
URIs in general.
> dogs, unicorns, hosts and web pages:
Correct.  But the meaning of a URN does not change according to location
or time.  Once a URN is associated with a resource, it's always
associated with that resource. 

It's certainly reasonable, at least in principle, to use a URN to name a
host.  However, it's not reasonable to take some sort of identifier
that's associated with one host now and another host later (like a DNS
name or an IP address), or an identifier that's associated with one host
in one location and another host in another location (like an RFC 1918
address), slap "urn:" and a namespace identifier on the front, and
pretend it's a legitimate URN.

And just as you said, a URN can name any kind of resource.  So why do we
need a specific kind of URN to name a host?  Wouldn't any kind of URN
suffice to do this, like a uuid or an oid?

Keith

---

From: Ted Hardie <[email-masked]>
Date: Mon, 24 May 2010 10:03:44 -0700

Thinking about this problem some more, I realized that we'd had some of this
conversaton in regards to Larry Masinter's proposals for the "thing
described by"
URI scheme.  The early drafts of this had it as a URN namespace, but it
shifted to a URI scheme during the discussion.  The current (albeit expired)
version of his document is at
https://merlot.tools.ietf.org/html/draft-masinter-dated-uri-06
and it describes some of the relationships he sees between the scheme and
URN-based approaches.

While it would introduce a pretty serious amount of indirection, I can actually
picture using this with dns URIs to get to a description of host.

"This host is that which is described by the DNS A record retrieved at
this timestamp
from this authority."

That solves the context problem as it identifies which DNS record was
retrieved, from
where, and when, enabling you to identify the related host pretty
well.  I'm not sure,
though, whether this is any better than an OID.  The problem with OIDs
is that the
binding between them and any "normal" sense of what a host is pretty
much undiscoverable.
You can relate to pieces of information which are both related to the
same OID, but
not a whole lot more.  Shifting to a tdb-style approach has much the
same discovery
problem--unless you can retrieve the same record at the same time, any
relationship
between the current DNS record and the timestamped one is conjecture
(unless you're
querying the authoritative server and the serial number hasn't changed).

A short discussion of this in a bar bof/conference call might be a
good idea, if we
want to pull off the folks interested in participating.

regards,

Ted Hardie

---

From: Keith Moore <[email-masked]>
Date: Mon, 24 May 2010 13:18:57 -0400

On 5/24/10 1:03 PM, Ted Hardie wrote:
> this timestamp from this authority."
>
> That solves the context problem as it identifies which DNS record was retrieved, from where, and when, enabling you to identify the related host pretty well.  
Mumble.  It doesn't solve the problem of DNS record ambiguity as a DNS
record can be associated with multiple addresses and multiple hosts.
There's also the problem that the IP addresses returned are themselves
ambiguous.  Especially with IPv4 addresses getting extremely scarce, we
can expect a tremendous amount of address reuse/overloading of one kind
or another in the near future.
> I'm not sure, though, whether this is any better than an OID.  The problem with OIDs
> is that the binding between them and any "normal" sense of what a host is pretty
> much undiscoverable. You can relate to pieces of information which are both related to the
> same OID, but not a whole lot more. 
And again, these days the notion of "host" is pretty much an
abstraction.   When a "host" doesn't have a concrete realization in
physical space, we have to rethink what we're trying to name.  Virtual
hosts can be created, cloned, and destroyed on the fly in an instant.  
This is already extremely common, and soon it may be the usual case. 
With those circumstances I'm not sure that we can do any better than a
UUID or OID.  There isn't any other inherent identifier for a virtual
host.  It doesn't have to live at a fixed address in the network, it
doesn't have to have a DNS name (and if it does the name-host binding
might well be ephemeral as it is for so many physical hosts), it doesn't
have a hardware identifier, etc.

Or to put it another way - Do we want to create a URI for hosts that
doesn't apply to hosts in general?   If there is going to be a general
purpose "host" URI, it needs to be applicable to all hosts, which pretty
much rules out anything associated with a DNS name, address (at any
layer), network attachment point, or hardware identifier. 

Keith

---

From: Ted Hardie <[email-masked]>
Date: Mon, 24 May 2010 10:47:24 -0700

> retrieved, from where, and when, enabling you to identify the related host
> pretty well.
>

Just so I understand this a bit better, are you referring to the case where
a lookup for an A record at timestamp T to authority X returns multiple
records, presumably for round-robin load balancing or failover?

I certainly agree that can happen, but wouldn't the semantics for Eran's
problem still be reasonable?  That is, the metadata presumably applies
to all of them, if the zone maintainer is declaring them to be equivalent
addresses at which that host can be reached.  This may be because
of your already noted abstraction or because there are multiple interfaces
which reach the same box (for whatever value of box we're dealing with).

>There's
> also the problem that the IP addresses returned are themselves ambiguous.
> Especially with IPv4 addresses getting extremely scarce, we can expect a
> tremendous amount of address reuse/overloading of one kind or another in the
> near future.
>
> And again, these days the notion of "host" is pretty much an abstraction.
> When a "host" doesn't have a concrete realization in physical space, we have
> to rethink what we're trying to name.

I'd restate this problem another way.  The *notion* of host is still a discrete
node on the network with specific resources--that box with cables we all
know and love.  The issue we're facing is that the *reality* of a host has
shifted to one where instances can be created, cloned, abandoned etc.
on the fly.

Think about the copyright example in the host-meta document.  For the
host-wide application, there needs to be some way to talk about the
specific set of resources; "those located at this discrete node" is one
way to do it.  If ip and dns name no longer suffice to identify "discrete node",
we either need to come up with something else that does or find some other
way of identifying the set of resources.

>Virtual hosts can be created, cloned,
> and destroyed on the fly in an instant.   This is already extremely common,
> and soon it may be the usual case.  With those circumstances I'm not sure
> that we can do any better than a UUID or OID.  There isn't any other
> inherent identifier for a virtual host.  It doesn't have to live at a fixed
> address in the network, it doesn't have to have a DNS name (and if it does
> the name-host binding might well be ephemeral as it is for so many physical
> hosts), it doesn't have a hardware identifier, etc.
>
> Or to put it another way - Do we want to create a URI for hosts that doesn't
> apply to hosts in general?   If there is going to be a general purpose
> "host" URI, it needs to be applicable to all hosts, which pretty much rules
> out anything associated with a DNS name, address (at any layer), network
> attachment point, or hardware identifier.
>
If UUID or OID were retrievable in any useful way, this would make sense to me.
But I currently have no real sense of how a community of users would share
data about licenses, etc., using meta-data related only to UUIDs.  I can't
see much deployment, honestly, but that may only be me.

Just my two cents,

Ted Hardie

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 24 May 2010 11:17:09 -0700

I have decided to drop this for the time being and removed the <Host> element from host-meta, as well as kept <Subject> out of scope. The scope of a host-meta document, at this point, is solely determined by the HTTP host used to obtain it. The primary reason for including subject in the document (stating clearly that this document is a host-meta document for this host) is to enable signatures to bind the document to the subject of the certificate. Since after almost 2 years no signature proposal or use cases reached maturity, I decided it is best to take it out and move this discussion for when it is actually needed.

Thanks!

EHL

> Sent: Monday, May 24, 2010 10:04 AM
> To: Keith Moore
> Cc: David Booth; Eran Hammer-Lahav; [email-masked]; uri-
> [email-masked]
> conversaton in regards to Larry Masinter's proposals for the "thing described
> by"
> "This host is that which is described by the DNS A record retrieved at this
> timestamp from this authority."
> 
> pretty well.  I'm not sure, though, whether this is any better than an OID.
> The problem with OIDs is that the binding between them and any "normal"
> sense of what a host is pretty much undiscoverable.
> You can relate to pieces of information which are both related to the same
> OID, but not a whole lot more.  Shifting to a tdb-style approach has much the
> same discovery problem--unless you can retrieve the same record at the
> same time, any relationship between the current DNS record and the
> timestamped one is conjecture (unless you're querying the authoritative
> server and the serial number hasn't changed).
> 
> A short discussion of this in a bar bof/conference call might be a good idea, if
> we want to pull off the folks interested in participating.
> 
> regards,
> 
> Ted Hardie

---

From: Keith Moore <[email-masked]>
Date: Mon, 24 May 2010 14:30:10 -0400

> records, presumably for round-robin load balancing or failover?
Yes.  Though there may be multiple A (and AAAA) records associated with
a host for a wider range of reasons than that.

It is frequently the case that a DNS name wasn't coined to be associated
with a specific host, but rather, a service.  One should not assume when
looking at a DNS name that the name was intended to be associated with a
specific host.  And it's not necessarily the case that all addresses
associated with a DNS name are equally valid for all purposes.  A
particular service might be implemented on several hosts, and be
equivalent on all of them, but that doesn't mean that all of those hosts
support the same services.
> problem still be reasonable? 
I went back and looked at Eran's recent messages on this topic and don't
believe that I understand what problem he is trying to solve.  Maybe I
missed a message?
>  That is, the metadata presumably applies
> addresses at which that host can be reached.  
I disagree, because I've seen too many cases where this was not the
case.   A DNS name is not a host name anymore.   If ftp.example.com has
N addresses, it might be that the FTP server on the default ports at
each of those addresses will return consistent results from one host to
another as of the time the DNS query was made.  But it's not necessarily
the case that every address listed in the ftp.example.com RRset is
identical for all purposes. 
> This may be because
Or: whereas at one time it was obvious to everybody what a "host" was,
these days different people have widely different notions of what a host is.
> way of identifying the set of resources.
I think that's a pretty bizarre example.  To me it makes no sense at all
to associate licensing information with a host.  The relationship
between copyright licensing and a host on which a resource is stored, or
from which it is retrievable, seems pretty arbitrary to me for several
different reasons.   Now if you want to associate licensing information
with a "web site", that makes a little bit more sense (but only a little
bit more sense), as at least the notion of a web site is something
that's visible to an end user in the prefix of URIs at that site.  But
this has nothing inherently to do with any host.  Really the licensing
information is being associated with a URI prefix, because that's what's
visible to the user.  And even if one wants to define a scheme to export
licensing (or other metadata) in the aggregate for a collection of
resources, it seems silly to insist that it be at "host" (or "site"
granularity).
> see much deployment, honestly, but that may only be me.
I'm getting the impression that what people want to identify (in this
case) is not really a host.

Keith

---

From: Larry Masinter <[email-masked]>
Date: Tue, 25 May 2010 15:52:34 -0700

http://masinter.blogspot.com/2010/03/resources-are-angels-urls-are-pins.html

and comments thereon.

Personally, I like the idea that URIs are intrinsically tied to access methods, that the scheme defines the ‘authoritative’ access method (alternatives access methods allowed as long as they give the same access as the authoritative method), and that the access method for urn:<authority>:<stuff>   is  (or should be )  “ask <authority> what <stuff> means”.

Alternative access method: using a HTTP cache instead of HTTP to talk access to a http: URI.

So if you want a URI scheme for a ‘host’, you’d have to define what you think the authoritative method is of accessing the host and no other host.

---

From: Larry Masinter <[email-masked]>
Date: Wed, 26 May 2010 10:00:18 -0700

A couple of cross pointers:

I'd like to bring a couple of threads together: the discussion
in the W3C Technical Architecture Group (TAG) on URIs as names
(recent thread 'larry's position on URIs as names') starting
with 
http://lists.w3.org/Archives/Public/www-tag/2010May/0033.html )

and the discussion on [email-masked]

http://www.ietf.org/mail-archive/web/urn-nid/current/maillist.html

starting around May 21 2010 on "URI for identifying a host"
around whether it's possible or meaningful to define a URI
scheme that identified a "host" when there was no, or confusing,
operational definition of what, exactly, a "host" was, and how
it might be identified.

The question comes down to whether URIs effectively can identify
something for which there is no clear operational definition.

I should also point out the proposal for a URNbis working 
group in IETF at
http://www.ietf.org/mail-archive/web/urn/current/maillist.html
and the charter there, and suggest that some coordination between
URNbis and W3C would be useful here.

Larry
--
http://larry.masinter.net

---

From: [email-masked]
Date: Wed, 26 May 2010 13:35:53 -0400 (EDT)

Even more interesting as the OGC community is having discussions on the
consistent use and naming rules for URIs in the OGC standards work.

Regards

Carl Reed
CTO
OGC

---

From: David Booth <[email-masked]>
Date: Wed, 26 May 2010 21:33:53 -0400

> http://masinter.blogspot.com/2010/03/resources-are-angels-urls-are-pins.html
Regarding your blog question: 

  'But what exactly is a "resource" . . . '

This was discussed quite a bit a few years ago, and although RFC2396 had
been unclear (or confusing), RFC3986 does a very good job of clarifying
that *anything* can be considered a resource:
http://www.apps.ietf.org/rfc/rfc3986.html#sec-1.1
"This specification does not limit the scope of what might be a
resource; rather, the term "resource" is used in a general sense for
whatever might be identified by a URI."  Think of it as the universal
set in web architecture.

And this question:

  ' . . . and what does it mean to "identify" [a "resource"]?'

This also has been discussed rather extensively over the past few years,
and it is quite clear that this is merely talking about naming: the use
of a URI as a name for something.  "Identify" was (in hind sight) an
unfortunate choice of terms.  It would have been clearer to say things
like "a URI names a resource".

You also asked:

  'I click on a link, and my computer asks some other computer something
and gets something back. What do I get? Is it "the resource" that was
identified by that URL?'

No, it is a "representation" of that resource, as defined in AWWW
section 3.2:
http://www.w3.org/TR/webarch/#def-representation

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 May 2010 01:19:25 -0400

> http://www.w3.org/TR/webarch/#def-representation
In general, that's a true statement.  The problem is that this
contradicts a vast body of existing practice for which

a) the "representation" of the resource happens to be identical to the
resource, and/or
b) the application (quite reasonably) expects that the representation of
the resource is identical to the resource.

Consider an application that uses HTTP to copy files from one location
to another.  To that application, it's not acceptable for the origin
server of the source file to return any "representation" of the resource
other than the resource itself.  The fact that the specifications allow
it to be a "representation" is irrelevant - if any other representation
is returned, it breaks the application.  And the application has always
worked this way, since long before we tried to tease apart the
distinction between resource and representation.

Most of the time, we don't care, because we don't usually use such
applications to copy resources for which the origin server returns any
other representation than one which is identical to the resource.  But
the fact that servers don't work consistently in this regard does break
things.  We're just so accustomed to the breakage that we think of it as
normal.

I liked URLs better when they were simply dense encodings of protocol
messages which could be used to access a resource.  That's a very
predictable kind of behavior, one on which you can base other more
complicated interactions and expect them to work well.  Trying to make
URLs be both encodings of protocols and general purpose names at the
same time spreads them too thin, IMO.  It also means that you can't
expect a "GET resource named by URL" function to do the right thing
without knowing a priori how the resource behaves.  But I also realize
that by now so much has been written to make URLs more complicated and
less predictable than they need to be, that there's no going back.

Keith

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 27 May 2010 11:10:56 -0700

On May 26, 2010, at 10:19 PM, Keith Moore wrote:

> In general, that's a true statement.  The problem is that this contradicts a vast body of existing practice for which 
> 
> a) the "representation" of the resource happens to be identical to the resource, and/or
> b) the application (quite reasonably) expects that the representation of the resource is identical to the resource.

The fact that my car is gray does not contradict the fact that one
can buy the same model of car in other colors.  It is just a subset
of the available forms.

In other words, there is no contradiction here.

What would be a contradiction is a statement that the identified
resource is transferred, since that is very clearly false for
most uses of http, https, mailto, telnet, dns, and probably other
schemes that I have long forgotten.

> Consider an application that uses HTTP to copy files from one location to another.  To that application, it's not acceptable for the origin server of the source file to return any "representation" of the resource other than the resource itself.  The fact that the specifications allow it to be a "representation" is irrelevant - if any other representation is returned, it breaks the application.  And the application has always worked this way, since long before we tried to tease apart the distinction between resource and representation.

That's because of a property you assume of that resource (that it is a file).
In any case, a resource that has one and only one representation is a subset
of the more general definition.  It still fits.

In contrast, try to describe facebook or twitter in your terms.
Or the identifier used to select a proxy.  Or a service that only
accepts POSTed content to submit to an SMS gateway to a phone.
It just doesn't work.  Resources are not, in general, files, and
they do not move anywhere when a GET is applied to them.

> Most of the time, we don't care, because we don't usually use such applications to copy resources for which the origin server returns any other representation than one which is identical to the resource.  But the fact that servers don't work consistently in this regard does break things.  We're just so accustomed to the breakage that we think of it as normal.
> 
> I liked URLs better when they were simply dense encodings of protocol messages which could be used to access a resource.  That's a very predictable kind of behavior, one on which you can base other more complicated interactions and expect them to work well.  Trying to make URLs be both encodings of protocols and general purpose names at the same time spreads them too thin, IMO.  It also means that you can't expect a "GET resource named by URL" function to do the right thing without knowing a priori how the resource behaves.  But I also realize that by now so much has been written to make URLs more complicated and less predictable than they need to be, that there's no going back.

URLs are no more complicated now than they were in 1992.  Your assumptions
are simply wrong for anything other than file, ftp, and similar schemes
that do have a fixed representation bias.  It is very frustrating to try
to accurately describe Web architecture when people are insisting on
assumptions that are usually false.  It is better, therefore, to have
definitions that reflect the actual capabilities of the architecture.

....Roy