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

["Joel M. Halpern" <[e-mail]>]

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
>>>
>>>
>>
>>
>>
>