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

Let me try explaining my use case again, this time without any overloaded terminology or proposed solutions.

---

XRD is a document format for describing resources. It looks like this:

<XRD>
	<Subject>http://example.com</Subject>
	<Type>http://example.org/type/blog</Type>
	<Link>
		<Rel>author</Rel>
		<URI>http://example.com/author</URI>
	</URI>
</XRD>

Without getting too much into XRD, this short descriptor describes the resource identified by 'http://example.com'. It includes one type indicator (a made up example meant to mean this resource is a blog), and one link to the author's page.

---

I want to use this document format to describe rules that apply to all resources which belong to an HTTP host (as defined by 2616: a domain/address and port combination). The problem is, <Subject> requires a URI and currently there is no way to identify this set of resources (http://domain:port/*) as a valid URI.

What I don't want to do is use an exception such as 'if the URI begins with X, treat it as a rule and not a valid URI'...

EHL


> -----Original Message-----
> From: ashok malhotra [mailto:ashok.malhotra@oracle.com]
> Sent: Saturday, June 27, 2009 6:08 PM
> To: Eran Hammer-Lahav
> Cc: apps-discuss@ietf.org; www-tag@w3.org; URI
> Subject: Re: URI for abstract concepts (domain, host, origin, site,
> etc.)
> 
> Hi Eran:
> Trying to understand your proposal.
> By 'abstract' do you mean URIs for which a representation cannot be
> retrieved?
> So, perhaps, a chair?
> 
> My assumption was that for such resources you want to retrieve the
> metadata.
> To do that you do a GET which returns a 'Not Found' as well as a Link
> Header.
> 
> Of course, if you know syntactically that the resource does not have a
> representation
> you can save one access and go directly for the metadata.
> 
> Is that where you are going?
> 
> All the best, Ashok
> 
> 
> Eran Hammer-Lahav wrote:
> > 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 Sunday, 28 June 2009 18:10:35 UTC