Re: Protocol design: the Gemini project

Phillip Hallam-Baker <phill@hallambaker.com> Tue, 01 December 2020 16:40 UTC

Return-Path: <hallam@gmail.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 A139E3A13CA for <ietf@ietfa.amsl.com>; Tue, 1 Dec 2020 08:40:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 N2znP9PIiJ-s for <ietf@ietfa.amsl.com>; Tue, 1 Dec 2020 08:40:54 -0800 (PST)
Received: from mail-yb1-f174.google.com (mail-yb1-f174.google.com [209.85.219.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 349CB3A13C6 for <ietf@ietf.org>; Tue, 1 Dec 2020 08:40:54 -0800 (PST)
Received: by mail-yb1-f174.google.com with SMTP id g15so2423767ybq.6 for <ietf@ietf.org>; Tue, 01 Dec 2020 08:40:54 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ldnmpFYkHV7HaefWlZEVcjxQOInRum+unVlZGYPRuvs=; b=DeWAd5+5F9ajsszg7mejq/2C8JiH198o2csgg9Hl493GadjkK5ifEYQYVTo3U42Mvd tjEMMYPs24VCl6e8I8t/a7J5aH+DhTgM7QoeRshjxhP1UCt4TQnZdfV2t3TziDr16wPw FVKrh2gO0pxScnOLINPzEo4SwH5gpr+SB/RBGA/ERpUMLFwmQZCWoKOdolccefU35ane hiAp0JStl1LXtU8cIHwRTktN/Tbm3AsCMt+OXVGywDOYO0jDbRydNPxe7iLuFx0egMl2 q4cRPk9Mc1MxL/GGweKw0uQjrSerfFT/StvVG6duZZtv7TseoBxdbqpCKijTxoupNrL4 Pilg==
X-Gm-Message-State: AOAM533FpQI+bYSZctcPePOwyWB/Q435ky4WwnnwaRnsLTNVR0ziG+UA IuueACyADWxh/6z3MJ80ZQNm495FM1HhgIP23XA=
X-Google-Smtp-Source: ABdhPJyPS9wYpCziKwoJGv4y2ga91s5YP9yoQGE9Va8Duo9nep9yMZI59qu2i7x0l2wwWlZ7SY9R3UgvQSGXIlYpvU4=
X-Received: by 2002:a25:d04b:: with SMTP id h72mr4858413ybg.523.1606840853268; Tue, 01 Dec 2020 08:40:53 -0800 (PST)
MIME-Version: 1.0
References: <20201130173714.GA15548@sources.org> <4B1B8D0E-52A6-4368-8964-43645ADD754A@strayalpha.com>
In-Reply-To: <4B1B8D0E-52A6-4368-8964-43645ADD754A@strayalpha.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Tue, 01 Dec 2020 11:40:42 -0500
Message-ID: <CAMm+Lwj9ecWvdjbPBwtuYYSEWLnracXgOKjTbFar8PGueRtfug@mail.gmail.com>
Subject: Re: Protocol design: the Gemini project
To: Joseph Touch <touch@strayalpha.com>
Cc: Stephane Bortzmeyer <bortzmeyer@nic.fr>, IETF Discussion Mailing List <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000450bbc05b569caab"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/xGlYMlfB3mgamU6mTm5SLBFbZRE>
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: Tue, 01 Dec 2020 16:40:56 -0000

On Mon, Nov 30, 2020 at 1:37 PM Joseph Touch <touch@strayalpha.com> wrote:

> My primary criticism:
>
> - port 1965 is already assigned
> - new system ports are advised against, per RFC7605
>
> I already let them know.
>
> As to whether the rest is useful, I sincerely hope they’ve studied
> previous protocols they think are too complex. The protocol design space is
> littered with examples of “I think I can do better by doing simpler”, only
> to end up reinventing the wheel (the most infamous example being HTTP vs
> using FTP).
>

Having (re)implemented FTP for LIBWWW, I can assure you that it was done
for very good reason.

FTP is not really an independent protocol. It is actually designed as a
feature add on for Telnet. As a result, FTP is vastly less efficient than
HTTP because you have two socket creations and teardowns per connection.

FTP requires multiple control plane interactions where HTTP requires only
one.

FTP has no provision for transfer of metadata.

FTP doesn't support proxying or caching, both of which were essential in
the early Web when bandwidth was severely constrained.


Of course we could have stuck to vinyl. But FTP is more like grandad's 78s.
There is absolutely nothing to recommend FTP over HTTP. Rsync is vastly
superior for file transfer.

Sometimes the best answer is to simply chuck out the old and start from a
clean slate. Software reuse is good but only to a point and only if the
software in question is fit for reuse. FTP is not and it is high time we
moved beyond it.

The same is becoming true of SMTP. Yes, we can try to continue to prop up a
protocol that has been spammed to death. But the simplest way to get to the
heart of the matter is to switch to a new protocol that has authentication
and end to end encryption built in from the start.

In fact the only good reason to not start from scratch is the difficulty of
deployment. HTTP succeeded so there was really no reason not to switch.


There is absolutely no part of the FTP design I am sorry we left out. None.