Re: [dispatch] RFC 3896 and 3987 vs WHATWG URL Living Standard

[Alwin Blok <[e-mail]>]

> On 10 Jun 2021, at 02:39, Larry Masinter <[e-mail]> wrote:
> 
> A replacement for RFCs 3986 and 3987 wouldn't be my
> first step. Maybe a short standards-track "UPDATES" that points to/contains
> deltas or a new grammar that is more consistent with (tested)
> implementations.

Since I am new to the IETF process, is there a link that I can follow with more information about this?
Specifically, a description of what is an UPDATES, in this case. 


> On 8 Jun 2021, at 08:37, Mark Nottingham <[e-mail]> wrote:
> 
> The issue that Larry links to seems to be taking tentative steps towards aligning the grammar in 3986/7 with what WHATWG does, which is great. If that's incorporated, I think there's still a significant gap that would need to be filled before we can deprecate. 

I don’t know if it will be incorporated. I feel quite a lot of resistance to it. My impression may be wrong though and maybe it will work out just fine. 

> although obviously the W3C has come to peace with HTML living there

Oh…. They should up their game and publish a much simpler but behaviourally equivalent specification of the html parsing chapter only. 

> Looking at this from a different angle, we could also ask ourselves whether 3986/7 should be updated to align with WHATWG URL. I think the answer to that is likely to be no -- not only is the delta apparently very small (according to the comments on the linked issue)

It can maybe just be descriptive, as in: this is the grammar and the behaviour that the WHATWG implicitly specifies. 

The delta between RFC3987 and WHATWG URL is not small. You cannot directly compare the documents, the style of the WHATWG prevents that. But the standard can be (after so much effort…) characterised. That characterisation could be published as an IETF document. That would be great! The diff between that, and RFC3987 should be relatively small. 

> alignment would mean doing things like considering <> to be valid content in URIs. Again, what they're specifying is how to get from an arbitrary string to a URI, not the syntax itself.

The WHATWG explicitly defines valid URLs to always have a scheme. But then it implicitly defines ‘loose URL’s and ‘loose relative URL’s via their ‘basic-url-parser’ function. 

That function specifies, how to get from an arbitrary input string and optionally an ‘URL record’ to a resolved-normalised-URL-record, or failure. 

If you break down that function, you see that it implicitly specifies:

- A grammar for valid URLs and one for loose URLs (incorporating valid and invalid)
- Grammars for relative references
- An encoding normal form for loose URLs
- Several slightly different resolution operations

They don’t seem to be attentively aware of that themselves. 
The solution was pointed out lucidly by David Sheets in 2012:

<https://mailarchive.ietf.org/arch/msg/ietf/iX5a8Bn3JJO98O1Z6BShkRSApY0/>

Kind regards,
-Alwin Blok