RE: WHATWG [was: Appeal from Tim McSweeney regarding draft-mcsweeney-drop-scheme]

[Larry Masinter <[e-mail]>]

I didn't mean to suggest that merely by publishing the URL standard that it would automatically change IETF standards. 
(But if you had to choose an implementation, one of which is compatible with the browsers, and one which is compatible with the RFCs, which would you choose?)

With URL schemes, it's hard to get any implementation of consumers of a new scheme until there are enough producers to pay attention.
But who would start producing URLs that most of the deployed consumers can't handle.
(this is true for any common protocol element)

Change "browser" to "URL interpreter" to account for the non-browser implementations.
What I am trying to propose is that new URL schemes that you want to register as "Permanent" should come with a credible deployment strategy (e.g., sufficient coverage of deployed browser/consumers).

--
https://LarryMasinter.net https://going-remote.info

> -----Original Message-----
> From: Joel M. Halpern <[e-mail]>
> Sent: Saturday, July 18, 2020 1:45 PM
> To: Brian E Carpenter <[e-mail]>; Larry Masinter
> <[e-mail]>
> Cc: 'IETF' <[e-mail]>
> Subject: Re: WHATWG [was: Appeal from Tim McSweeney regarding draft-
> mcsweeney-drop-scheme]
> 
> Small distinction.
> Anyone is free to ignore RFCs if they want to.  We have no police.
> Although we do have an understanding with W3C that we will respect each others
> work.
> 
> Having said that, WHATWG is not free to do what I understood Larry suggested,
> which is to deprecate RFCs.  They could ask the IETF to do so.  But they can not do
> so on their own.  (Presuming that by deprecate one means either obsolete or
> move to historic.)
> 
> Yours,
> Joel
> 
> On 7/18/2020 4:37 PM, Brian E Carpenter wrote:
> > Also, looking at the WHATWG material and in particular its rejection
> > of RFC6874, they don't seem to have picked up on the underlying
> > problem that made that RFC necessary: the difference between (a) what
> > one is allowed to type into a browser and (b) what is allowed as a URI
> > on the wire. As the RFC says "Unfortunately, there is no formal
> > distinction between the syntax allowed in a browser's input dialogue
> > box and the syntax allowed in URIs." It's entirely possible that we
> > got it wrong in RFC6874, but until this formal distinction exists, the IETF standard
> is what it is.
> > WHATWG can't change it unilaterally just because it makes their code
> > awkward.
> >
> > They could always come to the IETF and talk about it. I only
> > discovered yesterday that they have an opinion on RFC6874, which was
> > published 7 years ago. (I was aware that Mozilla rejected it 5 years
> > ago, and that on paper it broke CUPS, see
> > https://tools.ietf.org/html/draft-sweet-uri-zoneid-01.)
> >
> > Regards
> >     Brian Carpenter
> >
> > On 19-Jul-20 06:58, John C Klensin wrote:
> >> 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 <[e-mail]>
> >> 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
> >>>
> >>>
> >>
> >>
> >>
> >