Re: [Uri-review] Request for review

Timothy Mcsweeney <tim@dropnumber.com> Sun, 31 May 2020 21:54 UTC

Return-Path: <tim@dropnumber.com>
X-Original-To: uri-review@ietfa.amsl.com
Delivered-To: uri-review@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DAE53A0DFB; Sun, 31 May 2020 14:54:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.795
X-Spam-Level:
X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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 XBMIuIeP5MCq; Sun, 31 May 2020 14:54:05 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (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 BA0033A0DFA; Sun, 31 May 2020 14:54:05 -0700 (PDT)
Received: from oxusgaltgw02.schlund.de ([10.72.72.48]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1MiaDb-1j1mxz1MU3-00fi0q; Sun, 31 May 2020 23:54:00 +0200
Date: Sun, 31 May 2020 17:53:58 -0400 (EDT)
From: Timothy Mcsweeney <tim@dropnumber.com>
Reply-To: Timothy Mcsweeney <tim@dropnumber.com>
To: Larry Masinter <LMM@acm.org>, Michael Wojcik <Michael.Wojcik@microfocus.com>, uri-review@ietf.org
Cc: Eliot Lear <lear=40cisco.com@dmarc.ietf.org>
Message-ID: <1225920323.477357.1590962038349@email.ionos.com>
In-Reply-To: <009601d63790$c79a12f0$56ce38d0$@acm.org>
References: <491516506.246380.1589851279474@email.ionos.com> <5EC9B257.31362.CC5E003@dan.tobias.name> <1783049000.100771.1590323508943@email.ionos.com> <5ECA8A94.23977.101292FE@dan.tobias.name> <1426881880.158099.1590335585858@email.ionos.com> <94368b41-c15b-da2c-421d-fdd9300be6e9@dret.net> <1310141163.159340.1590344745080@email.ionos.com> <BL0PR2101MB102738EF50D7C8AD647E10BBA3B20@BL0PR2101MB1027.namprd21.prod.outlook.com> <1081815563.141711.1590624311343@email.ionos.com> <BL0PR2101MB102762C4CAFACC383412D5D8A38E0@BL0PR2101MB1027.namprd21.prod.outlook.com> <BL0PR2101MB10278A5360398EFF2E73FC0BA38E0@BL0PR2101MB1027.namprd21.prod.outlook.com> <117630321.142251.1590627970509@email.ionos.com> <8ae1641a-74c8-6c2d-7092-6cf53e745fb7@ninebynine.org> <797476254.282655.1590770737009@email.ionos.com> <656ab4ec-df34-c7a4-ed36-79a03623636c@ninebynine.org> <1435838702.391137.1590841215132@email.ionos.com> <DM6PR18MB270066320792DAC3091C6DA4F98C0@DM6PR18MB2700.namprd18.prod.outlook.com> <1924775136.405242.159095255 6836@email.ionos.com> <009601d63790$c79a12f0$56ce38d0$@acm.org>
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
Importance: Normal
X-Mailer: Open-Xchange Mailer v7.10.1-Rev31
X-Originating-Client: open-xchange-appsuite
X-Provags-ID: V03:K1:olsODbCklg5qAMXCzKKKZ5XbhdlYN1TiaN7hMsPQLaToH9gvbDZ pJORJ84wWNdBdd7Tbdrr3mmDVsXqVzxzCa/rBPbOgSpou4KGaj5KFQdW6yiNHs5sr5y8BXa BTcgVuY4wUf0boVJDpTItcvpBBBfHIC2y5SPEp+MpfN7p7ZMlmn7yJVti1y481csnn+A5Qn dmD6mM49RhZy2R6CYLysw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:xRn4utdtiEU=:jVIoXpjLorchMwCgNEPw37 B/6Nzs7kR5tGSm4guofIpk5bhRTYbNGjAs7SmF9zwiLxj8or0W404YDUDNHstPFxehWx7KaB0 SqN2dzwYEtoskpzklycm37reHvhk4A0QE0XmhA/0rbUMmC4lNmt9pjnAY3ezQ78b9LGcLaU41 qX6FXJd+c3P+9ByOymwlcjIonBLd9ziuGatqSOPgmaA0chvwuo2Z2VDGmpuZoOSmY4X98izzr 3d0gizhO0sGSfNT1JfvTTNatGB7IF4UmUWugpHVCU1g7LzfuxDB9VHfejubimI6yVX0olh3tT QNaFJIFAuAjw77CIG5UQtRDrxIGq5S602P/5Uk22pPvUOcyHqjTZXEJGZxjdOZQHKv1LdKeyb NXpd8W6RY26sCQGf3SEpWErEe8G1zMjGEE0yf4XRY6DR+WHmzXWjUW6og+1K8NyP666nBYCPR WxKnYOWpQbdRbJDRWuwgMnCF0GD3+0y6j96BmnPmfuxZlbGjzsMHTcl8VHYu9J+2qZbAgL3CR WdzLj2biOhkJBl/DxBQM/HZV7+/4y5FNECb8886tzzIlsOMJ92IONRRUYoRhPg6gtMD7BaLFD e/a4l+EA+qdY7lm/TwwjDXrxAheKYI58dpZHWVBX67PEXxMzpZdQQWKpP9TAXvJqOJzcnbk7D XCFx3WeYYUkjHYaK7uMLNI5zNhTcmHfZzGcENmf4ZQxJa9Rv0m00egwtQGw/wr01N7s6ibNzK Et086Tj7D85mV0k31D01WeNYStRE/SEdnM3NFljI3rNdBfiWglqEcUZFozwtza32AzzOdWuwI cJlhBSLWrxBbDtPwvScmlAT+9fWD8uweGlIaxBKpNC78qhYln66jCxxqdOOHiolExeZzUUz
Archived-At: <https://mailarchive.ietf.org/arch/msg/uri-review/wXomc99KXvgDacVE5yO6ulD_gpU>
Subject: Re: [Uri-review] Request for review
X-BeenThere: uri-review@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proposed URI Schemes <uri-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uri-review>, <mailto:uri-review-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uri-review/>
List-Post: <mailto:uri-review@ietf.org>
List-Help: <mailto:uri-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 31 May 2020 21:54:07 -0000

Hi Larry, 

Just so its crystal clear in my head, you're saying that the original intent of 3986
was that the colon, and only the colon, was to be used as the gen-delim between
scheme and path regardless of implementation specific sytanx?  I have that right?
On May 31, 2020 at 5:16 PM Larry Masinter <LMM@acm.org> wrote:

  • I noticed two of the original authors are on the email list.  It would
  • be nice to hear what the original interpretation was.


I wasn’t going to respond, but if you want my opinion, it’s that


we should change the registration form for new URI schemes to make this more explicit,

And we should consider updates to BCP 35/BCP 115 (Guidelines and Registration Procedures for URI schemes to figure out a way to terminate this kind of discussion.


I note that this re-(mis-)use of fragment identifier isn’t so different from the URN wish to repurpose “#”.

That we never required media type registrations to explain their interpretation of fragment identifiers. We should.

I note that for HTTP we can say “the fragment identifier isn’t sent to the server, only the base full URL” but that is not actually required and isn’t true for “file” URLs since in that case there is no particular “server”.

I point out https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler" rel="nofollow">https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler

      The https://developer.mozilla.org/en-US/docs/Web/API/Navigator" rel="nofollow">Navigator method registerProtocolHandler() lets web sites register their ability to open or handle particular URL schemes (aka protocols).

     For example, this API lets webmail sites open mailto: URLs, or VoIP sites open tel: URLs.

Which allows you to define “drop” URLs (which of course start with “drop:”)



From: Uri-review <uri-review-bounces@ietf.org> On Behalf Of Timothy Mcsweeney
Sent: Sunday, May 31, 2020 12:16 PM
To: Michael Wojcik <Michael.Wojcik@microfocus.com>om>; uri-review@ietf.org
Subject: Re: [Uri-review] Request for review


>The issue here is that you're misinterpreting RFC 3986.


I noticed two of the original authors are on the email list.  It would

be nice to hear what the original interpretation was.


>To be honest, I don't understand why you're being so difficult about this.


Having a different perspective is no being difficult. 

Imagine the first color blind person telling everyone the grass is dark gray.





On May 30, 2020 at 10:01 AM Michael Wojcik < Michael.Wojcik@microfocus.com> wrote:



From: Uri-review [mailto: uri-review-bounces@ietf.org] On Behalf Of Timothy Mcsweeney

Sent: Saturday, May 30, 2020 06:20

To: Graham Klyne; uri-review@ietf.org

And if people want to make parsers that don't work with the spec it doesn't

become the spec's problem.

That's not the issue here. The issue here is that you're misinterpreting RFC 3986.


3986 section 3 is not ambiguous. The first production is:


URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]


The colon is explicit and not optional. A minimal URI consists of a scheme, a colon, and a hier-part. There's no wiggle room there, and no amount of casuistry regarding other parts of 3986 will change that.


Someone could also point to 1.2.3, where the language clearly notes that the colon is the scheme delimiter; or 3.5, which makes it clear that the hash symbol is always the fragment delimiter. But those arguments are redundant in light of the generic-URI top-level production that begins section 3.


To be honest, I don't understand why you're being so difficult about this. What's your motive for trying to find grounds in 3986 for repurposing the fragment identifier?


--

Michael Wojcik