- From: Xiaoshu Wang <wangxiao@musc.edu>
- Date: Sun, 28 Jun 2009 22:33:41 -0400
- To: Eran Hammer-Lahav <eran@hueniverse.com>
- CC: "ashok.malhotra@oracle.com" <ashok.malhotra@oracle.com>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>, "www-tag@w3.org" <www-tag@w3.org>, URI <uri@w3.org>
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