W3C home > Mailing lists > Public > www-tag@w3.org > March 2009

RE: Uniform access to metadata: XRD use case.

From: Eran Hammer-Lahav <eran@hueniverse.com>
Date: Thu, 5 Mar 2009 00:00:30 -0700
To: Jonathan Rees <jar@creativecommons.org>
CC: "Patrick.Stickler@nokia.com" <Patrick.Stickler@nokia.com>, "julian.reschke@gmx.de" <julian.reschke@gmx.de>, "connolly@w3.org" <connolly@w3.org>, "www-tag@w3.org" <www-tag@w3.org>
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723425023C6D40@P3PW5EX1MB01.EX1.SECURESERVER.NET>
The simple fact that most developers I work with have never heard of HTTP OPTIONS is enough of an indication for me that asking them to use MGET is not being practical. Yes, this argument doesn't fly with many people on this list, and I'm fine with agreeing to disagree. The idea behind my Link-based discovery proposal is that it offers three methods to accomplish the association of a descriptor to a resource.


The decision whether URIQA and the M* methods are a good approach isn't really just a matter of figuring out if they can be hacked into most common httpd servers.

If the URIQA authors are serious about getting adoption as a standard, they should submit it for a standards process as well as work with an organization like Apache to get it included in standard distributions.

It seems to me that the IETF would be the appropriate venue given the fact this is an extension of the HTTP protocol. There are many real deployment issues with introducing a new HTTP method and real cost to the web. It is not my place to speculate on such ramifications because HTTP is not my area of expertise.

I would love to see Nokia submit URIQA as an I-D for review by the HTTPbis working group. I am sure they can offer some valuable insight. If this was done in the past, I would love if someone could point me to it.

Until URIQA is proposed as a standard (with some clarity regarding its licensing terms which I could not find other than a copyright statement at the bottom of the page), it would not be possible for me to treat it as anything but an interesting idea. And while at it, why not propose my own methods? Maybe LGET to get just the Link headers...

The empirical data I would like to see is where is URIQA deployed, what's the scale of the deployment, what applications are using it, etc.


> -----Original Message-----
> From: Jonathan Rees [mailto:jar@creativecommons.org]
> Sent: Wednesday, March 04, 2009 9:55 PM
> To: Eran Hammer-Lahav
> Cc: Patrick.Stickler@nokia.com; julian.reschke@gmx.de; connolly@w3.org;
> www-tag@w3.org
> Subject: Re: Uniform access to metadata: XRD use case.
> On Feb 24, 2009, at 9:00 AM, Eran Hammer-Lahav wrote:
> > I'll separate the two for my next draft and correct this.
> >
> > Adding URIQA support in many hosted environments or large corporate
> > deployment isn't simple. It sets a pretty steep threshold on
> > adoption [1]. I actually like the MGET approach a lot, but I can't
> > sell it to 90% of my use cases. Consider me an extreme pragmatists...
> >
> > EHL
> >
> > [1] http://www.hueniverse.com/hueniverse/2009/02/the-equal-access-
> principal.html
> I don't know about hosted environments and corporate deployments
> generally, but one thing I like about Link: is that in Apache, at
> least, it can be inserted using a directive in an .htaccess file.
> http://httpd.apache.org/docs/2.0/mod/mod_headers.html
> It looks as if the Apache 'script' directive could be used to enable
> URIQA, but it requires installation of a CGI script (or something
> similar), raising the bar a teeny bit (perhaps beyond
> what's practical in certain deployments). (Not that .htaccess is
> always permitted to use the header directive anyhow.)
> http://httpd.apache.org/docs/2.0/mod/mod_actions.html
> The problem is that I believe both Eran and Patrick, who say
> conflicting things. We have talked a lot about technical merit and
> generalities. Since the questions of practicality and simplicity are
> empirical any hard data pro or con either side would be helpful,
> especially as regards non-Apache platforms.
> Jonathan
Received on Thursday, 5 March 2009 07:01:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:28 UTC