Re: [Uri-review] Request for review

Larry Masinter <> Sun, 31 May 2020 21:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6DDB63A0DA7 for <>; Sun, 31 May 2020 14:16:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3KS_-5rw1vT9 for <>; Sun, 31 May 2020 14:16:42 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::1041]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A79F43A0DA5 for <>; Sun, 31 May 2020 14:16:42 -0700 (PDT)
Received: by with SMTP id k2so4114599pjs.2 for <>; Sun, 31 May 2020 14:16:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=sender:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=imfYO6rm5ZWMiuBBMflmZ4mM5NVMv0YcQdX4D4mfPgM=; b=As1vBiHVYo3Y3vVI2eGUmJiy6XH7wADZWCATSe92XaRv102HEuYFxc99bY2V81JWEp m6KtZX2K07wDy02hMfZJe0UVs+kTmeXvdjt5rpXvPHtB8ALp6trJmsLw2oueCPmDOn+s WBGKfbIgcQHlPmNGRm9gGDsEV3pRhZxi83Az4bWeJK+/6vrYfG8BT+sNIG4q9PPWxk/8 Im7LCL4f37Byfns7y4YgNsJF/Ss/xNayA4fsx7EJLfAn2CGs4k7jteBmXGlrQIPgW5+f YE63B2dFQcz1XHgFVa6eA7sEda70Gu6SUX1b/0EWELOPYoFzcdPdk8xCJqhQUv8qHiYu ksqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:sender:from:to:cc:references:in-reply-to:subject :date:message-id:mime-version:thread-index:content-language; bh=imfYO6rm5ZWMiuBBMflmZ4mM5NVMv0YcQdX4D4mfPgM=; b=rsVQIVhn3cRNGICw1T2+r+klY/h8UMVnQAVjFg+396TBlBfEPjuDcDXVrkGSosSpKX jYHB75WLtm2MpCD0y9FVcyTMatTVFYi1IWD1gE0epfvazCykJsRZaRaqCumUr1ls7LxU ENr6mUtjI++13Re3ic3E5Gk/l9/eX83BSrsdrDdCj7M6PTNceyM/aO2Xk1vk8Xzlzwx5 r+0QC354dDv23gPq71N0TEkKAfXi/0vHHUyyokNedSgGTjNA33EHJLmB92bY6mz7EH/y ey6lDXZNYnl3X5k1IF5YxxHOU4kv/xZqnCYDjCKmUsr1DvDUBxP41Eo3ZnbdfOArtX6s X+Cg==
X-Gm-Message-State: AOAM533Tq9UaElXLM9GYz7hVkLavBE+8fYxDN7H0YDaHPL/JHem0K4a2 nwDSKRGFbgyUpk9Jmv5h6bw=
X-Google-Smtp-Source: ABdhPJzd2l2htIrdsPphFSslb/8xTnImw3QsMIz3sUNKXE4v6PPU3twugmqhyizxC6G6HFsLYJGxTw==
X-Received: by 2002:a17:902:c807:: with SMTP id u7mr4876684plx.16.1590959801920; Sun, 31 May 2020 14:16:41 -0700 (PDT)
Received: from TVPC ( []) by with ESMTPSA id i26sm1641735pfo.0.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 31 May 2020 14:16:40 -0700 (PDT)
Sender: Larry Masinter <>
From: Larry Masinter <>
X-Google-Original-From: "Larry Masinter" <>
To: "'Timothy Mcsweeney'" <>, "'Michael Wojcik'" <>, <>
Cc: "'Eliot Lear'" <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <1924775136.405242.159095255>
In-Reply-To: <>
Date: Sun, 31 May 2020 14:16:40 -0700
Message-ID: <009601d63790$c79a12f0$56ce38d0$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0097_01D63756.1B3C7370"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGymr+RgmqR9KoorXl3tuJq/szTFwJYR2XSAqdVj/oCFtS2vgLcgkTOALiKKd8Dq5pEqAFDTkSgAZtVRbsB/PlolAHSMfbTAeyayrMDDafsLQHTAMmXAsRXq0oBYrpd8AFLHwJIAYT4f9Gn85X5MA==
Content-Language: en-us
Archived-At: <>
Subject: Re: [Uri-review] Request for review
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proposed URI Schemes <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 31 May 2020 21:16:44 -0000

*	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 

      The  <> 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 <> On Behalf Of Timothy Mcsweeney
Sent: Sunday, May 31, 2020 12:16 PM
To: Michael Wojcik <>om>;
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 < <> > wrote: 



From: Uri-review [mailto: <> ] On Behalf Of Timothy Mcsweeney 

Sent: Saturday, May 30, 2020 06:20 

To: Graham Klyne; <>  

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