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
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
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:
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.
Proposals will be accepted starting 29 February 2012.
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
Use this template:
for preparing change proposals. "High-level prose descriptions"
will be accepted if adequately clear and complete.
"Conformance class changes" may be omitted.
- Submit proposals via email to
firstname.lastname@example.org, which is where
they will be discussed.
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.
Please be prepared to interact with TAG members on revising
proposals over the following three weeks (through 19 April).
We encourage people to work together on change proposals, in order
to improve their chance of commanding consensus.
- 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.
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).
If it seems like it would help, the TAG
may decide to schedule a "town meeting" to hammer out a
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
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
"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
why the "hash URI" solution is unacceptable as the preferred
discovery method (i.e. why discovery for hashless URIs
why the "303" solution is unacceptable as the preferred
discovery method for hashless URIs,
when (if ever) a given 200 response payload is to be a nominal URI
documentation carrier for the URI,
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.