On Tue, 23 Oct 2012, Ted Hardie wrote:
On Mon, Oct 22, 2012 at 2:46 PM, Ian Hickson <ian(_at_)hixie(_dot_)ch> wrote:
On Mon, 22 Oct 2012, Julian Reschke wrote:
I couldn't agree more! We've been waiting for four years for the
URI working group to get their act together and fix the URL mess.
Nothing has happened. We lost patience and are now doing it
ourselves. ...
Clarifying: there is no URI Working Group, and as far as I can tell,
Whoever. The people complaining that it should be done at the IETF
haven't done any work. That's the complaint. Until they do the work,
Handing things off to the IETF and saying "please go do this work" has a
very low success rate, because that's not how the IETF works.
Ok, but "we disagree with you, do it differently" is not how it works
either.
The IETF works by bringing together folks interested in solving a
particular problem and putting them in a larger context
The problem here is that the bulk of the people here don't seem interested
in solving this particular problem. In fact, many don't seem to even think
that there is a problem to solve.
In this case, the concern is that defining what you are doing as a
revision of the URL standard outside the IETF will:
* lose that larger context
By which I presume you mean "you'll miss good feedback".
My experience with the Web Sockets work at the IETF is that we got way
better feedback (in terms of technical usefulness, relevance, and style)
when it was at the WHATWG than when it was at the IETF. All the good
feedback we got at the IETF was from people who were already participating
in the WHATWG.
So I'm not sure that this is a given.
* use a process which has a bias toward browser viewpoints, which raises
concerns about trade-offs outside that space
Working at the IETF results in the opposite concern, of course.
You're all welcome to participate in the WHATWG.
* generate a fork, either directly or in the creation of two communities
which understand URL to be either a subset of URI in the STD 66 sense or
the "input string to web identifier" sense that Anne's work uses.
If Anne does a good job, then STD 66 can just be updated to contain Anne's
work, and then there's no fork to worry about. If Anne does a poor job,
then people will ignore it, and there's still no fork to worry about. The
only way there could be a problem is if Anne does a good job, so people
pay attention to it, but the IETF for political reasons refuses to
acknowledge it. That's up to the IETF.
It's tedious when people say "you should come here and do the work", and
I apologize that I'm about to say it. But for work which redefines IETF
standards, the IETF is really the place to do it, and preserving that
context is important to making sure that the communities of use retain a
single standard. I share your frustration with the pace of work on
related topics, but I urge you to put energy into the process rather
than simply appropriating the term.
The problem is that we have lost hope that the IETF is somewhere where
this work could even take place. There's too much stop energy (just look
at this thread -- Tim just said we were all wasting our time and should
all shut up!).
But suppose we did try. Let's in fact try: Hi guys, we need to fix STD 66
because it doesn't define error handling. Also it seems to be about time
to merge IRIs and URIs together since implementing IRIs on top of URIs
leads to a confusing implementation experience. We can call the result
just "URLs" since that's what the majority of people call these things.
Anne has a proposal for how to do it:
http://url.spec.whatwg.org/
Does anyone object to us updating STD 66 to using this once it's ready?
How do we go about it?
If you choose not call what you're doing a "URL" but by some other
term ("fleen" is my favorite), then the issue does not arise
Since the IETF doesn't call it a URL anyway, I don't see the problem with
terminology.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'