draft-mcsweeney-drop-scheme-01

Ben Niven-Jenkins <ben@niven-jenkins.co.uk> Fri, 31 July 2020 08:47 UTC

Return-Path: <ben@niven-jenkins.co.uk>
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 320EA3A111B for <ietf@ietfa.amsl.com>; Fri, 31 Jul 2020 01:47:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.916
X-Spam-Level:
X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 7cWaFqPDj8vv for <ietf@ietfa.amsl.com>; Fri, 31 Jul 2020 01:47:22 -0700 (PDT)
Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A4B43A1133 for <ietf@ietf.org>; Fri, 31 Jul 2020 01:47:21 -0700 (PDT)
Received: from cpc93786-hari17-2-0-cust357.20-2.cable.virginm.net ([82.36.97.102] helo=[192.168.0.11]) by smtp03.mailcore.me with esmtpa (Exim 4.92.3) (envelope-from <ben@niven-jenkins.co.uk>) id 1k1QhD-0003Xh-NP; Fri, 31 Jul 2020 09:47:20 +0100
Content-Type: multipart/alternative; boundary="Apple-Mail=_4D22E583-9641-46C1-BBA5-51C9E4A4B1BD"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Subject: draft-mcsweeney-drop-scheme-01
From: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
X-Priority: 3
In-Reply-To: <415158810.625360.1596037241973@email.ionos.com>
Date: Fri, 31 Jul 2020 09:47:18 +0100
Cc: ietf <ietf@ietf.org>
Message-Id: <E69E1452-AEAF-42BD-B1FE-0B0F91A9EB70@niven-jenkins.co.uk>
References: <901180194.603556.1595969809620@email.ionos.com> <6BD2F701-E710-4971-AB27-7FE143F0DAD2@cooperw.in> <1413716743.604142.1595970565369@email.ionos.com> <CAL0qLwaS-_hWpsc068PbZYeE+Znqr1YG0MwzuC=S3BaKXViPDg@mail.gmail.com> <2146976118.606050.1595973326973@email.ionos.com> <c54c046b-e374-20f5-c8db-fc1432c47d97@foobar.org> <1446592900.620726.1596031615380@email.ionos.com> <6182F737-48C3-4EEC-B41C-0FCB3961A8BD@akamai.com> <1404739143.621548.1596032857882@email.ionos.com> <D99E5EA1-904A-48C1-A09C-AF2ABF3934E7@akamai.com> <2104612796.622036.1596033432279@email.ionos.com> <0B1ABA39-A058-4C4C-8A57-C4A2EB64B817@akamai.com> <415158810.625360.1596037241973@email.ionos.com>
To: Timothy Mcsweeney <tim@dropnumber.com>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
X-Mailcore-Auth: 9600544
X-Mailcore-Domain: 172912
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/HyiG5iBDXATTkOc2izX1Sjn_XQ0>
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: Fri, 31 Jul 2020 08:47:31 -0000

Hi Tim,

> On 29 Jul 2020, at 16:40, Timothy Mcsweeney <tim@dropnumber.com> wrote:
> 
> Rich,
> 
> >Why is “drop:” unacceptable to you?
> The RFC gave me a choice and I decided on the drop#.  I'm going to stick with it.

I read draft-mcsweeney-drop-scheme-01 and section 2.1 states "The 'drop' scheme was created in a way to be able to reuse current infrastructure making it easy to use and quick to deploy.”

Let us assume for a moment that your proposal is accepted and registered as a URI. There is no widely deployed URI parser that I am aware of that will parse your proposal as you intend and correctly identify the scheme as being ‘drop’ (instead your proposal will be parsed as a relative path of ‘drop’ with a fragment of whatever comes after the ‘#’). 

Therefore, even if you are successful at registering your proposal as a URI you will have failed in your goal to be able to reuse current internet infrastructure because your proposal is not deployable with today’s already deployed internet infrastructure.

It seems to me that you have two choices:

1) Continue to “stick with it” while cutting off your nose to spite your face [1].

2) Take a step back, accept your interpretation of RFC3986 is different to the consensus interpretation of that document, swallow your pride, and adjust your proposal to use ‘:' instead of ‘#' and benefit from being able to leverage already deployed URI parsers to correctly identify your new ‘drop’ scheme.

Regards
Ben

[1] https://dictionary.cambridge.org/dictionary/english/cut-off-your-nose-to-spite-your-face <https://dictionary.cambridge.org/dictionary/english/cut-off-your-nose-to-spite-your-face>