Re: HTTP is a domain name

Timothy Mcsweeney <tim@dropnumber.com> Tue, 06 September 2022 12:00 UTC

Return-Path: <tim@dropnumber.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 37DACC1527A3 for <ietf@ietfa.amsl.com>; Tue, 6 Sep 2022 05:00:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.906
X-Spam-Level:
X-Spam-Status: No, score=-6.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H42UrBU6HBFz for <ietf@ietfa.amsl.com>; Tue, 6 Sep 2022 04:59:56 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58D45C152569 for <ietf@ietf.org>; Tue, 6 Sep 2022 04:59:56 -0700 (PDT)
Received: from oxusgaltgw07.schlund.de ([10.72.72.53]) by mrelay.perfora.net (mreueus002 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MDzNh-1oaA441MKN-00HP25 for <ietf@ietf.org>; Tue, 06 Sep 2022 13:59:55 +0200
Date: Tue, 06 Sep 2022 07:59:54 -0400
From: Timothy Mcsweeney <tim@dropnumber.com>
To: IETF <ietf@ietf.org>
Message-ID: <1813595502.1130414.1662465594632@email.ionos.com>
In-Reply-To: <CAKq15vcVmk=12N=pYFqhBOp+cTMftTZGN-f-MZTRgrbEk-zQZg@mail.gmail.com>
References: <501119701.449636.1661772824621@email.ionos.com> <7ebb7ab5-fa2f-1259-33c0-cfe371204e98@network-heretics.com> <718001507.454153.1661775335429@email.ionos.com> <E90B833E-D67C-4F39-BBBA-F3BC4320AE7A@isoc.org> <557346184.457223.1661776681477@email.ionos.com> <F36F76C28AF6B85C4DFAC84A@PSB> <80fa2ab1-0355-7846-ebfa-a238cb5b208c@gmail.com> <CAC8QAcdRLi4oU+E=BWYsYU65yaCadhsrk_xQsxe4cZsKkRMu6g@mail.gmail.com> <CAKq15vcVmk=12N=pYFqhBOp+cTMftTZGN-f-MZTRgrbEk-zQZg@mail.gmail.com>
Subject: Re: HTTP is a domain name
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
Importance: Normal
X-Mailer: Open-Xchange Mailer v7.10.6-Rev22
X-Originating-Client: open-xchange-appsuite
X-Provags-ID: V03:K1:RXe3JRMDfDst4SFhCvqaHDTvwmcmXDJOxuvVLkqEIKPfF9343jo fhsBARO13lEDgedr4080v30161v5iW65urXI67Wt0BKzyDr2TuHuq2AkUBRJvMEsB3qK5fQ VLIa7I0oF+LnC8f/bPV0pc+D2AfnrdIV+xLtL3j5h2L8MajR2eGSblCwOBWNt7lnuwAK8II jb1vooJp3KzHGTC9MeuKA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:7toVYBlYKag=:hx+xnF0zXPnrtEZf+G8/UM nekssgt0xDoRbCkpR+cHGL3xDsPaH8/KwIu0uqB5lbFNEuY2Pxy4Ghp/TfFotdF+UzkElEHTB Ql7CkTL/sZY4HJYF6BJ0VJJTF8pyw782zOFvvvhr2XqIyRyjRvli1SRlQOCNX49wdJH6EPyEb NqSHkSb7Gl/pra9JXEqvLWafqZd8+MLjyBqSdECiDGmyOVwohXHimInqAB/wmq4Kq6syKKm21 zkfNTcVV9XJpjReZDSkX7PiD2T7eaUXmOc69kNO+lwdwLxAjxmUg93WZz3ELFv3f09345K37C YenAmBBzk9jx3c2lvRKocQ5o42tKAmK0kCXf/QG7c8QW8me6fQGC7lb8p7TSfwCOsXuNR6T9R W8mqcufX3gqyeYbE0JcaozxWqAztEZXVhBJZ8FG595npN9ZvwZZhPmqiIzAVBN9QGTM5hfbaE qjd731sya+ZOx/kcUMwtFCVet5w0nW3ak1w5I7aRHmYLOhViKtycmZY7sXHZ/9j9iPC6DZvY6 XhDyU9IYTC95aam71cM3ZlSJNA+zXFGQ1u8l+rs+ZW+o8ChNTWDQKNUOIbGgcSkGQGU+HLCo7 WtKcdiUcz6U0MnozMNUE/NHRegHZMDj1ZTEunz5RrZGb8pDNjVm2N+86ntDzfQaDX+6W0U0NP 9+YnUN1I09HHa4E4XojPttI/+xafVeuHNQogzmrVIHigHgb0ep7ITAV829S01sbmeWI4leNM4 6FciZIF4xh8x3ZgSncVfvH9L8crCZoGu4TFdtLWVBYVDPof5rbtz+kMrPMA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/HJKcDjb3ibxRUzyR6-a4OtIUO08>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IETF-Discussion. This is the most general IETF mailing list, intended for discussion of technical, procedural, operational, and other topics for which no dedicated mailing lists exist." <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: Tue, 06 Sep 2022 12:00:01 -0000

> On 08/30/2022 10:11 PM EDT Larry Masinter <lmm@acm.org> wrote:
> 
>  
> TL;DR proposal: register drop# as requested (with a note added); then maybe
> we can drop#it.
> 
> A "URI scheme" is kind of like a domain name from the following perspective:
> 
> If you own the top-level domain "pizza" then you have the right to hand out
> names like "joes.pizza" and "best.pizza" and "tasty.pizza". These domain
> names are valuable and you have to pay big bucks to be able to own that
> right.  Not too long ago there was a big flap over the sale of ".org" to a
> private equity group for an ungodly amount. From the point of view of
> imagining how most people in the world think about these things,  "http"
> and ".org" are "drop" (in drop#something) are kind of the same kind of
> thing.
> 
> 
> Now, if you own a URI (or if you like, URL) scheme, like "pizza" (or
> "drop") you might think this gives you the right to hand or manage or
> control names starting with those, like  "pizza:joes or pizza:best", or
> "drop:everything" or "drop:number" or "drop:dead".
> That is, the resource identified was the abstraction, with representations
> of abstractions imply an implicit MIME type with fragment identifiers
> naming the actual concept identified.
> 
> You might even establish a convention that the "drop" URI scheme supports a
> null body so that "drop:" by itself identified "the world of drop numbers"
> and the particular semantics of "the world of drop numbers" was instead
> typically identified by the fragment identifier, so that
> "drop:#best%20pizza" would turn out to identify the source of the best
> pizza (at least as designated by the owner of the "drop" scheme).
> 
> You might even want to build and deploy a set of clients and utilities that
> had the convention that a URI without a host or path but with a fragment
> identifier could be transmitted and understood that the intervening
> punctuation can be elided, allowing usages such as "drop#pizza",
> "drop#everything" or even "drop#dead".
> 
> You might even plan to offer a service (as RealNames and others [1] did)
> using the Common Name Resolution Protocol [2]  (or an alternative meeting
> the same goals [3]). Perhaps you could use an existing registered but
> unused scheme (e.g. "go" [4]) or register a new one (say "drop").
> 
> The syntax of URIs / URLs is not settled; the IETF has RFC 3986[5], WHATWG
> has the URL Living Standard[6], with mare more candidates for a definitive
> specification [7] (message received TODAY!).. Pleas to address the
> situation [8][9] or even consistent implementation in browsers have largely
> gone unheeded [10]. But the one thing that is worse than having two
> incompatible specs for the "same" thing (if they are) is having three.
> 
>  URI/URL scheme registration procedures and guidelines have changed over
> time, mainly ignoring the reality that there is little impact in this world
> in having your scheme registered.
> What matters is what you can get implementors to implement or delegate if
> you have the right apps installed on your phone or pad or desktop. There
> are tons of unimplemented schemes in the IANA registry[11]  and tons of
> implemented schemes with no registration.  Wikipedia[12]  is a better
> source.
> 
> Meanwhile, through BCP 35 RFC 4395, RFC 6085, RFC 8615, RFC 7595 and
> others, we've spent a lot of thought on guidelines and processes that don't
> seem to matter.. In retrospect, the differences between "in use" and
>  "registered" weren't due to problems addressed. Provisional registrations
> based on theory without practice are relatively harmless.  If you register
> schemes such as RFC 2324 (which defined the scheme for
> "%E3%82%B3%E3%83%BC%E3%83%92%E3%83%BC") the internet doesn't care   --
> perhaps in future we might use ☕ 😋:.
> 
> [1] https://datatracker.ietf.org/group/cnrp/
> [2] https://datatracker.ietf.org/doc/rfc3367/
> [3] https://datatracker.ietf.org/doc/rfc2972/
> [4] https://datatracker.ietf.org/doc/rfc3368
> [5] https://datatracker.ietf.org/doc/rfc3986
> [6] https://url.spec.whatwg.org/
> [7] https://github.com/whatwg/url/issues/479#issuecomment-1231491543
> [8] https://daniel.haxx.se/blog/2017/01/30/one-url-standard-please/
> [9] https://datatracker.ietf.org/doc/html/draft-ruby-url-problem-01
> [10] https://twitter.com/samruby/status/1547646895027146753
> [11] https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
> [12] https://en.wikipedia.org/wiki/List_of_URI_schemes
> --
> https://LarryMasinter.net  https://interlisp.org


And it gets rid of spam and robo calls.