Re: [LRDD] Add 303 as fourth LRDD method

I have been travelling for the past 3 weeks and will finally get home tomorrow and addressing LRDD's next iteration is my top priority. There is a longer explanation coming about what I am planning to do with LRDD and how host-meta is going to be replaced by a combination of a new I-D for a well-known directory instead (called /.well-known/) and an XRD file (/.well-known/host-meta).

The other significant change is that I plan to "demote" the describedby relation type from a LRDD requirement to a recommended relation type *in addition* to an application specific relation type (if needed). Working with a couple of other groups on real use cases for LRDD, I have realized that LRDD works better as a template rather then a framework. It is more of a BCP than normative required text...

I promise to fully update you on this development and the thinking behind it in a day or two. This is all very much a work in progress so if this sounds wrong to anyone, please don't be too alarmed and wait for my full update.

As for the proposal below, my first question would be if 303 is being repositioned by HTTPbis to *mean* a descriptor or is it just that HTTPbis is blessing the use case of a 303 in such a way as a specialization of "See Other"? My second question is how such a use of 303 can have a relation type and media type which are two important components of the Link construct (which is what the L in LRDD is all about). LRDD takes Mark's Link I-D and builds a simple template on top of that. I am not sure how I can extend a 303 reply to have a similar semantic meaning as a Link.

Ideas?

EHL




On 6/20/09 8:24 AM, "Jonathan Rees" <jar@creativecommons.org> 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