These proposals were prepared by Jonathan A Rees on 1 March 2012 in response to a call for change proposals. They have not yet received TAG review. Please consider these to be drafts subject to update.
The treatment of discovery for hashless URIs in "Understanding URI Hosting Practice as Support for Documentation Discovery" stands as is, superseding (as it says) the "httpRange-14 resolution" without subtantially changing it.
The "httpRange-14 resolution" reflects the bulk of current practice. Rocking the boat at this late stage is not likely to be productive.
None
Obtaining consensus and improving documentation around what is currently a TAG opinion will help reduce uncertainty among developers.
Where the URI isn't known to identify an information resource, the effect of a recorded consensus may be to cause some developers to use hash URIs in preference to hashless URIs, and/or 303 redirects in preference to (potentially nonconforming) 200 responses, perhaps increasing interoperability.
This will not make things any worse than they are, since this proposal codifies the status quo.
Because the "httpRange-14 resolution" does not address the performance and deployment concerns that have been raised other than by offering "hash URIs", some users may decide to ignore it and use retrieval-enabled hashless URIs to refer to things that are not information resources. Whether this creates any problems is not clear.
Vacate the entire document "Understanding URI Hosting Practice as Support for Documentation Discovery". Replace it with formal acknowledgement that consensus on the TAG's "httpRange-14 resolution" could not be reached.
The utility of the "httpRange-14 resolution" has not been demonstrated, it does not appear to completely solve any problems, and it continues to meet with resistance.
HTTPbis already covers the 303 case, so the TAG no longer needs to say anything about it (assuming that part of HTTPbis advances within IETF, which I think it will).
The ongoing arguments will be put to a rest.
Some developers will no longer be held back from using 200 responses in preference to 303 responses, and will thereby achieve their performance and ease-of-deployment objectives (but not in the context of a consensus solution).
None known, other than that Web architecture might become more difficult to explain.
Any benefits obtained to date from the adoption of the httpRange-14 resolution will likely be lost.
RDF and Web architecture might diverge irreversibly.
Documentation for the mechanisms by which semantics of individual http: URIs get their meaning will have to remain scattered across multiple specifications coming from many sources, and this may make the state of affairs harder to learn and implement, compared to advancing something to consensus.