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
