Re: [whatwg/url] Rephrase the stated goal of obsoleting RFC 3986 and RFC 3987 (Issue #703)

> You'll have to elaborate on what is confusing here. 

It is confusing _and likely to upset people_.  

From what I have read, the WHATWG standard was created because the IETF RFCs did not specify error recovery and did not match browser behaviour. It was created in response to the fact that changing browsers to match the RFCs wasn't feasible, and in addition to that, a lack of progress and the fact that nobody else with the IETF took on this task.

Anne, since you wrote the standard, you can amend, clarify or confirm.

It is clear that this split didn't leave the WHATWG on good terms with the IETF community. Given that situation, it is extra important to be careful about the way in which you state your goals. 

* To state that your goal is to make _someone else_'s work irrelevant, is often experienced as hurtful. If this really is your goal, then you can state it in a more careful and nuanced way and write additional motivation.

* It is not clear from this statement that there are **two** standards bodies that specify URLs and that they are **in conflict**. People may take it at face value and fail to assess the situation for themselves. This is both confusing, and upsetting.

* It is not stated why, how, and where the WHATWG Standard diverges from the RFCs. That _is_ confusing.

* It fails to discuss the many similarities. It does not acknowledge the contribution of the people that wrote the RFCs. Given the situation, this it is likely to upset people. Give credit where credit is due.

To be clear, the WHATWG Standard _does_ provide many things that the RFCs did not. It does provide an algorithm. It provides an API specification, there is a reference implementation and a test suite. The WHATWG _does_ make progress on describing the 'real world' situation and on getting web browsers aligned. Why don't you state that?

There are also a lot of things that the RFCs provide that the WHATWG standard _does not_ provide:

* It does not support parsing relative references stand-alone.

* It does not separate syntax and semantics; specifically, it does not contain a concise description of a parser that produces an AST (or CST) and it does not provide a separate, concise resolution algorihtm.

* It does not discuss the multiple normalisation functions that the RFC describes and it does not specify their corresponding normal forms. Note that these different forms have different applications, and they are used in non-browser applications.

* It does not discuss the comparison ladder and the equivalence classes that corresond to these different normalisations. 

* It fails to ensure that normalisation is congruent with resolution. This is as important as preventing reparse bugs.

* It does not specify a reserved and/ or unreserved set of code-points. This is important for applications that require additional processing of the opaque-path, for one example. 

* It does not contain the additional informative text that describes the relevance and the role of each of the components in a human readable form like the RFC does.

* The RFCs provide an _infrastructure_ for other specifications to build on. It is very difficult for other specification authors to use the WHATWG Standard as a 'library' in their own specifications, such as, for example, URL schemes that put additional constraints on the components of URLs, or schemes that parse additional semantic structures from the opaque path as mentioned above. I think this is what @bagder was getting at in [this comment]. 

That's elaborate enough, I hope!

The pont is, you **don't** obsolete the RFCs, you just don't and you don't seem to understand that. People depend on the RFCs and you claim you're obsoleting them, but you don't provide in their needs. That is what is causing upset and hostility. This is no different from the situation a decade ago, where the IETF standards did not provide in the needs of browsers, causing upset an hostility towards them. 

To make it worse, applications that depend on those specific RFC features, are now stuck in a situation where they cannot be web-compatible. This hurts the adoption rate of this standard, and causes more frustrations. It's just not a healthy situation. 

This is why I opened this issue. As long as these issues are not solved, at least be very open about them and discuss them, I believe this would be good for the larger community. 

cc @masinter, @mnot

**Note** that I am not just complaining. I have taken action when you did not respond to these concerns. I wrote this [URL Specification] and a [reference implementation] that passes the tests and adds some of the missing features. It **matches** the behaviour specified in the WHATWG standard. I'm showing you a path forward.

[this comment]: https://github.com/whatwg/url/issues/479#issuecomment-1232815246
[URL Specification]: https://alwinb.github.io/url-specification/
[reference implementation]: https://github.com/alwinb/spec-url

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/url/issues/703#issuecomment-1242937217
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/url/issues/703/1242937217@github.com>