W3C home > Mailing lists > Public > uri@w3.org > June 2009

URI for abstract concepts (domain, host, origin, site, etc.)

From: Eran Hammer-Lahav <eran@hueniverse.com>
Date: Thu, 25 Jun 2009 11:57:48 -0700
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
CC: "www-tag@w3.org" <www-tag@w3.org>, URI <uri@w3.org>
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET>
LRDD [1] defines a way to link a descriptor (metadata, information about, etc.) to a resource. It keeps the document format of the descriptor out of scope, leaving it up to existing formats (XRDS, XRD, POWDER, Metalink, etc.) and new format to address.

Most of these descriptor formats include an element which indicates what the document is about - the subject of the descriptor. XRD includes the <Subject> element for this purpose with xs:anyURI as its type. I believe POWDER uses RDF's 'about' attribute in a similar way IIRC.

We have some use cases in which the subject of the descriptor does not have a URI available.

LRDD uses a well-known-location document (/host-meta, soon to be replaced with /.well-known/host-meta) to store information about the abstract host resource (the combination of domain name and port number, potentially also including protocol). Over the past few years, ad-hoc protocols have been abusing the root resource URI to mean something beyond just the root resource of a domain - basically as a placeholder for information about the entire domain or host.

The lack of URI for such concepts is preventing descriptor formats from being used here because there is no valid URI available to insert into the subject container. While no representation is expected for such abstract concepts, within the context of descriptors, being able to reference them is critical.

The use case at hand is using XRD as the document format for host-meta. Host-meta describes attributes of the host which by itself does not currently have a URI. We need to figure out what to put in the host-meta document's <Subject> element which has direct impact on the trust profile and signature (but is outside the scope of this discussion).

So far I could only come up with two options:

1. Make a special case exception that when the subject is http://______/.well-known/host-meta, it is treated differently than any other URI in that it means the XRD is not about that URI (the host-meta document itself), but about the abstract host resource located at ______.

2. Define a new kind of URI that can be used for abstract entities such as "host" or "domain", but which is not an http URI because that will bring us right back to #1.

I would like to ask for feedback on the idea of proposing a new URI scheme or a new URN namespace for this purpose, something like 'abstract'.
It will look something like this (please focus on the idea, not the syntax of the examples):

urn:abstract:domain:example.com
urn:abstract:host:example.com:8080
urn:abstract:origin:example.com:8080:http

or

abstract://example.com/domain
abstract://example.com:8080/host
abstract://example.com:8080:http/origin

Any comments, feedback, or concerns would be greatly appreciated.

EHL

[1] http://tools.ietf.org/html/draft-hammer-discovery
Received on Thursday, 25 June 2009 18:58:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 January 2011 12:15:42 GMT