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

Re: [LRDD] Add 303 as fourth LRDD method

From: ashok malhotra <ashok.malhotra@oracle.com>
Date: Sat, 20 Jun 2009 09:31:20 -0700
Message-ID: <4A3D0ED8.6000805@oracle.com>
To: Jonathan Rees <jar@creativecommons.org>
CC: www-tag@w3.org
Hi Jonathan:
The description resource will be a set of links, correct?
If so, should we say something like "the same description resource 
should be returned by the various methods"
This needs a bit of tweaking as you will sometimes get the resource and 
sometimes a URI to the resource.

I made such a comment when I first reviewed the spec and Eran was 
sympathetic to it and said
they would address it in a future draft.

All the best, Ashok

Jonathan Rees wrote:
> LRDD [1] is being discussed on www-talk, but I thought I'd post the
> following here so that we could talk about it before I forward it on
> to Eran, to make sure I'm not missing some subtlety. Maybe y'all could
> mull this over before we discuss my review of HTTPbis GET/303 at the
> F2F.
> Dear Eran:
> With HTTPbis effectively endorsing the linked-data use of GET/303 to
> obtain description resources, I'd like to suggest the following tweak
> to LRDD:
> In addition to the three methods for obtaining description resources,
> add a fourth, namely to look for a description resource URI in the
> Location: field of a 303 response.
> That is, if you do a GET looking for a Link: or 200/<link>, and
> instead get a 303, use the Location: URI as the URI of the description
> resource.
> In no cases does this lead to any additional network traffic.
> This establishes harmony between LRDD and the now well-established
> linked data practice of using 303 to designate description resources.
> If a 303 response has both Link:/describedBy and Location: , we can
> treat the redundancy the same way redundancy is treated among the
> other LRDD methods.
> Best
> Jonathan
> [1] http://tools.ietf.org/html/draft-hammer-discovery-03
Received on Saturday, 20 June 2009 16:32:05 UTC

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