Should specifications take sides in the httpRange-14 debate?

Several members of the WebID CG met last month at TPAC, and one major
outcome backed by timbl was to standardize WebID on hash URIs because they
are easier to implement/deploy compared to 303s. Quoting from the new spec
[1]:

A WebID is a URI with an HTTP or HTTPS scheme, containing a URI fragment
> identifier (i.e. a # symbol) and which uniquely denotes an Agent (Person,
> Organisation, Group, Device, etc.). The URI without the fragment identifier
> denotes the WebID Profile page.


This decision made a few members of the group uncomfortable including
myself [2-4] and generated a lot of discussion on the mailing list. I
wasn't at TPAC to hear Tim's arguments, but I got to meet him today and
asked about his reasoning. Note that I've never been against hash URIs, and
I agree that they make sense for WebID (and many other scenarios). I use
them myself. What makes me and others uncomfortable is to see a spec taking
sides in the httpRange-14 debate by mandating one approach, when this
debate is still on-going and some people are working on a possible new
resolution. Should specifications relying on HTTP URIs take sides and pick
a "winner" in the httpRange-14 debate? I would much rather see these
specifications refer to the appropriate standard for publishing
non-information resources on the Web. I know we don't have such standard
today (at least one that people are happy with), and that's part of the
problem. I see at least a couple of risks for a specs like WebID to set in
stone a specific kind of URI. First, it means that whichever new resolution
that comes out of the debate might make the existing WebIDs obsolete.
Secondly, having deployment of one kind of URI might influence the TAG
towards choosing the most deployed method to avoid any disruptive
resolution, when a disruptive resolution is maybe what is needed.

If Tim fells strongly about hash URIs based on the experience of several
members of the community who got burnt with deploying 303 redirects, I'd
like to ask that such recommendation be formalized at a higher level than
each individual spec, so that groups writing specs such as WebID don't have
to go through the same permathread over and over. How close are we with
regards to a potential resolution of httpRange-14? What needs to happen to
reach such resolution? What do you recommend us to do in the meantime? Are
there precedents where specifications mandated a type of URI deployment? If
the TAG isn't willing to find a resolution, is there any Working Group
which might be interested in pursuing this goal? LDP?

-- 
Steph.

[1] https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html
[2] http://lists.w3.org/Archives/Public/public-webid/2012Nov/0135.html
[3] http://lists.w3.org/Archives/Public/public-webid/2012Nov/0142.html
[4] http://lists.w3.org/Archives/Public/public-webid/2012Nov/0137.html