Two httpRange-14 change proposals

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.

Change proposal: No change

Summary

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.

Rationale

The "httpRange-14 resolution" reflects the bulk of current practice. Rocking the boat at this late stage is not likely to be productive.

Details

None

  1. Why not "hash URIs"? "Hash URIs" are an acceptable solution and should be used when 303 performance and deployment concerns argue against the use of 303. Users should be alerted to the possibility of using the pattern http://z/a#_ http://z/b#_ ... rather than http://z#a http://z#b in order to avoid certain problems with the latter pattern, as discussed in http://www.w3.org/2001/tag/awwsw/issue57/latest/
  2. Why is "303" unacceptable? It is acceptable, except when performance and ease-of-deployment are concerns. When these are concerns "hash URIs" should be used.
  3. When is a given 200 response payload to be a nominal URI documentation carrier for the URI? There is no agreement to ever do this.
  4. When does a given 200 response payload mean that the identified resource is nominally an information resource? Always.

Impact

Positive effects

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.

Negative effects

This will not make things any worse than they are, since this proposal codifies the status quo.

Risks

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.

References

Change proposal: Withdraw

Summary

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.

Rationale

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.

Details

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).

  1. Why not "hash URIs"? Hash URIs are fine.
  2. Why is "303" unacceptable? It is acceptable.
  3. When is a given 200 response payload to be a nominal URI documentation carrier for the URI? Never (no consensus).
  4. When does a given 200 response payload mean that the identified resource is nominally an information resource? Never (no consensus).

Impact

Positive effects

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).

Negative effects

None known, other than that Web architecture might become more difficult to explain.

Risks

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.

References

  1. HTTPbis part 2