Call for proposals to amend the "httpRange-14 resolution"

Jonathan A Rees, 29 February 2012

In 2002 the issue of how use of URIs in RDF interacts with use of URIs on the "good old-fashioned hypertext Web" was raised, and debate has been raging ever since. The TAG weighed in with its opinion in 2005 with the so-called "httpRange-14 resolution". Community consensus has not held very well, and ever since then there have been periodic calls to amend (perhaps withdraw) the resolution. The primary concerns are number of round trips involved in 303 redirections and their cacheability, and the difficulty of deploying 303 redirects on hosting servies.

It's time to make progress on this issue. To attempt to garner some consensus I'm calling for concrete proposals for amending the resolution. Reinforcement of the status quo and total withdrawal of the resolution (no consensus / agree to disagree) are just two particular options to be weighed equally among others. A wide variety of design alternatives have been proposed, and we encourage champions for workable designs to come forward with complete proposals.

From a process point of view, what we are trying to do is to obtain a community consensus resolution to TAG ISSUE-57; see also the TAG "product page" on URI Documentation Discovery. ISSUE-57 is primarily about the performance of 303 redirects but is also used to track related concerns such as deployment difficulties. The most recent TAG discussion on the topic was at its January face-to-face meeting.

If you don't know what the fuss is about please consult "Interoperability of referential uses of hashless URIs".

Rules of engagement

Here are the rules of engagement for this change proposal process:

  1. We seek well-considered change proposals relating to the problem that 303 redirects were meant to solve from all quarters, especially the Semantic Web and Linked Data communities.
  2. Proposals will be accepted starting 29 February 2012.
  3. Write your change proposals using "Understanding URI Hosting Practice as Support for URI Documentation Discovery" as a baseline document (i.e. the one that is to be changed). This document is my attempt to rationally reconstruct the "httpRange-14 resolution" and place it in the context of other specifications.
  4. Use this template: http://www.w3.org/wiki/HTML/ChangeProposalTemplate for preparing change proposals. "High-level prose descriptions" will be accepted if adequately clear and complete. "Conformance class changes" may be omitted.
  5. Submit proposals via email to www-tag@w3.org, which is where they will be discussed.
  6. Please submit by one month from the start date (29 March 2012); preferably sooner to provide more lead time for discussion at the April 2-4 TAG face-to-face meeting.
  7. Please be prepared to interact with TAG members on revising proposals over the following three weeks (through 19 April).
  8. We encourage people to work together on change proposals, in order to improve their chance of commanding consensus.
  9. Kindly avoid arguing in the change proposals over the terminology that is used in the baseline document. Please use the terminology that it uses. If necessary discuss terminology questions on the list as document issues independent of the 303 question.
  10. The TAG, with the help of the community via the www-tag list, will then discuss (acting in a role similar to the "the Working Group" in the HTML Working Group escalation process).
  11. If it seems like it would help, the TAG may decide to schedule a "town meeting" to hammer out a solution.
  12. The TAG will come to a decision on what document to publish and/or advance. The disposition of the document will then be determined. It may move to W3C Recommendation track (starting with FPWD and if all goes well ending with Architectural Recommendation), be published as a Finding or Note, or be moved to a different venue. Further revisions will be expected as review continues.
  13. The TAG is not accustomed to using a formal change proposal process, so be prepared for some degree of process improvisation.

I have prepared a list of design questions, issues, and options in "Providing and discovering definitions of URIs". Proposals may be based on material in this document if desired, and attention to points raise here is advised as it may be consulted during the review process as well.

In particular any change proposal that alters the interpretation of HTTP 2xx responses relative to the baseline document should be accompanied by notes explaining

  1. why the "hash URI" solution is unacceptable as the preferred discovery method (i.e. why discovery for hashless URIs matters),
  2. why the "303" solution is unacceptable as the preferred discovery method for hashless URIs,
  3. when (if ever) a given 200 response payload is to be a nominal URI documentation carrier for the URI,
  4. when (if ever) a given 200 response payload means that the identified resource is being said to be an information resource.

About the baseline document

In documenting the context of the httpRange-14 resolution, many new potential issues arise simply with the way the document itself is written, including its scope and editorial style. Readers are encouraged to raise such issues even if they do not bear directly on the 303 problem.

The editor has begun a list of issues that have been raised pertaining to the document.