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.
- Re: HTTP is a domain name Timothy Mcsweeney
- HTTP is a domain name Timothy Mcsweeney
- Re: HTTP is a domain name Stephane Bortzmeyer
- Re: HTTP is a domain name Bron Gondwana
- Re: HTTP is a domain name Timothy Mcsweeney
- Re: HTTP is a domain name Stephane Bortzmeyer
- Re: HTTP is a domain name Bron Gondwana
- Re: HTTP is a domain name Stephane Bortzmeyer
- Re: HTTP is a domain name Timothy Mcsweeney
- Re: HTTP is a domain name Keith Moore
- Re: HTTP is a domain name Timothy Mcsweeney
- Re: HTTP is a domain name Bron Gondwana
- Re: HTTP is a domain name Olaf Kolkman
- Re: HTTP is a domain name Stephane Bortzmeyer
- Re: HTTP is a domain name Stephane Bortzmeyer
- Re: HTTP is a domain name Stephane Bortzmeyer
- Re: HTTP is a domain name Timothy Mcsweeney
- Re: HTTP is a domain name Viktor Dukhovni
- Re: HTTP is a domain name Olaf Kolkman
- HTTP is a book title Stephane Bortzmeyer
- Re: HTTP is a domain name Keith Moore
- HTTP is four-letter word Keith Moore
- Re: HTTP is a domain name John C Klensin
- Re: HTTP is a domain name Timothy Mcsweeney
- Re: HTTP is a domain name Olaf Kolkman
- Re: HTTP is a domain name Timothy Mcsweeney
- Re: HTTP is a domain name Salz, Rich
- Re: HTTP is a domain name Timothy Mcsweeney
- Re: HTTP is a domain name Brian E Carpenter
- Re: HTTP is a domain name George Michaelson
- Re: HTTP is a domain name Phillip Hallam-Baker
- Re: HTTP is a domain name Timothy Mcsweeney
- Re: HTTP is a domain name Salz, Rich
- Re: HTTP is a domain name Behcet Sarikaya
- Re: HTTP is a domain name Barry Leiba
- Re: HTTP is a domain name Timothy Mcsweeney
- Re: HTTP is a domain name Keith Moore
- Re: HTTP is a domain name Timothy Mcsweeney
- Re: HTTP is a domain name Keith Moore
- Re: HTTP is a domain name Timothy Mcsweeney
- Re: HTTP is a domain name Donald Eastlake
- Re: HTTP is a domain name Mezgani Ali
- Re: HTTP is a domain name Donald Eastlake
- Re: HTTP is a domain name Fred Baker
- Re: HTTP is a domain name John C Klensin
- Re: HTTP is a domain name Larry Masinter
- Re: HTTP is a domain name Brian E Carpenter
- Re: HTTP is a domain name lloydwood@users.sourceforge.net
- Re: HTTP is a domain name Viktor Dukhovni
- Re: HTTP is a domain name Timothy Mcsweeney
- Returning to "drop#" as a URI scheme name (was: R… John C Klensin
- Re: Returning to "drop#" as a URI scheme name (wa… Timothy Mcsweeney
- Re: Returning to "drop#" as a URI scheme name (wa… John C Klensin
- Re: Returning to "drop#" as a URI scheme name (wa… Timothy Mcsweeney
- Re: Returning to "drop#" as a URI scheme name (wa… Timothy Mcsweeney