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

Eran Hammer-Lahav wrote:
> 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
>>>
>>>
>>>
>>>
>>>       
>
>   
(1) You develop your XSD document format, in whatever form you think is 
the most suitable.  And you deploy that definition in the Web, say 
http://xsd.type.com, which in essence makes it a media-type.
(2) Then, you client content-negotiate the XSD content with that URI 
with the desired resource. 

It is as easy as it gets.  All communication problem can (and I think 
should be solved in this way).  I said can because, as Butler Lampson 
has famously said: "All problems in computer science can be solved by 
another level of indirection".  Content negotiation is just a level of 
"indirection".  The problem is abstracted into a URI and then negotiated 
over that URI.

Xiaoshu

Received on Monday, 29 June 2009 02:35:27 UTC