RE: Appeal from Tim McSweeney regarding draft-mcsweeney-drop-scheme
John C Klensin <john-ietf@jck.com> Sat, 18 July 2020 18:59 UTC
Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 929E03A0C3B for <ietf@ietfa.amsl.com>; Sat, 18 Jul 2020 11:59:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJdjTnEy4SGn for <ietf@ietfa.amsl.com>; Sat, 18 Jul 2020 11:59:08 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD5CF3A0C3A for <ietf@ietf.org>; Sat, 18 Jul 2020 11:59:07 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1jws2t-0007CN-Uj; Sat, 18 Jul 2020 14:58:51 -0400
Date: Sat, 18 Jul 2020 14:58:46 -0400
From: John C Klensin <john-ietf@jck.com>
To: Larry Masinter <LMM@acm.org>, 'Brian E Carpenter' <brian.e.carpenter@gmail.com>, 'Mark Nottingham' <mnot@mnot.net>
cc: 'Carsten Bormann' <cabo@tzi.org>, 'IETF' <ietf@ietf.org>
Subject: RE: Appeal from Tim McSweeney regarding draft-mcsweeney-drop-scheme
Message-ID: <50B333D9F7634FA432FF28AC@PSB>
In-Reply-To: <00a601d65cc7$64f8c2c0$2eea4840$@acm.org>
References: <CAL0qLwa9YYuT6J5vQYYJqkEf6ORiHJaf3zh_m=wyLHojaGPU3g@mail.gmail.com> <42958B5B-8EC4-449A-9B7F-B834285369AC@vigilsec.com> <01a701d65b90$9ffeea30$dffcbe90$@olddog.co.uk> <DD0E2DCC-707A-4702-9414-44B68A1B7BE4@tzi.org> <CAKKJt-eCdde6PY5egSg5aPL4_2LAjK5+dnhkUSiVpLiewYemRw@mail.gmail.com> <CAHw9_i+336sJq3oFCWTkeYFk8vmN1zki2qMfTYmgXkhJ6Z=-gg@mail.gmail.c om> <92415955-BD28-407C-A365-5ADFFE8164C9@tzi.org> <CAHw9_iKO+AjGN8TgjvC3H4=b-FNAx7=3dQdB=4QSVfzQr9o=bg@mail.gmail.com> <CAKKJt-enJVNSHOYj4x3caw4FAG5AjKyO70fxS_Rf6sTKwwtQvw@mail.gmail.c om> <012701d65c68$74b91890$5e2b49b0$@acm.org> <25DD0A8D-E59B-4D99-9A58-D986E3CD50D2@mnot.net> <008401d65cbb$c7806ad0$56814070$@acm.org> <2c572326-21a9-594f-4348-d717173769ea@gmail.com> <00a601d65cc7$64f8c2c0$2eea4840$@acm.org>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/Oh6hGpFwOzAPkFFpBnXVln5nGME>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 18 Jul 2020 18:59:10 -0000
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@acm.org> 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 > >
- Re: Appeal from Tim McSweeney regarding draft-mcs… Tim Bray
- RE: Appeal from Tim McSweeney regarding draft-mcs… Larry Masinter
- Appeal from Tim McSweeney regarding draft-mcsween… Murray S. Kucherawy
- Re: Appeal from Tim McSweeney regarding draft-mcs… Russ Housley
- RE: Appeal from Tim McSweeney regarding draft-mcs… Adrian Farrel
- Re: Appeal from Tim McSweeney regarding draft-mcs… Brian E Carpenter
- Re: Appeal from Tim McSweeney regarding draft-mcs… Carsten Bormann
- Re: Appeal from Tim McSweeney regarding draft-mcs… Spencer Dawkins at IETF
- Re: Appeal from Tim McSweeney regarding draft-mcs… Warren Kumari
- Re: Appeal from Tim McSweeney regarding draft-mcs… Carsten Bormann
- Re: Appeal from Tim McSweeney regarding draft-mcs… Warren Kumari
- Re: Appeal from Tim McSweeney regarding draft-mcs… Spencer Dawkins at IETF
- Re: Appeal from Tim McSweeney regarding draft-mcs… Mark Nottingham
- Re: Appeal from Tim McSweeney regarding draft-mcs… Eric Rescorla
- RE: Appeal from Tim McSweeney regarding draft-mcs… Larry Masinter
- Re: Appeal from Tim McSweeney regarding draft-mcs… Brian E Carpenter
- RE: Appeal from Tim McSweeney regarding draft-mcs… Larry Masinter
- Re: Appeal from Tim McSweeney regarding draft-mcs… Carsten Bormann
- RE: Appeal from Tim McSweeney regarding draft-mcs… John C Klensin
- Re: Appeal from Tim McSweeney regarding draft-mcs… John C Klensin
- WHATWG [was: Appeal from Tim McSweeney regarding … Brian E Carpenter
- Re: WHATWG [was: Appeal from Tim McSweeney regard… Joel M. Halpern
- Re: Appeal from Tim McSweeney regarding draft-mcs… Larry Masinter
- RE: WHATWG [was: Appeal from Tim McSweeney regard… Larry Masinter
- Re: WHATWG [was: Appeal from Tim McSweeney regard… Rob Sayre
- Scheme Registration (was Re: Appeal from Tim McSw… Ben Campbell
- Re: Appeal from Tim McSweeney regarding draft-mcs… Mark Nottingham
- RE: Appeal from Tim McSweeney regarding draft-mcs… Larry Masinter
- RE: Appeal from Tim McSweeney regarding draft-mcs… Larry Masinter
- Re: Appeal from Tim McSweeney regarding draft-mcs… Martin Thomson
- Re: Appeal from Tim McSweeney regarding draft-mcs… Larry Masinter
- RE: Appeal from Tim McSweeney regarding draft-mcs… John C Klensin
- Re: Appeal from Tim McSweeney regarding draft-mcs… Ted Hardie
- Re: Scheme Registration (was Re: Appeal from Tim … Ted Hardie
- Re: Appeal from Tim McSweeney regarding draft-mcs… Mark Nottingham
- Re: Appeal from Tim McSweeney regarding draft-mcs… Phillip Hallam-Baker
- RE: Appeal from Tim McSweeney regarding draft-mcs… Adrian Farrel
- Re: Appeal from Tim McSweeney regarding draft-mcs… tom petch
- Re: Appeal from Tim McSweeney regarding draft-mcs… Eric Rescorla
- RE: Appeal from Tim McSweeney regarding draft-mcs… Adrian Farrel
- Re: Appeal from Tim McSweeney regarding draft-mcs… Salz, Rich
- Re: Appeal from Tim McSweeney regarding draft-mcs… Salz, Rich
- Re: Appeal from Tim McSweeney regarding draft-mcs… Mark Nottingham
- Re: Appeal from Tim McSweeney regarding draft-mcs… IETF Chair
- Re: Appeal from Tim McSweeney regarding draft-mcs… IETF Chair
- Re: Appeal from Tim McSweeney regarding draft-mcs… IETF Chair
- Re: Appeal from Tim McSweeney regarding draft-mcs… Mark Nottingham
- Re: Appeal from Tim McSweeney regarding draft-mcs… Timothy Mcsweeney
- Re: Appeal from Tim McSweeney regarding draft-mcs… Timothy Mcsweeney
- Re: Appeal from Tim McSweeney regarding draft-mcs… Timothy Mcsweeney
- Re: Appeal from Tim McSweeney regarding draft-mcs… Timothy Mcsweeney
- Re: Appeal from Tim McSweeney regarding draft-mcs… Rich Kulawiec
- Re: Appeal from Tim McSweeney regarding draft-mcs… Timothy Mcsweeney
- Re: Appeal from Tim McSweeney regarding draft-mcs… Timothy Mcsweeney
- Re: Appeal from Tim McSweeney regarding draft-mcs… Timothy Mcsweeney