Goal: Getting a fixed document release

[bagder]

I would like to amend to the goals of this spec to have the ultimate goal of becoming a fixed specification - including a rough time schedule to reach that point. Something to refer back to for years to come, to bring all URL-using tools, browsers and utilities around. To file bugs against.

I would then like a call-for-participation to the world of URL producers and users and invite them and there should some sort of way to discuss matters other than github issues. To try to reach consensus on the points where we don't have them today.

A great step toward that would be to clearly identify and document differences between RFC3986 to this. Is there any such attempts already?

The world of URLs are still today a mishmash from RFC3986 to this spec and everything in between and I think the Internet would benefit from us trying to herd everyone back into one fold. The one true URL spec.

I think setting up some stricter goals for the outcome and guidelines for participating would help. As a representative for the world outside of browsers (even if I'm also working on browsers), I have never felt invited nor appreciated in these circles (I'm sure that's all my fault, don't feel accused) - but if there's perhaps a few others with my sentiment, there are lots of possible participants in such a work that aren't here today because this group is not the regular place where standards like this are made - I and others think of the IETF as the natural place for that.

(Ref: One URL standard please on my blog.)

[annevk]

A great step toward that would be to clearly identify and document differences between RFC3986 to this. Is there any such attempts already?

I don't think there's been any recent attempt.

One problem with setting a date is that there's still open issues. Those require tests, changes to the standard, and changes to implementations. It's a little bit unclear to me how we can commit to a date when we don't know how much work it is to get everything done.

[bagder]

I think it would still be very valuable. It would signal a clear intent and it would introduce a dead-line and an incentive to close issues in time before that. Getting to a stable release will greatly encourage wider adoption. For all the parts of the world with long upgrade cycles and long-term visions.

And a date wouldn't have to be written in stone. It can be changed if deemed unreasonable. And even when one version of the spec is shipped, there's of course most likely going to be an updated version in a future.

[annevk]

The problem is that we don't know if it's stable until all of it's been shipped in a couple of browsers. I wouldn't want to promise anything like that only for it to not be true. What's wrong with continuing to iterate and declare it stable once we know it is?

[bagder]

We can't be compliant with a spec that moves.

As long as it isn't stable, it will be considered "work in progress" and that will stand in the way of adoption and as long as there's no clear intent to ship a stable spec, I think there's less interest from the wide URL-using audience to be part of this effort. It's just a continued spiral of documenting what browsers do and browser do what is documented. Ad infinitum.

What does "stable" mean anyway? You've worked on this for a while and it isn't stable yet. What says it will ever be stable by these measures? Are there any signs of things narrowing down?

[annevk]

Browsers converging is a sign of things stabilizing, but it's taken a long time for them to start implementing based on the standard. Safari has done so recently and that's helped a lot. Servo did it quite a while ago, but that's only now making its way into Firefox and that hasn't really been tested for web compatibility as far as I know.

That, coupled with much more tests, should give us a sign for when things are stable. I don't really share the spiral impression or "ad infinitum". Currently the standard has a number of issues and those need to be addressed. And then browsers need to align and proof that it works in practice. After that there would no reason for further change to the parser.

[annevk]

And to be clear, new non-browser implementations can help us get there faster too. They have helped tremendously so far in validating the prose, the tests, and adding significant amounts of new tests that further help with the eventual goal of reaching full interoperability.

[masinter]

1. include (an update of) https://tools.ietf.org/html/draft-ruby-url-problem-01s
   Yes, there are other specs
   Yes, there are other non-HTML non-web applications that only do 3986 even if it needs a whatwgURL -> ietfURI intake transformation somewhere (say an older PDF).

[jgrisham]

1. include (an update of) https://tools.ietf.org/html/draft-ruby-url-problem-01s

Updated link for the above 2015-era draft: https://tools.ietf.org/html/draft-ruby-url-problem-01

---

Some may also be interested to peruse Larry Masinter’s many resource-name-related drafts and RFCs that were written over a 20+ year period.