OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


FYI

-----Original Message-----
From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On Behalf Of Eran Hammer-Lahav
Sent: Thursday, June 25, 2009 11:58 AM
To: apps-discuss@ietf.org
Cc: www-tag@w3.org; URI
Subject: URI for abstract concepts (domain, host, origin, site, etc.)

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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]