On Tue, 23 Oct 2012, Ted Hardie wrote: > On Mon, Oct 22, 2012 at 2:46 PM, Ian Hickson <ian@xxxxxxxx> 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. `._.-(,_..'--(,_..'`-.;.'