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.
- Protocol design: the Gemini project Stephane Bortzmeyer
- Re: Protocol design: the Gemini project Joseph Touch
- Re: Protocol design: the Gemini project Joseph Touch
- Re: Protocol design: the Gemini project Phillip Hallam-Baker
- Re: Protocol design: the Gemini project Keith Moore
- Re: Protocol design: the Gemini project Joseph Touch
- Re: Protocol design: the Gemini project Phillip Hallam-Baker
- Re: Protocol design: the Gemini project Joe Touch
- Re: Protocol design: the Gemini project Larry Masinter