Larry, This may be just an expansion on Carsten's "URIs are not just for browsers" but the two main difficulties with that scenario are: (i) It blows off all non-browser uses of URIs. To draw an example from your earlier message, while FTP may not be in general use on the public Internet any more, especially from browsers, it is still widely supported in text editors and for retrieval of information from repositories [1], many of whom have adopted or accept an FTP URI syntax. The recent discussion of email address syntax and validity in HTML [2] (of which you have been a part) and discrepancies between what the web allows, IETF Standards, and plausible practices when email addresses are used as identifiers may be another example, albeit an indirect one. (ii) It might be one thing to say (referencing RFC 3986) that there are no locator URIs other than URLs, parse the URL-specific material out of 3986, and see if what is left in worse publishing as a replacement. But saying that all URIs are URLs, URLs are being taken over by WHATWG, and 3986 should be obsoleted (taking anything non-URL-ish that remain with it) presumably deprecates all name-type URIs, including URNs. My impression is that there is a significant portion of the Internet community, including some national governments and repository libraries, that does not want to go there. The document you cited [3] also reinforces my concerns about WHATWG as a setter of standards for the Internet based on what a small number of browsers do and as an actor in this space that does not play well with others. As one handy example, Section 3.2 is inconsistent with DNS specifications (RFC 1034/RFC 1035 included) that do not require that labels in FQDNs for "hosts" conform to the preferred syntax. It also depends on the so-called Public Suffix List, which is known to be problematic (as it goes on the warn... sort of) and uses a concept of _registerable domain_ that is inconsistent with domain trees in which the sorts of registrations they are talking about may exist at multiple levels (see RFC 1480 for an interesting example that, in combination with public suffix ideas, recently bit me). As another, Section 3.3 uses terminology and procedures that were deprecated in 2010. More generally, that section is based, not on IETF Standard IDNA, but on an interpretation/ profiling of Unicode UTS#46 that amounts to "IDNA2003 as extended by Unicode forever; IDNA2008 never". If one accepts the hypothesis that the Internet is evolving, or has already evolved, to the point that the web (presumably as defined by W3C and WHATWG) is all that counts, all non-web applications are obsolescent and browsers are the only applications that count, little or any of the above is actually a problem. For at least some of us who do not believe that, perhaps because of advancing age and accompanying stick-in-the-mud tendencies, it feels like a probably. best, john [1] Where the data are public and, in most cases, the fact that one has accessed it is of even less interest, and less concern from a privacy standpoint, than one's choice of sources for the daily news. [2] https://github.com/whatwg/html/issues/4562 [3] https://url.spec.whatwg.org/ --On Friday, July 17, 2020 22:50 -0700 Larry Masinter <LMM@xxxxxxx> wrote: >> > If the URL spec moves >> >> Why would that happen? >> >> Brian > > https://url.spec.whatwg.org/#goals > > Main goal: "Align RFC 3986 and RFC 3987 with contemporary > implementations and obsolete them in the process." > > I would expect more stringent rules that would help > interoperability more than "specification required" - Must > have proof-of-concept implementation, two or more browsers > commit to implement - Drop or deprecate when two or more > browsers do, as is happening with "ftp:" URLs > > -- > https://LarryMasinter.net https://going-remote.info > >
