From nobody Wed Nov 11 07:59:34 2020 Return-Path: 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 35AAD3A08B2 for ; Wed, 11 Nov 2020 07:59:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.794 X-Spam-Level: X-Spam-Status: No, score=-1.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, 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 Oj76J_roNceX for ; Wed, 11 Nov 2020 07:59:31 -0800 (PST) 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 C840F3A0420 for ; Wed, 11 Nov 2020 07:59:30 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MEGhK-1kWK1A459M-00FTDy; Wed, 11 Nov 2020 16:59:29 +0100 Date: Wed, 11 Nov 2020 10:59:28 -0500 (EST) From: Timothy Mcsweeney To: Larry Masinter , uri-review@ietf.org Message-ID: <901501952.9965.1605110368595@email.ionos.com> In-Reply-To: <1285517896.32083.1582823376975@email.ionos.com> References: <1404861506.56788.1582761910043@email.ionos.com> <01a901d5ed0f$02d8e980$088abc80$@acm.org> <1285517896.32083.1582823376975@email.ionos.com> 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.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:DJ2c6pS7kVUhYRgpeqKfenBWwZjmZEVUulbtiw+L0qkOB/67+50 3qKXi7tc0CRiU+UGteHHoL9Ysnp50gStbklgdjWjkWrtv84Gtk7cTMZw6d0haf+fixkKdp5 ZoA1sQM+pn2AB3PKlGDFUvdkDWIlckCJDowjBCdpdiL4igdzPm5IHSJqlxgHPVk4gGFsR0D 845o89gnjkjzAHxE46NQw== X-UI-Out-Filterresults: notjunk:1;V03:K0:jyMWsFkZ/oE=:C9UoE2Mxc5HZeevxuVEa9L 4/w6hD/Sh92nPvooX9oR86zRCelhS5YV5iag+JR5nGbiQDMCMeaHv8Ik1tadGOqw9Kg+obVwD sT8QpywpTZL85j9/b2bIMyaBFVeEe5TBA8ox74QbdFXzyAa91GfD7n6QbAk6nBOJJlN0c4CN5 67ZRspXxWXH4LGeAfOh1qa7iqkO7DaRtx5wEpWYkiS1xN/fVnHf7RbVEfCUO2a1asF6cREuHI /edbn+guFmJDuKubqKltL/ocNstyzORSOYd0UGPUoOZvbDOTZ/9+cvNBvUQEuQfxf4PGTMg9I rmJ1TBpe0/rRJiRz+fRGmKqz/Nl5p61RzMP3Byt95lwyV5EvCndgyZmOEXV8RxWerRe6mCyW9 c15/FVKv+WyiRWqUkfAGo1E6FnQ0KK4D4pjFNdRkLbvHWofnWwRiGeht8FEPYEhIFaOsj9gAd zNAk1ztzbw== Archived-At: Subject: Re: [Uri-review] URI resolution questions X-BeenThere: uri-review@ietf.org 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: Wed, 11 Nov 2020 15:59:32 -0000 =20 =20
Text version:
Hi Larry, 

If "example:123456" is my application unique string (RFC 3402 section 3= ) and the first well known rule is applied, the output being the key exampl= e.uri.arpa.  At this point what has happened to the "123456"?  &n= bsp;I am assuming that at this point nothing has happened to the "123456" b= ecause the DDDS application is now asking for rules to apply which are loca= ted in the NAPTR record at example.uri.arpa....is that correct? 


On 02/27/2020 12:09 PM Timothy Mcsweeney <tim@dropnumber.com> wro= te:


Hi Larry, 

If "example:123456" is my application unique string (RFC 3402 section 3= ) and the first well known rule is applied, the output being the key exampl= e.uri.arpa.  At this point what has happened to the "123456"?  &n= bsp;I am assuming that at this point nothing has happened to the "123456" b= ecause the DDDS application is now asking for rules to apply which are loca= ted in the NAPTR record at example.uri.arpa....is that correct? 
On February 26, 2020 at 8:41 PM Larry Masinter <LMM@acm.org> wrot= e:=20

Uh=E2= =80=A6 I can=E2=80=99t make sense of your question


<= /p>

From: Uri-review <uri-review-bounces@ietf.org> On Behalf Of Timothy Mcsweeney
Sent: Wednesda= y, February 26, 2020 4:05 PM
To: uri-review@ietf.orgSubject: [Uri-review] URI resolution questions


=

Hel= lo All,

It = was generously suggested that I may get some questions answered here about = URI resolution so here it goes:

If = I have a scheme name and a string like "example:123456" and the the string = will be used for further processing by a second NAPTR , would I want to use= the I2Rs mnemonic with a "p" flag in the first NAPTR? 

&nb= sp;And in this scenario, if the answer to the query of the second NAPTR is = terminal , does the answer go back to where the first query originated from= ?

Wha= t happens to the string during the resolution process?  

I h= ave been trying to set up a test environment for this but have not yet been= successful so any tips/tricks, or tools would be greatly appreciated.

Tim=


 
From nobody Wed Nov 11 08:00:15 2020 Return-Path: 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 B33523A0EAA for ; Wed, 11 Nov 2020 08:00:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.797 X-Spam-Level: X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 XvZ2mpyY5i-p for ; Wed, 11 Nov 2020 08:00:12 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (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 92B373A0E55 for ; Wed, 11 Nov 2020 08:00:12 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1N7AIq-1kDpkl3Dem-017W6i for ; Wed, 11 Nov 2020 17:00:11 +0100 Date: Wed, 11 Nov 2020 11:00:11 -0500 (EST) From: Timothy Mcsweeney To: uri-review@ietf.org Message-ID: <2085690714.10009.1605110411458@email.ionos.com> In-Reply-To: <293287663.426810.1585596955546@email.ionos.com> References: <293287663.426810.1585596955546@email.ionos.com> MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:L3fEmpSExnUUb8cquQiTbNgCG/Vqa8mamCR5o4N1NqZh26pxFXK 5wVLMoXQCpjkQfbWYnfij5Y2t8CJcJ+AKDVfezyk2YmCRYY6uDJ4d0J66ryop6tQwBWKw4e g1lEJSoTvhDbNYEoa4fahSFtlAF/yXt9+pLlnvFX3uifDiNhSdykYwJWe8sxC9ZTb0JJD/J jLOeXXo4cUTI5MI4GjDpQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:S0hIDzL9SvI=:qhahnxPr3Em3Os0u7JmVqD Xzkah7ymB2p8HQuCdThl2xv/zRulypAJdmU3AZeyRun4DWD0WZ16bPyxBoBjNk06z7aFuXcc1 v042kfg0agnMMWFJ5Dl/Omh2eAgG9nexmLiIq4DWSsaNK75tXpzAy4QOS9lxAneYliIJVsWyJ Hp+8ip7QINsp4V/Tw4efolW8b6kG2uBxKjDXC/n/awGwxYohK3BWFdIa8lV0cI0rv/gzugfpH vB97saiFLuV68dM/M4kJ70TYPynNj+bvP8L9/xDEot6EUGc+3l78FFEY2QZDG7GBI/btPksej D0nH3f4rPWvDszgKHpJ4F6Ega5kpSCHbSLuGEujOdpCgBwIARBtI5gBLQYYkqKXOCGS/zo4HX HfAodDD7GGFu1YGGaXV0HF/ePfO/ODrDWrwXhtb+LB6No4NHUusaWjIxvmiehy0c1VblsnsEg x5ERyQlYoA== Archived-At: Subject: Re: [Uri-review] posix X-BeenThere: uri-review@ietf.org 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: Wed, 11 Nov 2020 16:00:14 -0000
Text version:

Hi again, 
Does anyone have a copy of POSIX 1003.2 section 2.8?

Tim


On 03/30/2020 3:35 PM Timothy Mcsweeney <tim@dropnumber.com> wrote:


Hi again, 
Does anyone have a copy of POSIX 1003.2 section 2.8?

Tim
From nobody Wed Nov 11 08:01:48 2020 Return-Path: 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 D6E653A0DAB for ; Wed, 11 Nov 2020 08:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.797 X-Spam-Level: X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, 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 fVe28p_0ZQnv for ; Wed, 11 Nov 2020 08:01:44 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (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 8889F3A0C8E for ; Wed, 11 Nov 2020 08:01:44 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1MKc4m-1krF5X2Kw0-00L25B for ; Wed, 11 Nov 2020 17:01:43 +0100 Date: Wed, 11 Nov 2020 11:01:43 -0500 (EST) From: Timothy Mcsweeney To: uri-review@ietf.org Message-ID: <363316129.10091.1605110503263@email.ionos.com> In-Reply-To: <491516506.246380.1589851279474@email.ionos.com> References: <491516506.246380.1589851279474@email.ionos.com> MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:qDxeWjhntc/YbzED6Zj4v9LataWxN1iOz+p9mf6YYz1D4pc9d8M SWksW9Q+dIxO7APr61oleafwCktzEZCEIColp0qgA3keNF4QoTCXdazu/mCnR5G0m5hbEqp w3e4t1DCOpIDfW2TD/XnV4WNGN9U1+Xy0o7t2P1+bIUoLVciLJus67HrBglyIOqsdXlcQRc iuwXy+j3YluAFaf2UgYRA== X-UI-Out-Filterresults: notjunk:1;V03:K0:IrVizjQr1ks=:yPgsI2SRG0ik4Z5xMwKfO5 xzJqTgCuWLolrShqnC94V2Y8yNFjcNudjdjL8HaVcY5pPzHN3ELVFjCxZBtuiBYmIp7EGGE82 aCudAGyAQYiM2eHJZI2RI9IGLiaNwxkWPKrSOyvyV+RA/10QPb1gabRNC24f8v5AfHOz1N3nY FFdfAMhHYtfJUvdPJXQRe+LgkFX/6TmnIFY8H3iEsaw7mR65UNbab/cy+ldP2qOeow3gIF4s2 ICJ2zBMT36V3F8Ra4TmMj4Ws7vFL7YurixGFX6e1SvIs7ViFb9drWUrFH7XDrg+unsXObmXuo mEm51CT2wqS4p8xCa11Bcc+r7/BX9f+Q36hkZl9wyc7ASimOaIcibgnJh+q8ni6nsRYWsgtP3 6qvItVT6wwu1eYfRBRX+BM3wlT6oXQe0403kBt9BeQP5UL/Unx0PSpyIb2i0wJh+Apad5/skZ sVd6/3YzPQ== Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 16:01:46 -0000
text version:

Hello everyone, 

This is a request for a review of the 'drop' URI scheme.  The draft can be found here < https://datatracker.ietf.org/doc/draft-mcsweeney-drop-scheme/>.  Thank you. 
Sincerely, 
Tim McSweeney
On 05/18/2020 9:21 PM Timothy Mcsweeney <tim@dropnumber.com> wrote:


Hello everyone, 

This is a request for a review of the 'drop' URI scheme.  The draft can be found here < https://datatracker.ietf.org/doc/draft-mcsweeney-drop-scheme/>.  Thank you. 

Sincerely, 
Tim McSweeney
From nobody Wed Nov 11 08:03:28 2020 Return-Path: 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 0B2CB3A0DAB for ; Wed, 11 Nov 2020 08:03:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 yLB43mnFj-i4 for ; Wed, 11 Nov 2020 08:03:24 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (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 294503A0C8E for ; Wed, 11 Nov 2020 08:03:24 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MWD5b-1koGRu16l7-00XGzA for ; Wed, 11 Nov 2020 17:03:23 +0100 Date: Wed, 11 Nov 2020 11:03:22 -0500 (EST) From: Timothy Mcsweeney To: uri-review@ietf.org Message-ID: <1724424081.10216.1605110602967@email.ionos.com> In-Reply-To: <1516971670.87548.1589903220738@email.ionos.com> References: <491516506.246380.1589851279474@email.ionos.com> <1516971670.87548.1589903220738@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:Tsv+vqdQu0CNsP9EfcfiGAGED8b+soznidbS5hBnlhh4FVJaqO1 sNdNeWTPumttds/iFGaioRpOOOFNNS9/2rpSJBPfTNeMLx06d8sdcSLmnmNnwOn1xMJepKo kVtoSG9ovtajacjwFFCbCjA2h05P9028Uigmz1dYw32k2DsIL37pQO1Uvf6z3r2HLSFS/01 Q2OKvIUVbTlRI/m7rZxfA== X-UI-Out-Filterresults: notjunk:1;V03:K0:4Hf4bnkN5Ws=:uel1oWAXnlLNLLXEhaYDQS 8PwEzZinaE+oYBdUa60WuQ9iUOgh+In6UBX3G2Ql23a4x0U0GczesmRskpNnCOW4sOMo4wTH6 BJe5a+W2Vt3jtfQxVU5cKXymIXyApU9Kpj8iq+NR2/Gi6bhgcqfCWevd7YO2xuIlWixpVtQSt 1NkqtuwKOx2B91w/MU7i+eD4S4THgjXCXWejdQIxOl99roZQoGpzR7B50c0+Q21pa14dEMorJ x+OEjAy3kWBbmrkhxZMMwRNRrqFjQ/Cm7jZ2Gvhz0CSdAM1sxhCvHJsl/UivEdoW7DFj+3uiP kXPzSfKA21Hd6CBrz/PmhHggwKpU3DhWrYUcbyTjNRJtMElydjYW2TC84SpsL0Aak+IRQrk1h tYAZtQ2IVcIvL4hw163MddZNbXfAXYeKbPqgtYXdDJ81lxDpe3aBzkm15GI4qCy8uvHrgNULi CVDiGEMfKA== Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 16:03:26 -0000 text version: Hi Henry, I apologize for anything that was misleading as that was certainly not my intent. I will separate those two statements. The only similarity I wanted to point out was that 'tel' and 'leaptofrogans' use less than all five scheme components. Perhaps 'geo:' would have been a better example? For the syntax, I wasn't sure exactly how much info was needed. I thought that only the scheme and path were required. Maybe I could change the reference to [RFC3986] section 2.2? If you think it would be better, should I write it out more like this? path = / path-noscheme ; begins with a non-colon segment / path-rootless ; begins with a segment / path-empty ; zero characters path-noscheme = segment-nz-nc *( "/" segment ) path-rootless = segment-nz *( "/" segment ) path-empty = 0 segment = *pchar segment-nz = 1*pchar segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" ) ; non-zero-length segment without any colon ":" pchar = unreserved / pct-encoded / sub-delims / ":" / "@" Hi Martin, I know at first glance it might look out of place but the #fg34htx part isn't a fragment. I think the "drop" part will be recognized as the scheme name because of its dereferencing. > On 05/19/2020 11:47 AM Timothy Mcsweeney wrote: > > > Hi Henry, > I apologize for anything that was misleading as that was certainly not my intent. I will separate those two statements. The only similarity I wanted to point out was that 'tel' and 'leaptofrogans' use less than all five scheme components. Perhaps 'geo:' would have been a better example? > > For the syntax, I wasn't sure exactly how much info was needed. I thought that only the scheme and path were required. Maybe I could change the reference to [RFC3986] section 2.2? If you think it would be better, should I write it out more like this? > > path = / path-noscheme ; begins with a non-colon segment > / path-rootless ; begins with a segment > / path-empty ; zero characters > > path-noscheme = segment-nz-nc *( "/" segment ) > path-rootless = segment-nz *( "/" segment ) > path-empty = 0 > > segment = *pchar > segment-nz = 1*pchar > segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" ) > ; non-zero-length segment without any colon ":" > > pchar = unreserved / pct-encoded / sub-delims / ":" / "@" > > > Hi Martin, > I know at first glance it might look out of place but the #fg34htx part isn't a fragment. I think the "drop" part will be recognized as the scheme name because of its dereferencing. > > > > On May 19, 2020 at 5:40 AM "Henry S. Thompson" < ht@inf.ed.ac.uk> wrote: > > > > > > Timothy Mcsweeney writes: > > > > > This is a request for a review of the 'drop' URI scheme. The > > > draft can be found here > > > https://datatracker.ietf.org/doc/draft-mcsweeney-drop-scheme/ > > Without commenting on any other aspect of the proposed scheme, and > > mostly just to save people time, I found the following aspect of the > > proposal somewhat misleading: > > > > "Similar to the previously registered 'tel' [RFC3966] and > > 'leaptofrogans' [RFC8589] URIs, the 'drop' URI scheme is > > syntactically correct but does not need to use all 5 of the > > parse-able components available to it. The 'drop' scheme uses the > > number sign '#' as a general delimiter as seen in Appendix > > A. Collected ABNF [RFC3986]. The scheme syntax is as follows: > > > > " drop-uri = 'drop#' character string > > > > drop # fg34htx > > \__/ \_/ \_____/ > > | | | > > | > > > > " > > > > I read this as implying that > > > > 1) 'tel' and 'leaptofrogans' URIs did not begin "tel:" and > > "leaptofrogans:"; > > 2) The 3986 ABNF for URIs recognises "drop#fg34htx" as a URI. > > > > Neither of these is in fact that case. The two referenced schemes > > require ':' after the 'scheme' component, and the 'URI' production does > > _not_ recognise the above example. (The 'URI-reference' production does, > > but not using the 'scheme' production to cover the "drop" part.) > > > > ht > > -- > > Henry S. Thompson, School of Informatics, University of Edinburgh > > 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 > > Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk > > URL: http://www.ltg.ed.ac.uk/~ht/ > > [mail from me _always_ has a .sig like this -- mail without it is forged spam] > > > > The University of Edinburgh is a charitable body, registered in > > Scotland, with registration number SC005336. > > > > _______________________________________________ > > Uri-review mailing list > > Uri-review@ietf.org > > https://www.ietf.org/mailman/listinfo/uri-review From nobody Wed Nov 11 08:05:27 2020 Return-Path: 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 03F733A0E55 for ; Wed, 11 Nov 2020 08:05:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 bRrwpXf811S5 for ; Wed, 11 Nov 2020 08:05:24 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (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 A06AD3A126C for ; Wed, 11 Nov 2020 08:04:32 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1M58Wm-1kbmg738zs-0019SJ for ; Wed, 11 Nov 2020 17:04:31 +0100 Date: Wed, 11 Nov 2020 11:04:31 -0500 (EST) From: Timothy Mcsweeney To: uri-review@ietf.org Message-ID: <1147014279.10279.1605110671455@email.ionos.com> In-Reply-To: <122709156.27676.1590010716156@email.ionos.com> References: <491516506.246380.1589851279474@email.ionos.com> <1516971670.87548.1589903220738@email.ionos.com> <122709156.27676.1590010716156@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:XoIC8WpO5d1X+Jkra6F566FwbS25E/N1q0bdMymVnU/QVkFD6zu k9eyh5SJupKx4x6nPVQuUiIe98dOokrwp2hbG3VYyIrxctunJK77r9iPO+uoOqTbifnNrYB oRKwSKsle14jee0kMkics4DQ0kfbWH6ds+4BtXJ4XE34sSVU4aDNQjjAg3BzGQe3G8fUJGW IMlmpFOAUGR/xPlJ3TNsA== X-UI-Out-Filterresults: notjunk:1;V03:K0:dwfcjngb0zk=:SAdB/9jRf1EhdSveEyYcDS bVx7jvu1KNjVhWbQ0/Olu7l86XEIx3pf7YbKRkS21FEj2i1czZtRgFfp6WAtybjp+Zrgz1FXx Bf7MpSKn6RJ0tIzNwwtAVCnl+DMOZ6fsVuE75vWLmsRHAWKOR+KLl7P2vK5pEhIfTXnTFetrK SkPwWTo023UnJAfmT+GBJnzxrj9xpKWygx8UcHwrECqdC7HKruqQMPKkMpIJ7A2foxBBgHbFm 3Xn9Psw6iCqOgifxxwMgTa1dJBSFceUbgBMgCuDD7nWV8Zl2Hf9WpQaGEdykLinJDRjFFAE/S JyzkhP4raCZnGXhuTHVrxRpb09hxTmJDipxTsGxwAa/WbB8a74XzY9v86Eu55GPt7C7Xc3DZr qCXn90kb5Oe1hTlr/npazImN8kPLuPzIrPuMY6XoJkvNjAdbnRYhgqI69L+HWcIZHrmY76OR7 zY462/8BZQ== Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 16:05:26 -0000 text version: Hi Martin, I followed your instructions and I could not recreate what you wanted me to= see. Here are the two pages I made: Perhaps it had something to do with the hosting provider?? I'm not sure wh= at's wrong here. =20 Anyways, I'm glad to be here doing this. Being an outsider, I was very ner= vous about a review on this proposed scheme because everyone on this mailin= g list is 1000X more knowledgeable than me. I thought for sure that this r= eview process was going to be a good way for the IETF crowd to blast my ign= orance and be rid of me for a long while. Just getting past the nits checker was a bit of a challenge for me. But I = have come to realize the real value in airing things out early is the advan= tage of perspective. I suspected I already knew the outcome of your experi= ment, but not wanting to discount other ideas too quickly is something I co= uld use more practice with. And I'm glad I tried it. Seeing things with a= more open mind helped me find an error in this first draft that I haven't = been called out on yet! (will be fixing that in draft-01). So I am already= grateful. Maybe we could do a different experiment? Maybe you know of a way for me t= o try out my dereferencing and test the "#" as a delimiter? Sincerely,=20 Tim > On 05/20/2020 5:38 PM Timothy Mcsweeney wrote: >=20 >=20 > Hi Martin, >=20 > I followed your instructions and I could not recreate what you wanted me = to see. > Here are the two pages I made: >=20 > > >=20 > Perhaps it had something to do with the hosting provider?? I'm not sure w= hat's wrong here. >=20 > Anyways, I'm glad to be here doing this. Being an outsider, I was very ne= rvous about a review on this proposed scheme because everyone on this maili= ng list is 1000X more knowledgeable than me. I thought for sure that this r= eview process was going to be a good way for the IETF crowd to blast my ign= orance and be rid of me for a long while. >=20 > Just getting past the nits checker was a bit of a challenge for me. But I= have come to realize the real value in airing things out early is the adva= ntage of perspective. I suspected I already knew the outcome of your experi= ment, but not wanting to discount other ideas too quickly=C2=A0is something= I could use more practice with. And I'm glad I tried it. Seeing things wit= h a more open mind helped me find an error in this first draft that I haven= 't been called out on yet! (will be fixing that in draft-01). So I am alrea= dy grateful. >=20 > Maybe we could do a different experiment? Maybe you know of a way for me = to try out my dereferencing and test the "#" as a delimiter? >=20 > Sincerely, > Tim >=20 >=20 >=20 > > On May 20, 2020 at 2:25 AM "Martin J. D=C3=BCrst" < duerst@it.aoyama.ac= .jp> wrote: > >=20 > >=20 > > Hello Timothy, > >=20 > > On 20/05/2020 00:47, Timothy Mcsweeney wrote: > > > Hi Henry, > > > I apologize for anything that was misleading as that was certainly no= t my > > > intent. I will separate those two statements. The only similarity I w= anted to > > > point out was that 'tel' and 'leaptofrogans' use less than all five s= cheme > > > components. Perhaps 'geo:' would have been a better example? > > >=20 > > > For the syntax, I wasn't sure exactly how much info was needed. I tho= ught that > > > only the scheme and path were required. Maybe I could change the refe= rence to > > > [RFC3986] section 2.2? If you think it would be better, should I writ= e it out > > > more like this? > > In the extreme, only the scheme is needed. "dav:" is an example. But > > without a colon, it's not a scheme. > >=20 > > > path =3D / path-noscheme ; begins with a non-colon segment > > > / path-rootless ; begins with a segment > > > / path-empty ; zero characters > > >=20 > > > path-noscheme =3D segment-nz-nc *( "/" segment ) > > > path-rootless =3D segment-nz *( "/" segment ) > > > path-empty =3D 0 > > >=20 > > > segment =3D *pchar > > > segment-nz =3D 1*pchar > > > segment-nz-nc =3D 1*( unreserved / pct-encoded / sub-delims / "@" ) > > > ; non-zero-length segment without any colon ":" > > >=20 > > > pchar =3D unreserved / pct-encoded / sub-delims / ":" / "@" > > I'm not sure what these parts of the grammar are supposed to do here, > > but you can't just start in the middle of the grammar and claim that yo= u > > get an URI. > >=20 > >=20 > > > Hi Martin, > > > I know at first glance it might look out of place but the #fg34htx pa= rt isn't a > > > fragment. > > By the definitions of RFC 3986, it is a fragment (identifier). This is > > independent of what you want to call it. > >=20 > > > I think the "drop" part will be recognized as the scheme name because > > > of its dereferencing. > > Please do the following, as an easy experiment: > >=20 > > - Create a simple Web page somewhere, e.g. called base.html, > > and in it, include the following part: > > Link to drop URI > > - In the same directory, create another Web page, with the file name > > simply being 'drop' (without extension). Way down in that Web page, > > include the following: > > Fragment fg34htx > > - Activate the link in the first page, and observe how it goes to the > > fragment in the second page. > > [If you set up the pages on the server, you may have to take some care > > that the 'drop' file is really served with an HTML media type; this may > > be a bit tricky.] > >=20 > > If my explanations don't help, maybe doing this experiment will show yo= u > > what I mean. > >=20 > > Regards, Martin. > >=20 > > P.S.: The solution is simple. If you change "drop#fg34htx" to > > "drop:fg34htx", then you actually match the URI production and no longe= r > > have a fragment id. > >=20 > > >> On May 19, 2020 at 5:40 AM "Henry S. Thompson" < ht@inf.ed.ac.uk > > >> > wrote: > > >> > > >> > > >> Timothy Mcsweeney writes: > > >> > > >>> This is a request for a review of the 'drop' URI scheme. The > > >>> draft can be found here > > >>> https://datatracker.ietf.org/doc/draft-mcsweeney-drop-scheme/ > > >> Without commenting on any other aspect of the proposed scheme, and > > >> mostly just to save people time, I found the following aspect of the > > >> proposal somewhat misleading: > > >> > > >> "Similar to the previously registered 'tel' [RFC3966] and > > >> 'leaptofrogans' [RFC8589] URIs, the 'drop' URI scheme is > > >> syntactically correct but does not need to use all 5 of the > > >> parse-able components available to it. The 'drop' scheme uses the > > >> number sign '#' as a general delimiter as seen in Appendix > > >> A. Collected ABNF [RFC3986]. The scheme syntax is as follows: > > >> > > >> " drop-uri =3D 'drop#' character string > > >> > > >> drop # fg34htx > > >> \__/ \_/ \_____/ > > >> | | | > > >> | > > >> > > >> " > > >> > > >> I read this as implying that > > >> > > >> 1) 'tel' and 'leaptofrogans' URIs did not begin "tel:" and > > >> "leaptofrogans:"; > > >> 2) The 3986 ABNF for URIs recognises "drop#fg34htx" as a URI. > > >> > > >> Neither of these is in fact that case. The two referenced schemes > > >> require ':' after the 'scheme' component, and the 'URI' production d= oes > > >> _not_ recognise the above example. (The 'URI-reference' production d= oes, > > >> but not using the 'scheme' production to cover the "drop" part.) > > >> > > >> ht > > >> -- > > >> Henry S. Thompson, School of Informatics, University of Edinburgh > > >> 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 > > >> Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk > > >> URL: http://www.ltg.ed.ac.uk/~ht/ > > >> [mail from me _always_ has a .sig like this -- mail without it is fo= rged spam] > > >> > > >> The University of Edinburgh is a charitable body, registered in > > >> Scotland, with registration number SC005336. > > >> > > >> _______________________________________________ > > >> Uri-review mailing list > > >> Uri-review@ietf.org > > >> https://www.ietf.org/mailman/listinfo/uri-review > > >=20 > > > _______________________________________________ > > > Uri-review mailing list > > > Uri-review@ietf.org > > > https://www.ietf.org/mailman/listinfo/uri-review > > >=20 > > -- > > Prof. Dr.sc. Martin J. D=C3=BCrst > > Department of Intelligent Information Technology > > College of Science and Engineering > > Aoyama Gakuin University > > Fuchinobe 5-1-10, Chuo-ku, Sagamihara > > 252-5258 Japan From nobody Wed Nov 11 08:05:46 2020 Return-Path: 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 0E0CD3A0C8E for ; Wed, 11 Nov 2020 08:05:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 nVTCJPyeVpq1 for ; Wed, 11 Nov 2020 08:05:43 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (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 EB0CE3A0E19 for ; Wed, 11 Nov 2020 08:05:06 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1N6tSF-1kEekv0YEJ-018L5e for ; Wed, 11 Nov 2020 17:05:06 +0100 Date: Wed, 11 Nov 2020 11:05:05 -0500 (EST) From: Timothy Mcsweeney To: uri-review@ietf.org Message-ID: <1546307172.10307.1605110705834@email.ionos.com> In-Reply-To: <1888561123.43509.1590034134659@email.ionos.com> References: <491516506.246380.1589851279474@email.ionos.com>, , <122709156.27676.1590010716156@email.ionos.com> <5EC5F6A9.7599.23B3E5E7@dan.tobias.name> <1888561123.43509.1590034134659@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:8HgUjirGVkBIfkcvK/ji1JeoShTx0tDgQWDyXpz/5k8x+W9nwnf qSX1MrBelrF0PoMihBNprlIJdo3na8GY0Wgy9UhI2uwN5DSmTqIkbed7vDFIeCC0d6Q53Mv dgNR3KBJzNBYUqavNTEN3W1qbSoWSE2tK1u07FcLKzx6Hmg800WMuCXQqBI/7yyURMSHWO/ 6M+ibUvTupmM3Ct6udr0A== X-UI-Out-Filterresults: notjunk:1;V03:K0:VRInmrnkR74=:igALDJPf3CXEGnCtlUzYET W56hm99paJW8PG8jm+MgEtKQbx0GCSg4FL0kzf320TwbZsgCirTq57MNaFKXyMgaBZ73XOUMv D+55RXchOwR70ByzaRkCW76bic3VYaT3aR/0vbXTXndtsHVCmji6GpwapmxKHpmzn0u94IgTL ZUhckOzT3kaPL3Co7lTpSdjiOta5C4jyKhWLv0px2Zpq8q/BD3TE/UyVgYxoIUpzmql0taRKf dYHoxFXhfIH84KyOtmtnl2KMN732HPOqMz/KCmSu9dJ8Ip4D00YFED44TcOKMMAADPPSDTmLf rRuweY/noff7WmoSs3BF97q3ZLB33q95DyBkm5ocJAl7+o58f6V5qKZlDKaLp2Ixys/bpPW7t +gAVG8//xRJLTZWpQJ7SDjzp39qGBWFEFwP+8MQIiuYqZF5C5WhFoov4EXoS1XABrNW4yq2op UtwCVfAk0A== Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 16:05:45 -0000 text version: hmm, it looks like my email client made it into a link. I fixed it and it works perfectly! Thank you Daniel. > On 05/21/2020 12:08 AM Timothy Mcsweeney wrote: > > > hmm, it looks like my email client made it into a link. I fixed it and it works perfectly! Thank you Daniel. > > On May 20, 2020 at 11:34 PM "Daniel R. Tobias" < dan@tobias.name> wrote: > > > > > > On 20 May 2020 at 17:38, Timothy Mcsweeney wrote: > > > > > I followed your instructions and I could not recreate what you wanted > > > me to see. Here are the two pages I made: > > > < http://www.soupsdeli.com/base.html> > > > < http://www.soupsdeli.com/drop> > > > Perhaps it had something to do with the hosting provider?? I'm not > > > sure what's wrong here. > > This is the content of your first page: > > > > > > > > > > test link > > > > > > > > > > > > > > > > > > As you can see, the "href" value doesn't have "drop#fg34htx" by > > itself as requested; it has a " http://" (http://) before it. This transforms it > > into a http URI with "drop" as its domain, which my browser > > "helpfully" converts into a link to drop.com. It would presumably > > then go to the fragment #fg34htx in that page if such a fragment > > existed. > > > > -- > > == Dan == > > Dan's Mail Format Site: http://mailformat.dan.info/ > > Dan's Web Tips: http://webtips.dan.info/ > > Dan's Domain Site: http://domains.dan.info/ > > From nobody Wed Nov 11 08:06:19 2020 Return-Path: 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 29A963A0C8E for ; Wed, 11 Nov 2020 08:06:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.875 X-Spam-Level: X-Spam-Status: No, score=-0.875 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, 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 HT7BNAniGtNB for ; Wed, 11 Nov 2020 08:06:17 -0800 (PST) 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 C53C33A101E for ; Wed, 11 Nov 2020 08:06:02 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1M8gu5-1khZSy3zPd-004i9C for ; Wed, 11 Nov 2020 17:06:02 +0100 Date: Wed, 11 Nov 2020 11:06:01 -0500 (EST) From: Timothy Mcsweeney Cc: uri-review@ietf.org Message-ID: <1545345914.10373.1605110761654@email.ionos.com> In-Reply-To: <624184630.116213.1590182968873@email.ionos.com> References: <491516506.246380.1589851279474@email.ionos.com>, , <122709156.27676.1590010716156@email.ionos.com> <5EC5F6A9.7599.23B3E5E7@dan.tobias.name> <624184630.116213.1590182968873@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:Fa7BNr7l/CmRtHD/isjz4JZA4k+dBVk6AAYGCjuYFRpYtuD9bD5 yhRbVmeizauHHAcWW19jhqPMqX7NynLVHPJFkHXzDP2T01c8gH+J9oou/u3Ja4+C27Oi7ZH j3W7PMjYzRN54uUC0OPYpDGoiRi/DQtBweyXZC4TFoUbWSl3Dj4pKhQ6xPR8VMrqOdJEhf+ hdn9g62vuIAIzUDDiDksg== X-UI-Out-Filterresults: notjunk:1;V03:K0:Ut7fviLqNhs=:BmvHHVZXVXrMJukzJYLCB7 gtTYAhE3OI5Yaw53ryWEp+pVDC1l71SGxVXewPaBccj9eAnlmOnDMV8YNyrIvdo55rwnocDFa GzCr10XUpzXyEWpQYRwrYVOM9rDnX5y+jOKmKZH2S85CbD1tIvBmEMdOsrD3J0N02E/adY8iY UzmidLuAPgeMXsQwL3ius3byQkuLYnfDyIQFLkaYMXyGhsovPPMoXV9+KhVnr0qUO4sqsyM1c 1XvGGVEYomP6fZoIZ54fHctC+EK+g+dXj9SDdgkS0vtoMtuv31r9a7TFoFWhb2kQgKm34L9dQ Ph3WCkA8HCFMSZA7tifWpN13K+lKxmnTSWl4qAz9kt2/Q3WYR49JzE9zoxckI2XKOFRhKBlA4 mJ9UGf+hb7oAy7dzhz3PzV+kXrH2j0/pfAAWGW9qgPAVm+nIfkQsrDL+DUyzFxG1EjqPFHs0q v/yTwahTBw== Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 16:06:18 -0000 text version: Hello everyone, The second draft of the 'drop' URI scheme is available and can be found here < https://datatracker.ietf.org/doc/draft-mcsweeney-drop-scheme/>. Thank you. Sincerely, Tim McSweeney > On 05/22/2020 5:29 PM Timothy Mcsweeney wrote: > > > Hello everyone, > > The second draft of the 'drop' URI scheme is available and can be found here < https://datatracker.ietf.org/doc/draft-mcsweeney-drop-scheme/>. Thank you. > > > Sincerely, > Tim McSweeney > > On May 20, 2020 at 11:34 PM "Daniel R. Tobias" < dan@tobias.name> wrote: > > > > > > On 20 May 2020 at 17:38, Timothy Mcsweeney wrote: > > > > > I followed your instructions and I could not recreate what you wanted > > > me to see. Here are the two pages I made: > > > < http://www.soupsdeli.com/base.html> > > > < http://www.soupsdeli.com/drop> > > > Perhaps it had something to do with the hosting provider?? I'm not > > > sure what's wrong here. > > This is the content of your first page: > > > > > > > > > > test link > > > > > > > > > > > > > > > > > > As you can see, the "href" value doesn't have "drop#fg34htx" by > > itself as requested; it has a " http://" (http://) before it. This transforms it > > into a http URI with "drop" as its domain, which my browser > > "helpfully" converts into a link to drop.com. It would presumably > > then go to the fragment #fg34htx in that page if such a fragment > > existed. > > > > -- > > == Dan == > > Dan's Mail Format Site: http://mailformat.dan.info/ > > Dan's Web Tips: http://webtips.dan.info/ > > Dan's Domain Site: http://domains.dan.info/ > > From nobody Wed Nov 11 08:06:41 2020 Return-Path: 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 EA2CE3A0E19 for ; Wed, 11 Nov 2020 08:06:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 pf8QMsd74tB5 for ; Wed, 11 Nov 2020 08:06:38 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (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 70C703A0DFB for ; Wed, 11 Nov 2020 08:06:38 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus002 [74.208.5.2]) with ESMTPSA (Nemesis) id 0Lp4sc-1k78KP2cGi-00etZg for ; Wed, 11 Nov 2020 17:06:37 +0100 Date: Wed, 11 Nov 2020 11:06:37 -0500 (EST) From: Timothy Mcsweeney To: uri-review@ietf.org Message-ID: <2064428371.10403.1605110797334@email.ionos.com> In-Reply-To: <811217250.273727.1590291463007@email.ionos.com> References: <491516506.246380.1589851279474@email.ionos.com>, <5EC5F6A9.7599.23B3E5E7@dan.tobias.name>, <624184630.116213.1590182968873@email.ionos.com> <5EC9B257.31362.CC5E003@dan.tobias.name> <811217250.273727.1590291463007@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:xPdUL7rI5PX4Lij0GEozOxPq3I6lunTH0LzWtr9R7NqlKHnul9M /RiPbsVvwOSGJPgvThwd+NUKdCCtblsT70axa7s6Cgtqo1SqM/313KGKggv4Jc0HOVvsIrL wOhEOzKpgFj/un1Iyd4mB7YEY6AyS056lejMOHbbEFxGjZGSLhYR75Wxzsz0FjiR1aC24Ft dr1utcAiTspow8G1szKYA== X-UI-Out-Filterresults: notjunk:1;V03:K0:aVOdp4JimVE=:Ba4FSj6leAtvUIc9yFhBOf QAVhv2iCfxfRrhHLn8fcWF47xgb0c+JrG8BNh7RT0TKUb1tcPcwywj+usYApoAy/tbJeCkOz3 8b5hpJgkNDm1BhxYwniGZxCTYYI8xUQmHE0P170IQUR3zYmUgzlZ4dnE+emQ7+CX3Q8Fs28lZ EOm+7a9VA/fA62MHQUx8l25BjLKFv4KlB7fc2mHTwlBhRehLcspyyAEuA8bSD/84aTOMcBnG0 Q10qU8Qevnc7hGFF/Lttl/noK9LQ4kAoMtbPDUCLKn7e330JDXOYHRz3Cj8cyVX1drbtbFMGN vnsy7Pglczo0SJmjtnjlKL2MS81Kq5p15+JJ8b8KByybwhMEMXWG2FYOLCzNqnnTuOr+5WHBW T20ydduM0j+vj4A8fhohUI8hyoUIZDmqt09bv9Coip5iJj6j0OiMb+h5x76YNvJNU5ktmDkAw ew60kppyug== Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 16:06:40 -0000 Hi Daniel, I think I know what you're saying but I want to make sure so, when you say 'mandatory colon' do you mean for all URIs or for just http? Tim > On 05/23/2020 11:37 PM Timothy Mcsweeney wrote: > > > Hi Daniel, > > I think I know what you're saying but I want to make sure so, when you say 'mandatory colon' do you mean for all URIs or for just http? > > Tim > > On May 23, 2020 at 7:31 PM "Daniel R. Tobias" < dan@tobias.name> wrote: > > > > > > On 22 May 2020 at 17:29, Timothy Mcsweeney wrote: > > > > > The second draft of the 'drop' URI scheme is available and can be > > > found here < > > > " rel="noopener" target="_blank" data-mce-href="https://datatracker.ietf.org/doc/draft-mcsweeney-drop-scheme/>">https://datatracker.ietf.org/doc/draft-mcsweeney-drop-scheme/> (https://datatracker.ietf.org/doc/draft-mcsweeney-drop-scheme/). Thank > > > you. > > This doesn't seem to resolve any of the issues people have raised; it > > still omits the mandatory colon after the scheme, and puts its main > > content, used for resource resolution and retrieval, in a fragment > > identifier, which is intended for client-specific post-processing > > after a document is retrieved. > > > > -- > > == Dan == > > Dan's Mail Format Site: http://mailformat.dan.info/ > > Dan's Web Tips: http://webtips.dan.info/ > > Dan's Domain Site: http://domains.dan.info/ > > > > > > _______________________________________________ > > Uri-review mailing list > > Uri-review@ietf.org > > https://www.ietf.org/mailman/listinfo/uri-review From nobody Wed Nov 11 08:07:26 2020 Return-Path: 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 8CDDA3A0C8E for ; Wed, 11 Nov 2020 08:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 yOmCX0bwuXzy for ; Wed, 11 Nov 2020 08:07:23 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (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 A00C23A098D for ; Wed, 11 Nov 2020 08:07:23 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1MuE0f-1kIS5X3OZB-00udtn for ; Wed, 11 Nov 2020 17:07:22 +0100 Date: Wed, 11 Nov 2020 11:07:22 -0500 (EST) From: Timothy Mcsweeney To: uri-review@ietf.org Message-ID: <984492400.10438.1605110842505@email.ionos.com> In-Reply-To: <1783049000.100771.1590323508943@email.ionos.com> References: <491516506.246380.1589851279474@email.ionos.com>, <5EC5F6A9.7599.23B3E5E7@dan.tobias.name>, <624184630.116213.1590182968873@email.ionos.com> <5EC9B257.31362.CC5E003@dan.tobias.name> <1783049000.100771.1590323508943@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:kmpNbxHoAzsiaKJJL1Kq+Yk2GMqdKY5mdhe31dnmjTnr7PNWitP NuTeaaS6m1ELAkq7EJ8uozxzTw3dECAXDGOtGRm21xSLgZwukR3Gec4Iz7HMlnoHVGC32iy U95NBEM/hsCTQ2bViOS7q1AdiiL9oT97prQtx1GxWbjQA1YSTYwNeGtdzmCk3YTbKkV7s3S Z0J4pN46n6hFoqyY7HtLg== X-UI-Out-Filterresults: notjunk:1;V03:K0:NjBq3SVCKuU=:cNcVlggkU3mAlid0uXzQ23 Kyq3JAkVuIGkIe+Rko53l2nSGEmfdhvrCqOTIYp9MlMpV6r9fuSrWY/tUys8DcClw21QfYBap ah2KSa1x8F974ZqJvKHGzvEU71u997vgrkNPYtHTZYFlcmuGxzAkX6vFzBqkDyPTrtItcVwxP gBh8s2an+msXYH8iLfyNt8lM5eJQNQQlXENMo1aX9oxC8KCNEMPv25vcFWTwAJgO2Hoci37Hw 3iV9c/PRu2ma6j6KSeqvu4/7c/5KLMyHIaT7iVMHo9wt7Xb6zHPNYElXy6GoaELOlHzt61p3X F+IHSCBh7YUf8J6WnBkT89z120PR997YvZVjLCN1+YlzxqY04ug2+lrnj9MGAeXl1OGnFLkgr E8QGIXkMIHoNQvwVzlOo6Fv6hVVPJWHIv7VJoIMSR0UGc5jbLoyIKTsJa7OIb4lvhug+8mFOw UfZnFd7s4w== Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 16:07:25 -0000 text version: Hi Dan, For the browser example, it is going to leave the client as 'drop#fg234' but come back to the client as 'fg234.dropexample.com'. Looking at the second sentence of section 2.2 of rfc3986 it give three choices for defining delimiters: by using general syntax by each scheme-specific syntax by the implementation-specific syntax of a URI's derefrencing algorithm. The 'drop' scheme uses the last one. I was thinking of a way to show this being done with http but didn't thing anyone really wanted to see that. Tim > On 05/24/2020 8:31 AM Timothy Mcsweeney wrote: > > > Hi Dan, > > For the browser example, it is going to leave the client as 'drop#fg234' but come back to the client as 'fg234.dropexample.com'. > > Looking at the second sentence of section 2.2 of rfc3986 it give three choices for defining delimiters: > by using general syntax > by each scheme-specific syntax > by the implementation-specific syntax of a URI's derefrencing algorithm. > > The 'drop' scheme uses the last one. I was thinking of a way to show this being done with http but didn't thing anyone really wanted to see that. > > Tim > > > On May 23, 2020 at 7:31 PM "Daniel R. Tobias" < dan@tobias.name> wrote: > > > > > > On 22 May 2020 at 17:29, Timothy Mcsweeney wrote: > > > > > The second draft of the 'drop' URI scheme is available and can be > > > found here < > > > " rel="noopener" target="_blank" data-mce-href="https://datatracker.ietf.org/doc/draft-mcsweeney-drop-scheme/>">https://datatracker.ietf.org/doc/draft-mcsweeney-drop-scheme/> (https://datatracker.ietf.org/doc/draft-mcsweeney-drop-scheme/). Thank > > > you. > > This doesn't seem to resolve any of the issues people have raised; it > > still omits the mandatory colon after the scheme, and puts its main > > content, used for resource resolution and retrieval, in a fragment > > identifier, which is intended for client-specific post-processing > > after a document is retrieved. > > > > -- > > == Dan == > > Dan's Mail Format Site: http://mailformat.dan.info/ > > Dan's Web Tips: http://webtips.dan.info/ > > Dan's Domain Site: http://domains.dan.info/ > > > > > > _______________________________________________ > > Uri-review mailing list > > Uri-review@ietf.org > > https://www.ietf.org/mailman/listinfo/uri-review From nobody Wed Nov 11 08:08:24 2020 Return-Path: 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 B96A03A0E92 for ; Wed, 11 Nov 2020 08:08:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 8SQkJ1gcVkiV for ; Wed, 11 Nov 2020 08:08:22 -0800 (PST) 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 4CA733A0E55 for ; Wed, 11 Nov 2020 08:08:22 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MDiSu-1kVlut1kIo-00H7cO for ; Wed, 11 Nov 2020 17:08:21 +0100 Date: Wed, 11 Nov 2020 11:08:21 -0500 (EST) From: Timothy Mcsweeney To: uri-review@ietf.org Message-ID: <1150746508.10489.1605110901134@email.ionos.com> In-Reply-To: <1426881880.158099.1590335585858@email.ionos.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:0sJv8HlxRM5uqrKDvyjAHAdf6t2FLHFczGw7pt8+bCIk5X3bbFT suKnWSMnNObyKNCKxzo39AHAnyMG9GGLbIbHfR8554W33r6jCF3hY9ucUjByf1rmKy1cpYV DZpZWxL7Dvr/A2MAbzJ5JgLpImeGaN3gzcYcXGNKw7BQdGwzfaPkKuMlip9iz8/UrBezUu1 PpGIOSUM6T/S7GW56OGKw== X-UI-Out-Filterresults: notjunk:1;V03:K0:6AECu4V0Y/E=:SXHSDGuyWLSSq2+HoCqHQR 6R13VEVcALNzjEvjnCR1Sgh8Q8MLdwYncGWGm/ajYOm83+1sfGGllmB24VDnC2o0Z45bbKgji Gz4/zJqjNHds/T4o23pxQ6a9NhZT5PxI0JY53wuRWHpaP2La+NlvvdvaBvDHFpdh3Izk1ICuo /JMek7z4nW13nc9MmjIFLA+pNRsM4BHbGhVpWeV1zZDn2xbu4epe70Ei/kmaMnMMOQyhe9EGz tJysJ7ONYM2f6f64qatqcle7SK0zx8Mt2MzRphPclhmWv4qGWSxNY1R96BmEDwwhL/dsqTf5v RsPLf7KLSgxYVHr3VY9aTVn+CudarnlVqsfcAuO5d+UULa7sy99FAMC4+gg1sM5ASxQlO1A9g 0Ec0xfYTDj4L7t9dPbXpVa/0dnfPIwk6Wxd6kVaLRHKr0/G8/WTcU/f1zXESpFKNRD19uSbwj t+bv31PfrA== Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 16:08:24 -0000 text version: Hi Dan, Yes, I agree and understand that the same way as you. But when the "#" leaves the client it is not leaving as a fragment, it is leaving as a way to separate the URI components, and or for http it would be separating and . It is this that makes me believe that even if the colon is required for http resolution, it is not necessarily required for all URI. Tim > On 05/24/2020 11:53 AM Timothy Mcsweeney wrote: > > > Hi Dan, > > Yes, I agree and understand that the same way as you. But when the "#" leaves the client it is not leaving as a fragment, it is leaving as a way to separate the URI components, and or for http it would be separating and . It is this that makes me believe that even if the colon is required for http resolution, it is not necessarily required for all URI. > > Tim > > > > On May 24, 2020 at 10:54 AM "Daniel R. Tobias" < dan@tobias.name> wrote: > > > > > > On 24 May 2020 at 8:31, Timothy Mcsweeney wrote: > > > > > For the browser example, it is going to leave the client as > > > 'drop#fg234' but come back to the client as 'fg234.dropexample.com'. > > As I understand it, fragment identifiers don't leave the client, but > > are used when processing the returned data from the server at the > > client side. > > > > -- > > == Dan == > > Dan's Mail Format Site: http://mailformat.dan.info/ > > Dan's Web Tips: http://webtips.dan.info/ > > Dan's Domain Site: http://domains.dan.info/ > > > > > > _______________________________________________ > > Uri-review mailing list > > Uri-review@ietf.org > > https://www.ietf.org/mailman/listinfo/uri-review From nobody Wed Nov 11 08:10:04 2020 Return-Path: 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 646683A010D for ; Wed, 11 Nov 2020 08:10:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 2hGWkYCoOWih for ; Wed, 11 Nov 2020 08:10:00 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (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 9CB473A00E5 for ; Wed, 11 Nov 2020 08:10:00 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MBEIN-1kTHtQ18Cb-00AGj8; Wed, 11 Nov 2020 17:09:17 +0100 Date: Wed, 11 Nov 2020 11:09:16 -0500 (EST) From: Timothy Mcsweeney To: Erik Wilde , uri-review@ietf.org Message-ID: <2137182463.10540.1605110956846@email.ionos.com> In-Reply-To: <1310141163.159340.1590344745080@email.ionos.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:+0UjCils4IKvx6TFZSKj9rcylih/hJZY0X7uZUNaaE31cFIV9l7 J1g4X0C/qD8hcSONjdBNpsKAIwhpu0KnwEZncttt04QQrbpJXhheOqn1KohVj1aWmJ5lMqa aCG9cVMwSpN5R6DlkaFnPRxWt/lCB24bXVsXB2NRDtA7I+fc0JR+qOcMOb04yme+k1N4QKH 8rR/EpKvelGptAzQbpVug== X-UI-Out-Filterresults: notjunk:1;V03:K0:1aNbRxFiqrw=:kgOtRowOnufPOAFRM4TJvp KFJbzRg3/CZeEPAkBPVnXHNkzUg9Ev2io5PUk34S57dJRdtGtKbCmmiwTD4l4HPycQKTEU8fa vuVfBBOBeSGy2etJgxMetJ4H8kY0Z3t+JYA9cUbTTslqrx9WAl6oZ2rPBEdjAmqC9Nc8Gqg1+ ovHBH67TQNGV7Jb+QVTrKlD7CKXJEpUWOCzzKYNVnCGgewgOAKEM1tYxKhdYUshwl0K2CEnuD Wu3Lz8jwJTUHmsTltNJvj005bpoOZWtuL97Zpw3auoSiDrW54koC6LFwClMOXmLEI95w8d6D/ vb0CsGGS7U9C4yPJlIz6I3iHnCoDz/3sdhT5kG0kPK5Cl5kB4C1sGhe0xNBucJhJTPsPcNFXR RM+Ym50ocm2vVcLHUe8teSEk37hQjQRbpdLvZBOZZKQdNdtBO3TOy2shFmJtrMAuXgUmAT3Yx Y1bZNcaLxA== Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 16:10:03 -0000 text version: Hi Erik, Thank you, I will have another look at my reference to section 3. Would you agree that in "https://ietf.org" the colon is not part of the hier-part? > On 05/24/2020 2:25 PM Timothy Mcsweeney wrote: > > > Hi Erik, > > Thank you, I will have another look at my reference to section 3. > Would you agree that in "https://ietf.org" the colon is not part of the hier-part? > > On May 24, 2020 at 12:02 PM Erik Wilde < erik.wilde@dret.net> wrote: > > > > > > hey tim. > > > > On 2020-05-24 17:53, Timothy Mcsweeney wrote: > > > Yes, I agree and understand that the same way as you. But when the "#" > > > leaves the client it is not leaving as a fragment, > > what people are telling you is that "#" and anything following it never > > leaves the client, by definition. > > > > > it is leaving as a > > > way to separate the URI components, and or for http it > > > would be separating and . It is this that makes me > > > believe that even if the colon is required for http resolution, it is > > > not necessarily required for all URI. > > this discussion could be more productive if you had a brief look at the > > specs you're depending on. the very first rule shown in > > https://tools.ietf.org/html/rfc3986#section-3 is > > > > URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] > > > > each URI is defined like this and must have a colon. > > > > cheers, > > > > dret. > > > > -- > > erik wilde | mailto: erik.wilde@dret.net | > > | http://dret.net/netdret | > > | http://twitter.com/dret | From nobody Wed Nov 11 08:10:49 2020 Return-Path: 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 5C4DD3A0FD6 for ; Wed, 11 Nov 2020 08:10:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 wy6piTbDmgyF for ; Wed, 11 Nov 2020 08:10:42 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (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 10ACD3A0E19 for ; Wed, 11 Nov 2020 08:10:40 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0LuwOl-1kCzy50mH3-0102Bt for ; Wed, 11 Nov 2020 17:10:40 +0100 Date: Wed, 11 Nov 2020 11:10:39 -0500 (EST) From: Timothy Mcsweeney To: uri-review@ietf.org Message-ID: <385332703.10610.1605111039889@email.ionos.com> In-Reply-To: <1804062312.403587.1590622955990@email.ionos.com> References: <491516506.246380.1589851279474@email.ionos.com> <1630462326.97358.1589928036619@email.ionos.com> <217485042.439703.1589938351012@email.ionos.com> <745178906.42051.1590103115859@email.ionos.com> <1804062312.403587.1590622955990@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:zPjQ+XmeUXv0S+zgJ+nh3DFwmdbdCKuoIwga87dzqDFYdtiYDBM BsLQKfsdbwjnqMtrSAQqS5W7OZGhkfH38TDWgbkC9Ga2Rgg1VtRDILvhfDD7RVJmOq171xd 9X2zJC9tASTWnyQxi2Z13AucP6+HZLBPnGXeu61affbIAIUQ7twHz3oaLuvDUoeoxJCoDcI +UR+sZp/G7wAmm6+z2geQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:jd9/Mv05Hos=:2vyPCP522wMsj9Me2+V+28 zeN6gw+jMf1acnuzJYVRiG9kO1onF3AdaPQ5oR9SD0NcKnEyO3XaDNfaoZWaNsj99a6ytQpJu LDKj1M7Fwat4r6YDvYyei4BTu3G0hv+1/jxsKl0CkneX/8IKNM/UlvpykXQHW3ffq6KbUtjAJ wQZwDspksh2hZKRMHnt00M3Mb2hs20RYWaJC5JnL/AOSoI7DAK2O7TI7HxQ5w5Tduq5Iot+mZ 7dndBb7aTN4Maoy3GAdPyLzoHVWqIIw7wGDa76scRHn3a57qKjrX1YbkxvOEtQq1EdY22yXHS vzLhPTCIwZ7ufY/767SVcy/br0tgLArInG7X3sLGmz0Oc8Uc0ISzqh3u6Ibt6lMth22aPbtKP TcMmnZAQXxm1WllnojiNSxmYPWRdrP8fAGLBZKXZHJ7FX85XRGQrq+2ih05h8VQDjZE6Nu5tz EALvTRq5VQ== Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 16:10:49 -0000 text version: Just putting this conversation up here to show that Ted brought up some good points that I have fixed in the second draft. > On 05/27/2020 7:42 PM Timothy Mcsweeney wrote: > > > Just putting this conversation up here to show that Ted brought up some good points that I have fixed in the second draft. > > On May 21, 2020 at 7:18 PM Timothy Mcsweeney wrote: > > > > > > Hi Ted, > > I have a question for you. In your last couple emails when you said the words "permanent identifier", did you mean: > > > > the string always matches the same object forever > > -or- > > the string will always be an identifier for these particular types of objects > > -or- > > the string is disposable and there will never be another string like it again. > > > > Thanks, > > Tim > > > On May 20, 2020 at 6:42 PM Ted Hardie < ted.ietf@gmail.com> wrote: > > > > > > > > > On Tue, May 19, 2020 at 6:32 PM Timothy Mcsweeney < tim@dropnumber.com> wrote: > > > > > > > > Ted, > > > > Thank you very much for the feedback. Would I be correct in deducing from your reply that if the 'drop' scheme remained a locator that you would recommend it remain a URI over a URN? > > > > Tim > > > > > > Because you can use the DDDS to get from a URN to the a retrieval > > > step, I'm not sure that's the critical property for me. I think for > > > me the difference is whether the drop-string is unique or not. As an > > > example, a URN with a NBN > > > ( https://en.wikipedia.org/wiki/National_Bibliography_Number) can go > > > through a resolver to identify a specific resource. In cases like > > > NBNs (or RFC numbers, for which there are also URNs), the number is > > > never reassigned; the issuer guarantees that the NBN will change if > > > the resource changes. > > > > > > If you are constructing an identifier that is unique but will have > > > internal references which change (e.g. if the telephone number or > > > address associated with it change), you can still use a URN, but it > > > will be associated will be a meta-identifier for the collection of > > > changing versions. That's how vCard's CLIENTPIDMAP works, for > > > example. It sort-of sounds like drop-strings would be dereferenable > > > versions of this, via something like > > > CLIENTPIDMAP.well-known-domain.example. The usefulness of that gets > > > back to the question we discussed before,of whether these are mnemonic > > > or not; discovering the right drop-string to use becomes a major part > > > of the exercise. > > > > > > In general, I think the vCard case might be a useful one for you to > > > spend some time with, because it may be easier to communicate what > > > drop-string will do if you relate it to an existing case. > > > > > > regards, > > > > > > Ted Hardie > > > > > > > > > > > > > > Hi Tim, > > > > On Tue, May 19, 2020 at 3:40 PM Timothy Mcsweeney < tim@dropnumber.com> wrote: > > > > Hi Ted, > > > > Thank you for taking the time to have a look at the draft. I had not considered the use of more than one domain. I will be sure to clarify that there will only be one second level domain used for http. Because I am limited to four flags in the DDDS, at this time I would say my intent would be the same as listed. You are probably right when saying that section will need a rewrite. > > > > Your statement about the drop-string functioning as a permanent identifier with the current telephone number, address, or other contact methods being available as a retrieved resource is spot on but in my head it is a locator. I'm going to give that some more thought. Generally speaking, is this draft something that you would personally find appealing to use? > > > > If this intended to be a permanent identifier and you intend to use the DDDS, I would suggest you consider either a URN or, if you want to look outside the IETF, at an implementation of the handle system, which is currently maintained by the DONA foundation. If you stick with a URN, the result would be a string like this: > > > > urn:drop:nss-specific-string > > > > Drop is the namespace identifier (NID) in this case. The issuer assigned that NID is the issuer of names-specific-strings and has to maintain certain guarantees related to uniqueness, which may or may not work for you depending on your application model. There is, however, already a specification for how to use the DDDS to retrieve URNs (RFC 3402) as well as some experience with S-NAPTR (RFC 3958), which may simplify your deployment. > > > > Your question about whether or not I feel this would be appealing to use is a little hard to answer without knowing more about the construction of the resources it returns and the creation of the strings. If they are essentially random, the deployment model is hard to get going because the users are trading a series of mnemonic strings for an opaque one. vCards (RFC 6350), for example, can contain a UUID in URN form; this is unique, but not memorable. Systems can use it to confirm that a vCard is a new entry in a contacts database, but the URN UUIDs do not really replace any of the entries in the vCard in other contexts. If the strings are not random, then you get markets in the names, along with risks of squatting and so on. Even for the opaque strings there have been such markets (sales of mnemonic telephone numbers, for example, where either keypad mapping or repeating numbers are valued as easy to remember). Those markets (for domain names, twitter handles, and so on) ten d to produce a lot of work in balancing the needs of those trying to maintain trademarks and those wishing to create new marks and identifiers. > > > > regards, > > > > Ted Hardie > > > > > > > > Sincerely, > > > > Tim > > > > On May 19, 2020 at 11:45 AM Ted Hardie < ted.ietf@gmail.com> wrote: > > > > Hi Tim, > > > > Thanks for the pointer to the draft. I think there are two issues here which are large enough that you may wish to think about the implied architecture. The first is a syntactic issue: the use of "#" as the only delimiter in the proposed URIs. As RFC 3986 describes it, the "#" delimiter is used for identifying fragments and is thus dependent on the MIME type of the retrieved object: > > > > The fragment's format and resolution is therefore > > > > dependent on the media type [RFC2046] of a potentially retrieved > > > > representation, even though such a retrieval is only performed if the > > > > URI is dereferenced. > > > > This does not appear to match your usage. The usage you appear to be seeking is a transposition of the string to a subdomain of a well-known domain, so that a client can attempt retrieval via the three methods you enumerate; it is not clear from the document whether there will ever be more than one permitted domain here. A simpler implementation would appear to be drop:drop-string.well-known-domain.example. > > > > Second, your document appears to imply that the drop string is used to augment existing telephone numbers and addresses, but it is not terribly clear how it does this. One interpretation might be that the drop-string functions as a permanent identifier with the current telephone number, address, or other contact methods being available as a retrieved resource. This section: > > > > Primarily functioning as a locator there are three ways to get to a > > > > 'drop' URI resource, http, srv records, and private resolution for > > > > anything not found using the previous two methods. The first, or > > > > default, action is when an application invokes the 'drop' URI it will > > > > cause a lookup for matching application information starting with an A > > > > record [RFC1035], then on to Service records [RFC2782], and then on to > > > > other available records that may offer a new rule set for resolution. > > > > raises a problem with this approach: the records returned by SRV are fundamentally different, in that they are onward pointers to other domains and resolutions. If the implication is that HTTP is always used to retrieve drop records and the appropriate server is discovered by either using an A record, an SRV record, or private resolution, then this section needs a major re-write (to include AAAA records and to clarify the intent). It's also not clear what long lived utility a new scheme serves here if the result is always https://some-string.discovered-domain.example/ . > > > > If there were a different guarantee of uniqueness than the DNS, this would seem closer to a URN than other URI forms, or possibly an implementation of the handle system (as DOIs are). There is, unfortunately, not enough detail in the draft on the overall system to be confident of that. > > > > regards, > > > > Ted Hardie > > > > > > > > On Mon, May 18, 2020 at 6:21 PM Timothy Mcsweeney < tim@dropnumber.com> wrote: > > > > Hello everyone, > > > > This is a request for a review of the 'drop' URI scheme. The draft can be found here < " rel="noopener" target="_blank" data-mce-href="https://datatracker.ietf.org/doc/draft-mcsweeney-drop-scheme/>">https://datatracker.ietf.org/doc/draft-mcsweeney-drop-scheme/> (https://datatracker.ietf.org/doc/draft-mcsweeney-drop-scheme/). Thank you. > > > > Sincerely, > > > > Tim McSweeney > > > > _______________________________________________ > > > > Uri-review mailing list > > > > Uri-review@ietf.org > > > > https://www.ietf.org/mailman/listinfo/uri-review > > > > > > > > > > > > > > > > > > > > > > From nobody Wed Nov 11 08:11:38 2020 Return-Path: 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 0DC713A0141 for ; Wed, 11 Nov 2020 08:11:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 sZ1e5nPQjLEh for ; Wed, 11 Nov 2020 08:11:35 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (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 D93603A0E92 for ; Wed, 11 Nov 2020 08:11:20 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0LnyM2-1k61wG0Eci-00g2Wv for ; Wed, 11 Nov 2020 17:11:20 +0100 Date: Wed, 11 Nov 2020 11:11:19 -0500 (EST) From: Timothy Mcsweeney To: uri-review@ietf.org Message-ID: <1692000460.10654.1605111079774@email.ionos.com> In-Reply-To: <1081815563.141711.1590624311343@email.ionos.com> 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> <1081815563.141711.1590624311343@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:gvL3UKNN2KDJF+fmd0YaVjHptnBfqC0JnxVZRn9dm8nj8E0rYoE YeohYQORpqymPSNO3hHOHAb1yuHavN9eGJayd8QISc+pjnGLLkxFlaYjkIr3IU7GUyGP2Q+ dmm68tRzblAiGRFbGhNyeD3AfRGvj/GcDQLyyxLwCceyLG0H3uXveHJmeQxD4rqkz2Xk9zO ns5G/azSmJ7KnL6WFqvMA== X-UI-Out-Filterresults: notjunk:1;V03:K0:s05CD3wqMnM=:5GGrrqwRULR5l6q4VbLcaW skOiVTGiZygSyyTuhfxh00KdSSFmIv1esRBbLIl9TfXohWJZ7C5Oenx8y6r3+dN9g9JiOkmf6 HSQPY4WR9sOqFhhptRfCVUwCVXkAF6VYZ6xFgPRlhplhtQ0VI/CUBbCW98JOTfw65AXSo0Hy/ ZomTc0jere3Dzuxb0cwpidz3JTiTaAJZlGyOfE+lbxZRMdMldG6y9oRdBjWgz1TjTpYoAwjgC so77+Gzx1yKu4q7D4jvKrY2gnzwS/GAziyTz5BJsECp4ub3pZx1klZwV5lCrs/2bwb4eeGIxI G//6w3siA/anBYe2vjakCdUOH09bZm97Nrj3gIt4svBd0xMT6WQVkI4m8B5ZmueYijgavUNR3 r/GRK+wTxmwX4kRfEuBOpFUUhUda5NeljrVa1EKRlAm+DHqHbFfHrjBcrbyMkbrAkuVtjigFv UAiwDCzuXw== Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 16:11:37 -0000 text version: Hi Dave, If the other six gen-delims from the reserved set were safe and valid, woul= d you oppose their use in URIs? Tim > On 05/27/2020 8:05 PM Timothy Mcsweeney wrote: >=20 >=20 > Hi Dave, >=20 >=20 > If the other six gen-delims from the reserved set were safe and valid, wo= uld you oppose their use in URIs? >=20 >=20 > Tim >=20 >=20 >=20 > > On May 24, 2020 at 6:08 PM Dave Thaler wrote:= =20 > >=20 > >=20 > > Hi Tim, > >=20 > > Correct the colon is not part of the hier-part, the hier-part is what c= omes after the colon. RFC 3986 says: > >=20 > > URI =3D scheme ":" hier-part [ "?" query ] [ "#" fragment ] > >=20 > > Only strings that conform to the above are URIs. > > So =E2=80=9Cdrop#sd54g54=E2=80=9D is not a URI because it does not conf= orm to the above syntax, as it has no =E2=80=9C:=E2=80=9D > >=20 > > =E2=80=9Cdrop:sd54g54=E2=80=9D on the other hand would be a valid URI. > >=20 > > This is what folks are saying when they say if you just change the =E2= =80=9C#=E2=80=9D to a =E2=80=9C:=E2=80=9D in your draft then it becomes leg= al. > >=20 > > Dave > >=20 > > From:Uri-review On Behalf OfTimothy Mcswe= eney > > Sent: Sunday, May 24, 2020 11:26 AM > > To: Erik Wilde ; uri-review@ietf.org > > Subject: Re: [Uri-review] Request for review > >=20 > > Hi Erik, > >=20 > > Thank you, I will have another look at my reference to section 3. > > Would you agree that in "https://ietf.org" the colon is not part of the= hier-part? > > > On May 24, 2020 at 12:02 PM Erik Wilde < erik.wilde@dret.net> wrote: > > >=20 > > >=20 > > > hey tim. > > >=20 > > > On 2020-05-24 17:53, Timothy Mcsweeney wrote: > > > > Yes, I agree and understand that the same way as you. But when the = "#" > > > > leaves the client it is not leaving as a fragment, > > > what people are telling you is that "#" and anything following it nev= er > > > leaves the client, by definition. > > >=20 > > > > it is leaving as a > > > > way to separate the URI components, and or for http= it > > > > would be separating and . It is this that makes= me > > > > believe that even if the colon is required for http resolution, it = is > > > > not necessarily required for all URI. > > > this discussion could be more productive if you had a brief look at t= he > > > specs you're depending on. the very first rule shown in > > > https://tools.ietf.org/html/rfc3986#section-3 (https://nam06.safelink= s.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc39= 86%23section-3&data=3D02%7C01%7Cdthaler%40microsoft.com%7C301845b79f34417b8= da108d8000ffe6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63725941598852= 3425&sdata=3D8SdFPIQPmfPOefEYg%2Fy13BK0AMhxkW6g55TE5MAJ2pY%3D&reserved=3D0)= is > > >=20 > > > URI =3D scheme ":" hier-part [ "?" query ] [ "#" fragment ] > > >=20 > > > each URI is defined like this and must have a colon. > > >=20 > > > cheers, > > >=20 > > > dret. > > >=20 > > > -- > > > erik wilde | mailto: erik.wilde@dret.net | > > > | http://dret.net/netdret (https://nam06.safelinks.protection.outlook= .com/?url=3Dhttp%3A%2F%2Fdret.net%2Fnetdret&data=3D02%7C01%7Cdthaler%40micr= osoft.com%7C301845b79f34417b8da108d8000ffe6c%7C72f988bf86f141af91ab2d7cd011= db47%7C1%7C0%7C637259415988523425&sdata=3DAsAJT%2BzCdftgNtsB3tJr7Yj7hTBe8%2= BES%2BHLi7QMUudg%3D&reserved=3D0) | > > > | http://twitter.com/dret (https://nam06.safelinks.protection.outlook= .com/?url=3Dhttp%3A%2F%2Ftwitter.com%2Fdret&data=3D02%7C01%7Cdthaler%40micr= osoft.com%7C301845b79f34417b8da108d8000ffe6c%7C72f988bf86f141af91ab2d7cd011= db47%7C1%7C0%7C637259415988533419&sdata=3DP%2FHldqxET0s4Ka1%2BYCw9xaHlCrItX= J9ko8rwHa%2B0Mag%3D&reserved=3D0) | >=20 > From nobody Wed Nov 11 08:12:08 2020 Return-Path: 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 743403A02BD for ; Wed, 11 Nov 2020 08:12:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 J91Gi08x5IC1 for ; Wed, 11 Nov 2020 08:12:06 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (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 B9A923A0141 for ; Wed, 11 Nov 2020 08:12:05 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MIL1t-1kaOYY3gxr-004FiO; Wed, 11 Nov 2020 17:12:01 +0100 Date: Wed, 11 Nov 2020 11:12:01 -0500 (EST) From: Timothy Mcsweeney To: Dave Thaler , uri-review@ietf.org Message-ID: <1410771389.10680.1605111121525@email.ionos.com> In-Reply-To: <117630321.142251.1590627970509@email.ionos.com> 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> <1081815563.141711.1590624311343@email.ionos.com> <117630321.142251.1590627970509@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:NPrEDnOtYNdxmenAwIm6SA45sM3G7Z4x0IjWcIi9opAqPDz5PcT Pou6eG7Ycnd33m4EzB88aTFWDACGV+W7+/TJ2p6NlhaIQb1Qm5PzBuO2LXzIMYtvZVWH4lE 8R9bnRsJfjVNoNiRDBDmsGzTwBdalXLL6BSAf+DXI80ylgZoQhzH1AkuXwBkeK3rLgloVlJ XVMVbts8SC+d4obFzSNpw== X-UI-Out-Filterresults: notjunk:1;V03:K0:ZDdQ5Yu1i9E=:rYViCL0KNRsk+xg80WSol/ 62O68TO7KEkB17GmYDyMNjzYRqwtAMaikurrjNRYS99sH7sQSN+Z9GBbDX1KeWjzcJVjIjmj/ PJQjByfEteJafc0o9OeobA2Sx7CzkEn7yzPF1GOG925S/bV36O3JBWtbPKJLU7DoqSXJM/iAf pTpXK72IX1w7ChqOBaBSA+TFeHETYuNygXMT51nH019p4pIayOmy56yWMlZbDURs7lhOCxzoV 6QylmLGnBk4LleDmiN8lUcJCSfAifiZ6v5gSHQf5E58l0f64Fl9KbxZkWm49jhhq2KWx0ugZ5 wOA2YUBI5vb54q+uYQ7PbZiaP/ZjK9WgXVNXtsOPWuGsGRTFOxcK7w02PbAHf+7/RucQgoc/+ lG4wnnfJvOmhgYLFwTYfOJFyxlxvU5k5GMW/HKKjY8DPVH+evQBg+UkIWxNbACus/Xk2kXRd5 2z42fcv6YQ== Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 16:12:07 -0000 text version: Hi Dave,=20 By "safe" I meant like "..... safe to be used by scheme-specific and producer-specific algorithms for delimiting data subcomponents within a URI" Like it says in section 2.2 of RFC3986. =20 Tim > On 05/27/2020 9:06 PM Timothy Mcsweeney wrote: >=20 >=20 > Hi Dave, >=20 > By "safe" I meant like "..... > safe to be > used by scheme-specific and producer-specific algorithms for > delimiting data subcomponents within a URI" >=20 > Like it says in section 2.2 of RFC3986. =20 >=20 > Tim >=20 > > On May 27, 2020 at 8:48 PM Dave Thaler wrote:= =20 > >=20 > >=20 > > s/URL/URI/ in both cases in my responseJ > >=20 > > From:Uri-review On Behalf OfDave Thaler > > Sent: Wednesday, May 27, 2020 5:47 PM > > To: Timothy Mcsweeney ; uri-review@ietf.org > > Subject: Re: [Uri-review] Request for review > >=20 > > I don=E2=80=99t understand your question. The URL syntax is fixed by th= at RFC. > > I don=E2=80=99t know what you mean by =E2=80=9Csafe=E2=80=9D or =E2=80= =9Cvalid=E2=80=9D. > >=20 > > If by =E2=80=9Cvalid=E2=80=9D you mean =E2=80=9Callowed by RFC 3986=E2= =80=9D, the answer is that they may only appear in a URL literally > > if they have the exact meaning in the RFC, otherwise they must be pct-e= ncoded. > >=20 > >=20 > > From:Uri-review On Behalf OfTimothy Mcswe= eney > > Sent: Wednesday, May 27, 2020 5:05 PM > > To: uri-review@ietf.org > > Subject: Re: [Uri-review] Request for review > >=20 > > Hi Dave, > >=20 > > If the other six gen-delims from the reserved set were safe and valid, = would you oppose their use in URIs? > >=20 > > Tim > >=20 > >=20 > >=20 > > > On May 24, 2020 at 6:08 PM Dave Thaler wrote: > > > Hi Tim, > > >=20 > > > Correct the colon is not part of the hier-part, the hier-part is what= comes after the colon. RFC 3986 says: > > >=20 > > > URI =3D scheme ":" hier-part [ "?" query ] [ "#" fragment ] > > >=20 > > > Only strings that conform to the above are URIs. > > > So =E2=80=9Cdrop#sd54g54=E2=80=9D is not a URI because it does not co= nform to the above syntax, as it has no =E2=80=9C:=E2=80=9D > > >=20 > > > =E2=80=9Cdrop:sd54g54=E2=80=9D on the other hand would be a valid URI= . > > >=20 > > > This is what folks are saying when they say if you just change the = =E2=80=9C#=E2=80=9D to a =E2=80=9C:=E2=80=9D in your draft then it becomes = legal. > > >=20 > > > Dave > > >=20 > > > From:Uri-review On Behalf OfTimothy Mcs= weeney > > > Sent: Sunday, May 24, 2020 11:26 AM > > > To: Erik Wilde ; uri-review@ietf.org > > > Subject: Re: [Uri-review] Request for review > > >=20 > > > Hi Erik, > > >=20 > > > Thank you, I will have another look at my reference to section 3. > > > Would you agree that in "https://ietf.org (https://nam06.safelinks.pr= otection.outlook.com/?url=3Dhttps%3A%2F%2Fietf.org%2F&data=3D02%7C01%7Cdtha= ler%40microsoft.com%7Cb115c7f8c70b410eb98308d802a0a8f4%7C72f988bf86f141af91= ab2d7cd011db47%7C1%7C0%7C637262236339204192&sdata=3DUJ7TQnKfGZMnWkBKZCVozZQ= hn%2BGir1saiPQoNGV2C9M%3D&reserved=3D0)" the colon is not part of the hier-= part? > > > > On May 24, 2020 at 12:02 PM Erik Wilde < erik.wilde@dret.net> wrote= : > > > >=20 > > > >=20 > > > > hey tim. > > > >=20 > > > > On 2020-05-24 17:53, Timothy Mcsweeney wrote: > > > > > Yes, I agree and understand that the same way as you. But when th= e "#" > > > > > leaves the client it is not leaving as a fragment, > > > > what people are telling you is that "#" and anything following it n= ever > > > > leaves the client, by definition.. > > > >=20 > > > > > it is leaving as a > > > > > way to separate the URI components, and or for ht= tp it > > > > > would be separating and . It is this that mak= es me > > > > > believe that even if the colon is required for http resolution, i= t is > > > > > not necessarily required for all URI. > > > > this discussion could be more productive if you had a brief look at= the > > > > specs you're depending on. the very first rule shown in > > > > https://tools.ietf.org/html/rfc3986#section-3 (https://nam06.safeli= nks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.ietf..org%2Fhtml%2Frf= c3986%23section-3&data=3D02%7C01%7Cdthaler%40microsoft.com%7Cb115c7f8c70b41= 0eb98308d802a0a8f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63726223633= 9214150&sdata=3DupZbOkALJ8SuEk%2FpLLqhdDDUNMhdpSmjWqpMAyITzc8%3D&reserved= =3D0) is > > > >=20 > > > > URI =3D scheme ":" hier-part [ "?" query ] [ "#" fragment ] > > > >=20 > > > > each URI is defined like this and must have a colon. > > > >=20 > > > > cheers, > > > >=20 > > > > dret. > > > >=20 > > > > -- > > > > erik wilde | mailto: erik.wilde@dret.net | > > > > | http://dret.net/netdret (https://nam06.safelinks.protection.outlo= ok.com/?url=3Dhttp%3A%2F%2Fdret.net%2Fnetdret&data=3D02%7C01%7Cdthaler%40mi= crosoft.com%7Cb115c7f8c70b410eb98308d802a0a8f4%7C72f988bf86f141af91ab2d7cd0= 11db47%7C1%7C0%7C637262236339214150&sdata=3Dhq8QVDrXxRmV3iS6DF7R%2FeXFtDKnt= McYOHnLSMqx5zo%3D&reserved=3D0) | > > > > | http://twitter.com/dret (https://nam06.safelinks.protection.outlo= ok.com/?url=3Dhttp%3A%2F%2Ftwitter.com%2Fdret&data=3D02%7C01%7Cdthaler%40mi= crosoft.com%7Cb115c7f8c70b410eb98308d802a0a8f4%7C72f988bf86f141af91ab2d7cd0= 11db47%7C1%7C0%7C637262236339224105&sdata=3D9V5l2cgygLF2GJbT9Eh0ptd2mv4YRbv= Zm6oaYSrf8fE%3D&reserved=3D0) | > >=20 > >=20 >=20 > From nobody Wed Nov 11 08:21:24 2020 Return-Path: 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 C61533A03FB for ; Wed, 11 Nov 2020 08:21:22 -0800 (PST) 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 XGrf9Hd8WkmZ for ; Wed, 11 Nov 2020 08:21:21 -0800 (PST) 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 DD0233A0990 for ; Wed, 11 Nov 2020 08:21:16 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1M3U6Q-1kdQpl3ocU-000bnp for ; Wed, 11 Nov 2020 17:21:15 +0100 Date: Wed, 11 Nov 2020 11:21:15 -0500 (EST) From: Timothy Mcsweeney To: uri-review@ietf.org Message-ID: <2075956636.11218.1605111675605@email.ionos.com> In-Reply-To: <1729337515.289325.1590778487527@email.ionos.com> 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> <1081815563.141711.1590624311343@email.ionos.com> <117630321.142251.1590627970509@email.ionos.com> <8ae1641a-74c8-6c2d-7092-6cf53e745fb7@ninebynine.org> <797476254.282655.1590770737009@email.ionos.com> <1729337515.289325.1590778487527@email.ionos.com> 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.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:A/wUexXLat4UJeUVPGWz6JVZ1q4+nY2WYiV3iHs/eUnd1HTVOuu bC602n3mzOeeBiz/C2t2zIZNF3C3AF5V8MDbhZwna+jW6PAtuDkzzGAsl+3Pgy4PGPGH5pH hbEqqLdRR+m7d/SAHYWQSjPO2s21Q8U2rJpgfxagcikAiRbv248scIexPbapG6FWLxnsSLU untDqryj1RmSVRnGZhWVA== X-UI-Out-Filterresults: notjunk:1;V03:K0:FKiWVK6KQIQ=:ENLkgdjXJe1nae4zC4gG4p KD3rQjLyG1es+u5jKcgvrbO165U+4WDKSTzM4FUVnDcmc2DPfngh6N54+OQbCq9QbF5W7BfTc g29KeY2+XcPzR68dOLbRnu9gPNyCyImSPDASHg4FS+LayOtdBJyIm3xAfu0oQH/el8LqF98Iq s6/ShVlHjiKw3zCb9nVUFQPXYIR8ZGY1JAxp8mHNI/n7S0o1cq1HKUfEkmGSvDyx+ig/smYGc xa04qDeUexQJPO7AdGh0wFi65yWVwNmk1ejChz9gGSvAl1+O9W/A8vF2J8InAW/HbQ73P8/Ql /WgFRh2HWPRHUcX8z2azGujwA3SwC3EYZMPB2hgbc6/UzjcQmguwEMt1bRdHK48PesJTQ0vM2 U6zZ24cFfYEu4YuM/aQqBaQje89LMHR4nOlbP9966ZqzysqUsFtO8ZR13FTmZF38zwGWMqxv3 j+OvAs85Ag== Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 16:21:23 -0000 =20 =20
text version:
Hi Ted,
>For a URI parser, the method used to identify the scheme within any= example is basically: "it's the bit to the left of the colon".

Is it basically this, or exactly this?

> The colon is the "end of label" marker, and that's why folks are i= nsisting on it here; without it, you can't use the URI API to select a bran= ch

Is the colon the only "end of label" marker?

Tim


On 05/29/2020 2:54 PM Timothy Mcsweeney <tim@dropnumber.com> wrot= e:


Hi Ted,
>For a URI parser, the method used to identify the scheme within an= y example is basically: "it's the bit to the left of the colon".

Is it basically this, or exactly this?

> The colon is the "end of label" marker, and that's why folks are = insisting on it here; without it, you can't use the URI API to select a bra= nch

Is the colon the only "end of label" marker?

Tim
On May 29, 2020 at 2:22 PM Ted Hardie <ted.ietf@gmail.com> wrote:= =20

Hi Tim,

Thanks for sharing your thoughts on this.  Let me suggest a slig= htly different formulation, which is not based on the colon itself, but on = the scheme. =20

The scheme indicates which type of URI a particular  example is = and thus governs a bunch of the behavior you describe below (whether it is = used to dereference resources and, if so, what protocol(s) are used, if the= re are specific parameters and, if so, whether any are mandatory, and so on= ).  For a URI parser, the method used to identify the scheme within an= y example is basically: "it's the bit to the left of the colon".  If y= ou don't have that specific marker, then a standard URI parser won't find a= scheme and thus won't know what behavior to match to the example. =20

A common early metaphor for this was to identify the network retrieva= l protocols as different parts of the plumbing of the Web, with the scheme = names as the labels on the taps.  That plumbing metaphor doesn't reall= y work with abstract identifiers and is stretched by schemes like HTTPS whi= ch might have more than one set of underlying protocols.  But the labe= ling still does--you can think of the schemes and the labels that tell the = API which branch of behavior to invoke.  The colon is the "end of labe= l" marker, and that's why folks are insisting on it here; without it, you c= an't use the URI API to select a branch.=20

best regards,

Ted=20


On Fri, May 29, 2020 at 9:46 AM Timothy Mcsweeney < tim@dropnumber.com> wrote:=20
Hi Graham,

I would never treat suggestions from this list as arbitrary, quit= e the contrary.  =20
I want to change the format of this reply just for a minute t= o express my deductions. 

This is an excerpt from the conversation in my head:


If you take away all the components and subcomponents of a UR= I, what's leftover? =20
The colon. =20
And what governs the colon? =20
The dereferencing algorithm. =20
Does http use a colon in its dereferencing? =20
It does. =20
What about a URN? =20
It does. =20
FTP and Mailto? =20
Yup the same. =20
So If you change the colon to a number sign would you get the= m same output?=20
Yes.=20
All of them? =20
Yes.=20
Can you prove it?=20
Yes.  =20
Why do all the delimiters have quotes around them?=20
Because they are interchangeable.=20
Interchangeable everywhere?=20
No, just within the scope of their placement.  That's wh= y URNs can use a bunch of colons and not interfere with the first colon aft= er the URN scheme name.=20
But it says the colon is required doesn't it?=20
I can not pinpoint the sentence that says that.=20
But section 3, the colon is in the generic syntax, you can se= e that right?=20
Yes but the title of section 3 is "Syntax Components" and the= colon is not a component. =20
Wait, what does generic mean?=20
Not specific. =20
So the generic syntax is not specific?=20
That's right.=20
So [RFC3986] is a specification that is defining something th= at is not specific?=20
Yup, says it right there in the abstract.

From here my mental conversation took a left turn.  But = I wanted to put this out here so that the members of this list didn't think= my intent was for purely self interest reasons but that we can all use wha= t's here. 

Tim

On May 29, 2020 at 6:01 AM Graham Klyne < gk@ninebynine.org>= ; wrote:


Hmmm... I find that bit of RFC3986 isn't immeditely clear. But on = closer study,
I think it's simply saying that the characters are "safe" in the s= ense that
they are protected from change by URI normalization, hence that wh= en used as
delimiters there is no risk that the interpretation of the URI is = affected by
URI normalization (see also section 6 of RFC 3986).

But some of these reserved characters already have defined purpose= s in URI
structure, and any scheme-dependent use needs to take care not to = interfere with
such use. For example, using "#" as a delimiter within a URI path = would
interfere with it's already-defined purpose to delimit a fragment.

Also, current URI structure *requires* that the ":" is used to del= imit the
scheme name from the rest of the URI. Suggestions by others on thi= s list to use
":" rather than "#" are not entirely arbitrary.

As a rule of thumb, I would suggest that if you do need scheme-spe= cific
delimiters (and it's not clear to me that you do), then using one = from the
"sub-delims" set is more likely to avoid conflicts with generic UR= I syntax and
interpretation.

#g
--


On 28/05/2020 02:06, Timothy Mcsweeney wrote:
Hi Dave,

By "safe" I meant like ".....

safe to be
used by scheme-specific and producer-specific algorithms for
delimiting data subcomponents within a URI"

Like it says in section 2.2 of RFC3986.

Tim

On May 27, 2020 at 8:48 PM Dave Thaler < dthaler@microsoft.c= om> wrote:
>> s/URL/URI/ in both cases in my response J
>>
>> *From:*Uri-review < uri-review-bounces@ietf.org= > *On Behalf Of *Dave Thaler
>> *Sent:* Wednesday, May 27, 2020 5:47 PM
>> *To:* Timothy Mcsweeney < tim@dropnumber.com>; uri= -review@ietf.org
>> *Subject:* Re: [Uri-review] Request for review
>>
>>
>> I don=E2=80=99t understand your question.   The= URL syntax is fixed by that RFC.
>>
>> I don=E2=80=99t know what you mean by =E2=80=9Csafe=E2=80= =9D or =E2=80=9Cvalid=E2=80=9D.
>>
>> If by =E2=80=9Cvalid=E2=80=9D you mean =E2=80=9Callowed b= y RFC 3986=E2=80=9D, the answer is that they may only
>> appear in a URL literally
>>
>> if they have the exact meaning in the RFC, otherwise they= must be pct-encoded.
>>
>> *From:*Uri-review < uri-review-bounces@ietf.org=
>> <mailto: uri-review-bounces@ietf.org>>= ; *On Behalf Of *Timothy Mcsweeney
>> *Sent:* Wednesday, May 27, 2020 5:05 PM
>> *Subject:* Re: [Uri-review] Request for review
>>
>>
>> Hi Dave,
>>
>>
>> If the other six gen-delims from the reserved set were sa= fe and valid, would
>> you oppose their use in URIs?
>>
>>
>> Tim
>>
>>
>>
>>
>> On May 24, 2020 at 6:08 PM Dave Thaler < dthaler@micr= osoft.com
>> <mailto: dthaler@microsoft.com>> wrote:
>>
>> Hi Tim,
>>
>> Correct the colon is not part of the hier-part, the hier-= part is what
>> comes after the colon.  RFC 3986 says:
>>
>> URI         =3D s= cheme ":" hier-part [ "?" query ] [ "#" fragment ]
>>
>> Only strings that conform to the above are URIs.
>>
>> So =E2=80=9Cdrop#sd54g54=E2=80=9D is not a URI because it= does not conform to the above
>> syntax, as it has no =E2=80=9C:=E2=80=9D
>>
>> =E2=80=9Cdrop:sd54g54=E2=80=9D on the other hand would be= a valid URI.
>>
>> This is what folks are saying when they say if you just c= hange the =E2=80=9C#=E2=80=9D to
>> a =E2=80=9C:=E2=80=9D in your draft then it becomes legal= .
>>
>> Dave
>>
>> *From:*Uri-review < uri-review-bounces@ietf.org=
>> <mailto: uri-review-bounces@ietf.org>>= ; *On Behalf Of *Timothy Mcsweeney
>> *Sent:* Sunday, May 24, 2020 11:26 AM
>> *To:* Erik Wilde < erik.wilde@dret.net <mailto: = e= rik.wilde@dret.net>>;
>> *Subject:* Re: [Uri-review] Request for review
>>
>>
>> Hi Erik,
>>
>>
>> Thank you, I will have another look at my reference to se= ction 3.
>>
>> Would you agree that in " https://ietf.org
>> the colon is not part of the hier-part?
>>
>> <mailto: erik.wilde@dret.net>> wrote:
>>
>>
>>
>> hey tim.
>>
>>
>> On 2020-05-24 17:53, Timothy Mcsweeney wrote:
>>
>> Yes, I agree and understand that the same way as you.&nbs= p;  But when
>> the "#"
>>
>> leaves the client it is not leaving as a fragment,
>>
>> what people are telling you is that "#" and anything foll= owing it never
>>
>> leaves the client, by definition..
>>
>>
>> it is leaving as a
>>
>> way to separate the URI components, <scheme> and &l= t;path> or for http it
>>
>> would be separating <scheme> and <authority>.=   It is this that
>> makes me
>>
>> believe that even if the colon is required for http resol= ution, it is
>>
>> not necessarily required for all URI.
>>
>> this discussion could be more productive if you had a bri= ef look at the
>>
>> specs you're depending on. the very first rule shown in
>>
>> is
>>
>>
>> URI =3D scheme ":" hier-part [ "?" query ] [ "#" fragment= ]
>>
>>
>> each URI is defined like this and must have a colon.
>>
>>
>> cheers,
>>
>>
>> dret.
>>
>>
>> --
>>
>> erik wilde | mailto: erik.wilde@dret.net <mailto: <= a href=3D"mailto:erik.wilde@dret.net" target=3D"_blank" rel=3D"noopener">er= ik.wilde@dret.net> |
>>
>> |
>>
>> |
>>
>>

_______________________________________________
Uri-review mailing list
_______________________________________________=20
Uri-review mailing list=20
Uri-review@ietf.org=20
https://www.ietf.org/mailman/listinfo/uri-re= view=20

 
From nobody Wed Nov 11 08:24:10 2020 Return-Path: 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 72E0F3A0DFB for ; Wed, 11 Nov 2020 08:24:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 PHW7mqG8sBGt for ; Wed, 11 Nov 2020 08:24:06 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (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 93EE73A03FB for ; Wed, 11 Nov 2020 08:24:06 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1MEFKb-1kTIfN3IKT-00ACJ0; Wed, 11 Nov 2020 17:23:28 +0100 Date: Wed, 11 Nov 2020 11:23:27 -0500 (EST) From: Timothy Mcsweeney To: Graham Klyne , uri-review@ietf.org Message-ID: <1234871373.11344.1605111807115@email.ionos.com> In-Reply-To: <1435838702.391137.1590841215132@email.ionos.com> 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> <1081815563.141711.1590624311343@email.ionos.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> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:FI0bCj1WIXcAKNOMHP+P94bWhiuHXSQNnVl3bdlL4U1iQYFp2Jo 28lpp6ll9xpqLV9ngExLp+3eNxk33ES3egOj1MpLwqHj/7hqMmYDXF1oguSIneodFDXki+r Xl5aaJV5oF9zrSrSjf0JKcLUsY/dK/JFac28FAWyUwf3COqijgI9sonFRIEg3hhZVzC0h6D 7RVW7mPEMfAET5obDtt0g== X-UI-Out-Filterresults: notjunk:1;V03:K0:WoMvnVlkyC0=:7sOiGzEsa/iTkzpCPF0SmG oTkHUg8mrYKLXg7d3iOdC08VjQV81whrA42efMAXpzMUZzPLijo+H1BprAlJBKw+ARv128z92 0kuOqEYBnslzQBT7Ylbx5sP+oCBc6JgFpJeTS+ZeKRXtYMRYdRsHk6VogvsVXgwouS5mPk66v HILQeUxPdsvb8OOIk/VD/ya3pQNe16pRHMiEzkTntpkmMKXW1KkJ/+mZUwOXnmC+QXyS9rih8 Vv+bn8TgqAQyv4vD23mgKnXRjxjhOjLRlj5goyZJEexHuY8DXiYH+Dr9Ot93eaQ1bPtt7JV+5 1ONfhFyExvx+CAScoLcB7rNRJmW5uTAUkufUJDBYUOrla0cmL6JOI0eLUUM6AVWSldDg8jUqY rP6J7hfgpJRJodqbnPFDxNPb9+rfSxUAAL2ziuMmlVtbeK0LnfjXloXJXvI1bZrVanTdzuVLh 2dDJVGE2JA== Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 16:24:08 -0000 text version: Hi Graham,=20 >>A short answer here is that you need the colon after the scheme name because that's what the URI specification, which represents a community consensus, says. Yes, the entire 3986 represents a community consensus , even the parts some don't like, including the parts I want to use. The community that ratified = that RFC still exists. And if people want to make parsers that don't work with the spec it doesn't= become the spec's problem. Tim > On 05/30/2020 8:20 AM Timothy Mcsweeney wrote: >=20 >=20 > Hi Graham, >=20 > >>A short answer here is that you need the colon after the scheme name > because that's what the URI specification, which represents a community > consensus, says. >=20 > Yes,=C2=A0the entire 3986 represents a community consensus , even the par= ts some > don't like, including the parts I want to use. The community that ratifie= d that > RFC still exists. >=20 > And if people want to make parsers that don't work with the spec it doesn= 't become the spec's problem. >=20 >=20 > Tim >=20 > > On May 30, 2020 at 5:24 AM Graham Klyne < gk@ninebynine.org> wrote: > >=20 > >=20 > > Hi Tim, > >=20 > > A short answer here is that you need the colon after the scheme name be= cause > > that's what the URI specification, which represents a community consens= us, says. > >=20 > > A pragmatic response is that many contexts allow either a URI or a rela= tive > > reference to be used (e.g. HTML ). So it's important fo= r a > > processor to be able to distinguish between these cases. The colon afte= r the > > sceme name is what makes that possible > > ( https://tools.ietf.org/html/rfc3986#section-4.1). > >=20 > > (BTW, I wasn't suggesting you were treating anything as arbitrary. But = in > > practice, some choices *are* arbitrary, and for interoperability we nee= d to > > agree some such choices.) > >=20 > > #g > > -- > >=20 > >=20 > > On 29/05/2020 17:45, Timothy Mcsweeney wrote: > > > Hi Graham, > > >=20 > > > I would never treat suggestions from this list as arbitrary, quite th= e contrary. > > > I want to change the format of this reply just for a minute to expres= s my > > > deductions. > > >=20 > > > This is an excerpt from the conversation in my head: > > >=20 > > >=20 > > > If you take away all the components and subcomponents of a URI, what'= s leftover? > > > The colon. > > > And what governs the colon? > > > The dereferencing algorithm. > > > Does http use a colon in its dereferencing? > > > It does. > > > What about a URN? > > > It does. > > > FTP and Mailto? > > > Yup the same. > > > So If you change the colon to a number sign would you get them same o= utput? > > > Yes. > > > All of them? > > > Yes. > > > Can you prove it? > > > Yes. > > > Why do all the delimiters have quotes around them? > > > Because they are interchangeable. > > > Interchangeable everywhere? > > > No, just within the scope of their placement. That's why URNs can use= a bunch > > > of colons and not interfere with the first colon after the URN scheme= name. > > > But it says the colon is required doesn't it? > > > I can not pinpoint the sentence that says that. > > > But section 3, the colon is in the generic syntax, you can see that r= ight? > > > Yes but the title of section 3 is "Syntax Components" and the colon i= s not a > > > component. > > > Wait, what does generic mean? > > > Not specific. > > > So the generic syntax is not specific? > > > That's right. > > > So [RFC3986] is a specification that is defining something that is no= t specific? > > > Yup, says it right there in the abstract. > > >=20 > > > From here my mental conversation took a left turn. But I wanted to pu= t this > > > out here so that the members of this list didn't think my intent was = for purely > > > self interest reasons but that we can all use what's here. > > > Tim > > >=20 > > > > On May 29, 2020 at 6:01 AM Graham Klyne < gk@ninebynine.org > > > > > wrote: > > >> > > >> Hmmm... I find that bit of RFC3986 isn't immeditely clear. But on cl= oser study, > > >> I think it's simply saying that the characters are "safe" in the sen= se that > > >> they are protected from change by URI normalization, hence that when= used as > > >> delimiters there is no risk that the interpretation of the URI is af= fected by > > >> URI normalization (see also section 6 of RFC 3986). > > >> > > >> But some of these reserved characters already have defined purposes = in URI > > >> structure, and any scheme-dependent use needs to take care not to in= terfere with > > >> such use. For example, using "#" as a delimiter within a URI path wo= uld > > >> interfere with it's already-defined purpose to delimit a fragment. > > >> > > >> Also, current URI structure *requires* that the ":" is used to delim= it the > > >> scheme name from the rest of the URI. Suggestions by others on this = list to use > > >> ":" rather than "#" are not entirely arbitrary. > > >> > > >> As a rule of thumb, I would suggest that if you do need scheme-speci= fic > > >> delimiters (and it's not clear to me that you do), then using one fr= om the > > >> "sub-delims" set is more likely to avoid conflicts with generic URI = syntax and > > >> interpretation. > > >> > > >> #g > > >> -- > > >> > > >> > > >> On 28/05/2020 02:06, Timothy Mcsweeney wrote: > > >>> Hi Dave, > > >>> > > >>> By "safe" I meant like "..... > > >>> > > >>> safe to be > > >>> used by scheme-specific and producer-specific algorithms for > > >>> delimiting data subcomponents within a URI" > > >>> > > >>> Like it says in section 2.2 of RFC3986. > > >>> > > >>> Tim > > >>> > > >>>> On May 27, 2020 at 8:48 PM Dave Thaler < dthaler@microsoft.com > > >>>> > wrote: > > >> >> s/URL/URI/ in both cases in my response J > > >> >> > > >> >> *From:*Uri-review < uri-review-bounces@ietf.org > > >> > *On Behalf Of *Dave Thaler > > >> >> *Sent:* Wednesday, May 27, 2020 5:47 PM > > >> >> *To:* Timothy Mcsweeney < tim@dropnumber.com >; > > >> uri-review@ietf.org > > >> >> *Subject:* Re: [Uri-review] Request for review > > >> >> > > >> >> > > >> >> I don=E2=80=99t understand your question. The URL syntax is fixed= by that RFC. > > >> >> > > >> >> I don=E2=80=99t know what you mean by =E2=80=9Csafe=E2=80=9D or = =E2=80=9Cvalid=E2=80=9D. > > >> >> > > >> >> If by =E2=80=9Cvalid=E2=80=9D you mean =E2=80=9Callowed by RFC 39= 86=E2=80=9D, the answer is that they may only > > >> >> appear in a URL literally > > >> >> > > >> >> if they have the exact meaning in the RFC, otherwise they must be= pct-encoded. > > >> >> > > >> >> *From:*Uri-review < uri-review-bounces@ietf.org > > >> > > >> >> >> > > >> *On Behalf Of *Timothy Mcsweeney > > >> >> *Sent:* Wednesday, May 27, 2020 5:05 PM > > >> >> *To:* uri-review@ietf.org > >> uri-review@ietf.org > > > >> >> *Subject:* Re: [Uri-review] Request for review > > >> >> > > >> >> > > >> >> Hi Dave, > > >> >> > > >> >> > > >> >> If the other six gen-delims from the reserved set were safe and v= alid, would > > >> >> you oppose their use in URIs? > > >> >> > > >> >> > > >> >> Tim > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> On May 24, 2020 at 6:08 PM Dave Thaler < dthaler@microsoft.com > > >> > > >> >> >> = wrote: > > >> >> > > >> >> Hi Tim, > > >> >> > > >> >> Correct the colon is not part of the hier-part, the hier-part is = what > > >> >> comes after the colon. RFC 3986 says: > > >> >> > > >> >> URI =3D scheme ":" hier-part [ "?" query ] [ "#" fragment ] > > >> >> > > >> >> Only strings that conform to the above are URIs. > > >> >> > > >> >> So =E2=80=9Cdrop#sd54g54=E2=80=9D is not a URI because it does no= t conform to the above > > >> >> syntax, as it has no =E2=80=9C:=E2=80=9D > > >> >> > > >> >> =E2=80=9Cdrop:sd54g54=E2=80=9D on the other hand would be a valid= URI. > > >> >> > > >> >> This is what folks are saying when they say if you just change th= e =E2=80=9C#=E2=80=9D to > > >> >> a =E2=80=9C:=E2=80=9D in your draft then it becomes legal. > > >> >> > > >> >> Dave > > >> >> > > >> >> *From:*Uri-review < uri-review-bounces@ietf.org > > >> > > >> >> >> > > >> *On Behalf Of *Timothy Mcsweeney > > >> >> *Sent:* Sunday, May 24, 2020 11:26 AM > > >> >> *To:* Erik Wilde < erik.wilde@dret.net > > >> >>; > > >> >> uri-review@ietf.org > >> uri-review@ietf.org > > > >> >> *Subject:* Re: [Uri-review] Request for review > > >> >> > > >> >> > > >> >> Hi Erik, > > >> >> > > >> >> > > >> >> Thank you, I will have another look at my reference to section 3. > > >> >> > > >> >> Would you agree that in " https://ietf.org > > >> >> < "" rel=3D"noopener" > > >> target=3D"_blank"> "" rel=3D"noopener" target=3D"_blank">https://nam= 06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fietf.org%2F&data= =3D02%7C01%7Cdthaler%40microsoft.com%7Cb115c7f8c70b410eb98308d802a0a8f4%7C7= 2f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637262236339204192&sdata=3DUJ7TQn= KfGZMnWkBKZCVozZQhn%2BGir1saiPQoNGV2C9M%3D&reserved=3D0>" > > >> > > >> >> the colon is not part of the hier-part? > > >> >> > > >> >> On May 24, 2020 at 12:02 PM Erik Wilde < erik.wilde@dret.net > > >> > > >> >> >> wrot= e: > > >> >> > > >> >> > > >> >> > > >> >> hey tim. > > >> >> > > >> >> > > >> >> On 2020-05-24 17:53, Timothy Mcsweeney wrote: > > >> >> > > >> >> Yes, I agree and understand that the same way as you. But when > > >> >> the "#" > > >> >> > > >> >> leaves the client it is not leaving as a fragment, > > >> >> > > >> >> what people are telling you is that "#" and anything following it= never > > >> >> > > >> >> leaves the client, by definition.. > > >> >> > > >> >> > > >> >> it is leaving as a > > >> >> > > >> >> way to separate the URI components, and or for ht= tp it > > >> >> > > >> >> would be separating and . It is this that > > >> >> makes me > > >> >> > > >> >> believe that even if the colon is required for http resolution, i= t is > > >> >> > > >> >> not necessarily required for all URI. > > >> >> > > >> >> this discussion could be more productive if you had a brief look = at the > > >> >> > > >> >> specs you're depending on. the very first rule shown in > > >> >> > > >> >> https://tools.ietf.org/html/rfc3986#section-3 > > >> >> < > > >> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2F= tools.ietf..org%2Fhtml%2Frfc3986%23section-3&data=3D02%7C01%7Cdthaler%40mic= rosoft.com%7Cb115c7f8c70b410eb98308d802a0a8f4%7C72f988bf86f141af91ab2d7cd01= 1db47%7C1%7C0%7C637262236339214150&sdata=3DupZbOkALJ8SuEk%2FpLLqhdDDUNMhdpS= mjWqpMAyITzc8%3D&reserved=3D0> > > >> > > >> >> is > > >> >> > > >> >> > > >> >> URI =3D scheme ":" hier-part [ "?" query ] [ "#" fragment ] > > >> >> > > >> >> > > >> >> each URI is defined like this and must have a colon. > > >> >> > > >> >> > > >> >> cheers, > > >> >> > > >> >> > > >> >> dret. > > >> >> > > >> >> > > >> >> -- > > >> >> > > >> >> erik wilde | mailto: erik.wilde@dret.net > > >> > | > > >> >> > > >> >> | http://dret.net/netdret > > >> >> < > > >> https://nam06.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fd= ret.net%2Fnetdret&data=3D02%7C01%7Cdthaler%40microsoft.com%7Cb115c7f8c70b41= 0eb98308d802a0a8f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63726223633= 9214150&sdata=3Dhq8QVDrXxRmV3iS6DF7R%2FeXFtDKntMcYOHnLSMqx5zo%3D&reserved= =3D0> > > >> > > >> >> | > > >> >> > > >> >> | http://twitter.com/dret > > >> >> < > > >> https://nam06.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Ft= witter.com%2Fdret&data=3D02%7C01%7Cdthaler%40microsoft.com%7Cb115c7f8c70b41= 0eb98308d802a0a8f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63726223633= 9224105&sdata=3D9V5l2cgygLF2GJbT9Eh0ptd2mv4YRbvZm6oaYSrf8fE%3D&reserved=3D0= > > > >> > > >> >> | > > >> >> > > >> >> > > >>> > > >>> _______________________________________________ > > >>> Uri-review mailing list > > >>> Uri-review@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/uri-review From nobody Wed Nov 11 08:24:16 2020 Return-Path: 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 8E4353A0E99 for ; Wed, 11 Nov 2020 08:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 dLaZupTcK7Fi for ; Wed, 11 Nov 2020 08:24:14 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (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 B5ABD3A1059 for ; Wed, 11 Nov 2020 08:24:12 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus002 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MJRQT-1kbWOx3oHz-0035UL; Wed, 11 Nov 2020 17:24:08 +0100 Date: Wed, 11 Nov 2020 11:24:07 -0500 (EST) From: Timothy Mcsweeney To: Michael Wojcik , uri-review@ietf.org Message-ID: <1558704952.11385.1605111847841@email.ionos.com> In-Reply-To: <1759640974.393018.1590850816391@email.ionos.com> 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> <1081815563.141711.1590624311343@email.ionos.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> <1759640974.393018.1590850816391@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:xJu0GMXOtQDm2PPwGhKKVxdi4c6CEsp3ic9fk78O5gkcYIAQK5e mnLRWcnETdycJXrSg/OtPzhH5XH2WCRF6lSLf2kcRUb75QQwxK9eVHNvs0CihvnXLrBB4Ti aZODDA7o/+ay2N6LjSbbbk7btfuupp+9iiKIqQvANmcEVG2QxmDQddwYpoIe8g7vsNahakH arxCKbIQXsA3/8PERHVoA== X-UI-Out-Filterresults: notjunk:1;V03:K0:qe4Qetv+ou4=:9icBn3+sx8ZRlryYt8ue9Q +qZzSwmDu5LmSSnodIrKF3u6W5qx7RWckDEtYBSJ5zRLCbF58ZMaHyiJpaVa8NiMTARejVd1V xzazH/yjSaa+fgolTWB6imqaHGaWlmpC8yqm3rwQBYPhDKPR8Hx8k+tmUYlL0RR8LwxxDzbjS XpiEsRRIXfLYB1w9Q5rxTUxy2X36hYpXTNwvibpXCDdzoI71rNULTl8WsX3QycJkXLWwRdhuM 4YMXxYzU76In2Oq4FSGJAtkADOa3LQbUr8IMYV+F4vlKzpMO4bRGu1f2unliufKwm+WAMU0BN E/w6A3aeSAZ+PCgrE+6iSjYRlCBuwOWGzNdQY5DbIWwWAMY5vrf0LHsI6gCTVfBpeV9J3Btxx CGI3kPU4qCUn5g4RDXJ+kUHpNUmcO0TAHXlczOadyR70wv0/LNnf/2aebNmKvfheKGY2ES5Jv jsS7u03/aw== Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 16:24:16 -0000 text version: Hi Michael, Before I reply to that, I want to be sure you and I are on the same page about how my draft works. Using the browser example, drop#mk34s is queried, reponses given, the browser then goes to http://mk34s.dropexample.com and in the browser address bar it says http://mk34s.dropexample.com. Is that how you understand my draft? Tim > On 05/30/2020 11:00 AM Timothy Mcsweeney wrote: > > > Hi Michael, > > Before I reply to that, I want to be sure you and I are on the same page about > how my draft works. Using the browser example, drop#mk34s is queried, > reponses given, the browser then goes to http://mk34s.dropexample.com > and in the browser address bar it says http://mk34s.dropexample.com. > > Is that how you understand my draft? > > Tim > > > > > > 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 From nobody Wed Nov 11 08:25:04 2020 Return-Path: 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 572603A03FB for ; Wed, 11 Nov 2020 08:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 9uNYsRllpOKx for ; Wed, 11 Nov 2020 08:25:01 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (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 C08573A103F for ; Wed, 11 Nov 2020 08:24:54 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0Lan5K-1jsrwT3qWm-00kQIU for ; Wed, 11 Nov 2020 17:24:53 +0100 Date: Wed, 11 Nov 2020 11:24:53 -0500 (EST) From: Timothy Mcsweeney To: uri-review@ietf.org Message-ID: <1514347463.11429.1605111893633@email.ionos.com> In-Reply-To: <906613693.393411.1590852424418@email.ionos.com> 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> <1081815563.141711.1590624311343@email.ionos.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> <906613693.393411.1590852424418@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:+GTNH5VHYT4ne8ahVg1RyJbrZl936VKPAFLFJRve4blzskDGWjx YGgUPNO6gCpOQGNLr70IEULAYhQhlFHOJXMH0Eg6XPLJTm2mTnwKY+PO6wYq91sjhiWsBlo q6k6Y6/LB0lH4dT1S3aQmFa65VNwb2iG8IU6MvhqFOgeIsgbsm0XTQ+rxxJ0sf2VmrxdHXB l/aTDhm1ro03JIdtJn+1g== X-UI-Out-Filterresults: notjunk:1;V03:K0:UtjVgmcdntM=:Bg3KT10kkpU3tzxrzFmz2X +XP4DZYGbXYoAQ5Vk0WOlGXoJETnXlxDB5xR2+uvCkx8sTqUWKChzTWF0yoLZ5hVAwwrayC+2 fb6ArwAhVlbS+YamGTq1knxjs4f5B66xwRD+rc4bISCVi4gox5hvB2svTCondLNJl8HOz9qGh NCpiaa7LN1aZ3r+h+GHaSDswqTNU0FjoU3UopLmyOPK6ESK/bV0apkrHwznRNcZ9y0w7T9gcf KsLyexxSNvlK/idrdTr3MWICJU3qis8DZH4jdX3ss849Y2ZS3OLqSq5MuZTe5R7BlJrqo6X1j UD2T9R9hVYI/szQSIqrroSUmJ6rMnB8ICbSjbHp22YTLAEaz4ZKQ67iTVr1Efe00u7N+5T3sb 8ArIwKz0va4jpe5tZfo55XqQ/c2aJXJDhrlZnTlDWzKf0A6s0ZGeu9HLWF6pDVktn2KU4/WQI ji6GjJ+LoQ== Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 16:25:02 -0000 text version: Hi Michael, Before I reply to that, I want to be sure you and I are on the same page about how my draft works. Using the browser example, drop#mk34s is queried, reponses given, the browser then goes to and in the browser address bar it says . Is that how you understand my draft? Tim > On 05/30/2020 11:27 AM Timothy Mcsweeney wrote: > > > > Hi Michael, > > Before I reply to that, I want to be sure you and I are on the same page about > how my draft works. Using the browser example, drop#mk34s is queried, > reponses given, the browser then goes to > and in the browser address bar it says . > > Is that how you understand my draft? > > Tim > > > 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 From nobody Wed Nov 11 08:26:03 2020 Return-Path: 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 6CF5D3A0E96 for ; Wed, 11 Nov 2020 08:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 KpKTGwsIRDbe for ; Wed, 11 Nov 2020 08:25:58 -0800 (PST) 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 1F9D23A11EF for ; Wed, 11 Nov 2020 08:25:51 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1Mhkbc-1k8CtQ416u-00dliu; Wed, 11 Nov 2020 17:25:49 +0100 Date: Wed, 11 Nov 2020 11:25:48 -0500 (EST) From: Timothy Mcsweeney To: "Daniel R. Tobias" , uri-review@ietf.org Message-ID: <72333469.11467.1605111948547@email.ionos.com> In-Reply-To: <635829576.405068.1590951735546@email.ionos.com> References: <491516506.246380.1589851279474@email.ionos.com>, <1435838702.391137.1590841215132@email.ionos.com>, <5ED3F66B.7204.10663FF@dan.tobias.name> <635829576.405068.1590951735546@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:wEhdryxBwVTZPnmUS8uvC6s7qKDGqcbAw614M6cv0K2pXp20sIG MSoYQainkNlnWmApUr+/FBx4qIPD8mwH4XE2bbV5TLtnLspcrHBj51+I1OYrOY7UntdLl0H JV+Eu8A/c94C2KBKGwbAQl8VsOc050Y7A/OQF1LTk80urXowQJZIlhUNe9tWhjohptzjnPG 6iWpMb952UkTvGFmAn41w== X-UI-Out-Filterresults: notjunk:1;V03:K0:rL44qUrZxsU=:a9BYPSeB/OjsVR3+CMBmlK dtItB/2u+N+MJJk5uMMxpY9tE0RjBUe6l9L7bdIfCNEoeOw7oo0FJ54ORMSSPC8PX5B6OVvjJ kjB6/NO8u2w96vF8UnmA7OyXnvss5KnhEObDGCZsLpVhxulm9BIHjpxSsL4H9uX9PfoGfusbq qBg4iOigbIAn58qhYcqh5QP1Zlvq6HexmmVIsGn94nbulr66Mzgg375WKCUEvZNH/Plz1rM65 s6INp6EteV7+HKbyUh6DmYfLiGVh7C5qntqlbkc318x2O+L8XbMRFB67ASJiJUeC1zv4GMJoM HKjXAFWPRGCG76cy24RzGwLbnQhdPH9wjn1UAUiNSIW3EABegucgTCwZQUPDmE5aK2qHGc7kj dznA3jLksR+n7+qBhEEWVUbMQcLDl+HLim9478EZbJYKeuTgicUW4q/4rOAl2Y9YZvFJUuXrS V1SzS5tglw== Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 16:26:02 -0000 text version: I am bringing a product to market. In the draft it says dropexample.com and my email, as you know, my is dropnumber.com. So its drop number, not drop colon. Your struggle is over. > On 05/31/2020 3:02 PM Timothy Mcsweeney wrote: > > > I am bringing a product to market. In the draft it says dropexample.com and my email, as you know, my is dropnumber.com. So its drop number, not drop colon. Your struggle is over. > > > > On May 31, 2020 at 2:24 PM "Daniel R. Tobias" < dan@tobias.name> wrote: > > > > > > On 30 May 2020 at 14:01, Michael Wojcik wrote: > > > > > 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? > > I'm struggling to figure out what the guy's true agenda is, too; why > > he's so wedded to the nonstandard syntax he is proposing. Maybe he's > > got an implementation out there somewhere with the quirky syntax > > embedded that he doesn't want to have to change? > > > > -- > > == Dan == > > Dan's Mail Format Site: http://mailformat.dan.info/ > > Dan's Web Tips: http://webtips.dan.info/ > > Dan's Domain Site: http://domains.dan.info/ > > > > > > _______________________________________________ > > Uri-review mailing list > > Uri-review@ietf.org > > https://www.ietf.org/mailman/listinfo/uri-review From nobody Wed Nov 11 08:29:33 2020 Return-Path: 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 CB9203A0930 for ; Wed, 11 Nov 2020 08:29:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 k9YK2kUABVXL for ; Wed, 11 Nov 2020 08:29:31 -0800 (PST) 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 73B403A0855 for ; Wed, 11 Nov 2020 08:29:31 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1N0naj-1kP3Ra42ar-00woe0; Wed, 11 Nov 2020 17:29:28 +0100 Date: Wed, 11 Nov 2020 11:29:27 -0500 (EST) From: Timothy Mcsweeney To: Michael Wojcik , uri-review@ietf.org Message-ID: <1501562967.11637.1605112167450@email.ionos.com> In-Reply-To: <1924775136.405242.1590952556836@email.ionos.com> 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> <1081815563.141711.1590624311343@email.ionos.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> <1924775136.405242.1590952556836@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:izcx4bQc7z0fqvYbSh0kUq/fJLXPC0icqHdCkUtLtsYonp1ZAbi ctLhbI6FlgDwzaXHx81HBCJvO4+vuBsBIOBqwM/U2MCV7J1Kq8vbhMv/yePRTErX8uMTF1m CowdZYUT5WbPR5IOeHNQT9ln8DhTq3eJOFmmMQsj0Htjqll5l/JGu9huc9HeoR+i2P7vHkF hYRl9xpQLRJxlbSNIMuaQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:R2ZUla9ohjI=:2aAHN7CJt/ss9pvTU/0Hbw Q32msKj57R2SqGs/hkEY2HyURFhLGVqcHai0hwETmH33OzTdPpXtcv5CaYltL+eeUpvZKsTsn FvinJnBZxCSxoHc9iXDLsw8T5AactsI/kTibX4pli4zqlUuaC+TKaUXp/CHELg3RuVDLpfDQX gBL1q7LhutFZhKKMyIMdFFAWxbX0VUmgRcrrdgInCRzVf5w8kCOavmmRbd6w1vKQxHq1p0uyr gnTzC40+TT0gq4binrvUxtqh0pMgI1UajKj8v4FWIUoXQAyHHxUtCS78mRFjaS178uU8xxzXA XkifclM/hSwHnYLAknPcyjTdNML9/unx5srPmE3MrrBuJfecAUncWbqt19Yu5qIwWCz6TmZVm TDO1Wm6vok38c8iavtIDz7p9ZgSZlEocbd6nnaE05eaX7rEkiOSYUoF7L6HzQOzDuoLZVwche WHoRzuU98g== Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 16:29:33 -0000 text version >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 05/31/2020 3:15 PM Timothy Mcsweeney wrote: > > > >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 From nobody Wed Nov 11 08:30:23 2020 Return-Path: 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 BF5D93A0855; Wed, 11 Nov 2020 08:30:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 xBbq0rdJcFBK; Wed, 11 Nov 2020 08:30:20 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (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 A88D83A00E0; Wed, 11 Nov 2020 08:30:20 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MXJY3-1kpLl42W05-00WBd3; Wed, 11 Nov 2020 17:30:15 +0100 Date: Wed, 11 Nov 2020 11:30:15 -0500 (EST) From: Timothy Mcsweeney To: Larry Masinter , Michael Wojcik , uri-review@ietf.org Cc: Eliot Lear Message-ID: <254547412.11677.1605112215039@email.ionos.com> In-Reply-To: <1225920323.477357.1590962038349@email.ionos.com> 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> <1081815563.141711.1590624311343@email.ionos.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> <1924775136.405242.159095255 6836@email.ionos.com> <009601d63790$c79a12f0$56ce38d0$@acm.org> <1225920323.477357.1590962038349@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:KlooUjt51G92/VW3U+TO/Wdbs0ABxOi8P3okEcqMs0LKT+Q5XDP U6V7jtWekyECt7Jc+TyjdtOr/I89IQrC+weHGNzx1F31wj5LQSxbAnNTXl6le1PhQKbBawB utCd3bwQ68URSHO4X6HgCo1mUonmwv6gv58WorBUR5PBJsVgny+xP8/yHgRdskepA63265B UZhzBYwnASrOQcUimTVmA== X-UI-Out-Filterresults: notjunk:1;V03:K0:1PewzeJSHac=:SKqqzaGMpuqc3hUg0VakCf 0YGJaz+Ga2GOT3W1qKp/pMzPD5xhxYckCrFH7BmRQGMpOc4OzFNFGEiskg0JaUVZGGZ8OtpQi PGaMNOgMNvMdJMC0AB2GIWPIv9zbyNA3ODc5ilhkc+Njj8A70WKKkZjfR2Mjn7U3L3sbPAQYB 6YCvUtsXczJ1cpkvTDtP8Oi6Z3hbL02jz8UMuBLRYSTrQkEVtO8LRRG09N0HhNl9dOGkxvdqi mKji4SS9dxhOE3AKV3cq+RPbh+6tIXfzirUpDqEoxv1bmlL6obPU8X0jx9mmuqXIGd1wW5Ket rHFDtmOIpC9fOIp9AeEtsEQZjkkofLSU9mJUep4+isxynQVZR4xZHg7aRlAzHjlO3AG45deTM /5cmI4dfrZKbn1SzhFZ0Xfa2Use4ze4EziGOgf2CD2bmvARfvz0q4sWuHujM9crskKN9PgkYL GrbYlhCSVA== Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 16:30:23 -0000 text version: Hi Larry,=20 Just so its crystal clear in my head, you're saying that the original inten= t of 3986 was that the colon, and only the colon, was to be used as the gen-delim bet= ween scheme and path regardless of implementation specific sytanx? I have that = right? > On 05/31/2020 5:53 PM Timothy Mcsweeney wrote: >=20 >=20 > Hi Larry, >=20 > Just so its crystal clear in my head, you're saying that the original int= ent of 3986 > was that the colon, and only the colon, was to be used as the gen-delim b= etween > scheme and path regardless of implementation specific sytanx? I have that= right? > > On May 31, 2020 at 5:16 PM Larry Masinter wrote:=20 > >=20 > >=20 > > * I noticed two of the original authors are on the email list. It wou= ld > > * be nice to hear what the original interpretation was. > >=20 > > I wasn=E2=80=99t going to respond, but if you want my opinion, it=E2=80= =99s that > >=20 > > 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 Regist= ration Procedures for URI schemes to figure out a way to terminate this kin= d of discussion. > >=20 > > I note that this re-(mis-)use of fragment identifier isn=E2=80=99t so d= ifferent from the URN wish to repurpose =E2=80=9C#=E2=80=9D. > > That we never required media type registrations to explain their interp= retation of fragment identifiers. We should. > > I note that for HTTP we can say =E2=80=9Cthe fragment identifier isn=E2= =80=99t sent to the server, only the base full URL=E2=80=9D but that is not= actually required and isn=E2=80=99t true for =E2=80=9Cfile=E2=80=9D URLs s= ince in that case there is no particular =E2=80=9Cserver=E2=80=9D. > > I point out https://developer.mozilla.org/en-US/docs/Web/API/Navigator/= registerProtocolHandler > > TheNavigator (https://developer.mozilla.org/en-US/docs/Web/API/Navigato= r)methodregisterProtocolHandler()lets web sites register their ability to o= pen or handle particular URL schemes (aka protocols). > > For example, this API lets webmail sites open mailto: URLs, or VoIP sit= es open tel: URLs. > > Which allows you to define =E2=80=9Cdrop=E2=80=9D URLs (which of course= start with =E2=80=9Cdrop:=E2=80=9D) > >=20 > >=20 > > From: Uri-review On Behalf OfTimothy Mcsw= eeney > > Sent: Sunday, May 31, 2020 12:16 PM > > To: Michael Wojcik ; uri-review@ietf.org > > Subject: Re: [Uri-review] Request for review > >=20 > > >The issue here is that you're misinterpreting RFC 3986. > >=20 > > I noticed two of the original authors are on the email list. It would > > be nice to hear what the original interpretation was. > >=20 > > >To be honest, I don't understand why you're being so difficult about t= his. > >=20 > > Having a different perspective is no being difficult. > > Imagine the first color blind person telling everyone the grass is dark= gray. > >=20 > >=20 > >=20 > >=20 > > > On May 30, 2020 at 10:01 AM Michael Wojcik < Michael.Wojcik@microfocu= s.com> wrote: > > >=20 > > >=20 > > > > 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 misinterpret= ing RFC 3986. > > >=20 > > > 3986 section 3 is not ambiguous. The first production is: > > >=20 > > > URI =3D scheme ":" hier-part [ "?" query ] [ "#" fragment ] > > >=20 > > > The colon is explicit and not optional. A minimal URI consists of a s= cheme, a colon, and a hier-part. There's no wiggle room there, and no amoun= t of casuistry regarding other parts of 3986 will change that. > > >=20 > > > Someone could also point to 1.2.3, where the language clearly notes t= hat the colon is the scheme delimiter; or 3.5, which makes it clear that th= e hash symbol is always the fragment delimiter. But those arguments are red= undant in light of the generic-URI top-level production that begins section= 3. > > >=20 > > > 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? > > >=20 > > > -- > > > Michael Wojcik >=20 > From nobody Wed Nov 11 08:32:20 2020 Return-Path: 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 406C13A0855; Wed, 11 Nov 2020 08:32:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 FcTwP5ZAFB9x; Wed, 11 Nov 2020 08:32:16 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (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 546A63A0930; Wed, 11 Nov 2020 08:32:13 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0Lmae5-1k4eQ30FgR-00aHwj; Wed, 11 Nov 2020 17:32:12 +0100 Date: Wed, 11 Nov 2020 11:32:11 -0500 (EST) From: Timothy Mcsweeney To: Thomas Fruin , uri-review@ietf.org Message-ID: <1317191741.11765.1605112331730@email.ionos.com> In-Reply-To: <2114262334.127635.1591301624060@email.ionos.com> 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> <1081815563.141711.1590624311343@email.ionos.com> <117630321.142251.1590627970509@email.ionos.com> <8ae1641a-74c8-6c2d-7092-6cf53e745fb7@ninebynine.org> <797476254.282655.1590770737009@email.ionos.com> <1729337515.289325.1590778487527@email.ionos.com> <4CEF6E3B-6116-4CDB-B660-16554A9638B5@mac.com> <2114262334.127635.1591301624060@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:qY/QD1jB/upUzt8GKNRD35xoLj9b8GrnFLplYPOc882+ReRobGs i7lZHbH+pQVK5dQhhAJyPHtzrm5JG/lNptY9Rh8+Cq6fiyEK8ACO0h+m7Ei+9dBhRwTggHi XvRTKvIhNdYNn+mMvllOycl/me8Kv90aeP5I3Z5gGQkPYJ2N4OJgAFitRPElTxLzBfjk6nX IdlLb8gKILlfSgYjDmHig== X-UI-Out-Filterresults: notjunk:1;V03:K0:d6R4N53fkHg=:OJYBpFtogy4MN8eX1+7u4W VFAYvG3k+a7Z5n4ivlf+dGm4UWyhTxxjtpCZIAnQyv+G2rJfRXxi8T2Q4SBXKg9lz+iQ8JEtl 843yTpeIdmERBHYEIJ96UMi5+wfqWEDIWV3oAvxyXBIXndCRdNIiuh2Ep6YcTnwvzgxt0JWwT 2Q4riDRj33Ginj4UeZNQXKQS9wWqyinNB9TjcAUH5Svf9qVOxVm88HVa1hrgwXOo2WKRZodXD GJMzQnBSIC7/HR1slQi/U8GDKMcsSV3UBmcG5eehJgYNGwC4tfLw4VCWopGmRDWlKyD/IQmqa qpW3Yoh3NymQ7sRIu43cl0dZ1qeZRge1Js/8Gqc2vkBMETRD9C5SeYAYQ5Nyx0W6GF0mSDebx 7QAG5xzI2FP4Cefz9/BgT1sorubCsVLxpC38uzb8veX2y7ugFkhghfA7k02pRsun+OQhNYVUR cTrbn7xUkA== Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 16:32:19 -0000 text version: Ok thank you Thomas, I will have another look at the RFCs. > On 06/04/2020 4:13 PM Timothy Mcsweeney wrote: >=20 >=20 > Ok thank you Thomas, I will have another look at the RFCs. > > On May 29, 2020 at 7:01 PM Thomas Fruin wrote:=20 > >=20 > > The usefulness of this mailing list is clear, when needing the help of = the community in difficult or ambiguous situations that are not covered in = the RFCs. > >=20 > > For these recently posted, very simple and unambiguous questions, may I= kindly suggest reading the RFCs, because that is what they are for.=20 > >=20 > >=20 > >=20 > > >> For a URI parser, the method used to identify the scheme within any = example is basically: "it's the bit to the left of the colon". > > > Is it basically this, or exactly this? > >=20 > > >> The colon is the "end of label" marker, and that's why folks are ins= isting on it here; without it, you can't use the URI API to select a branch > > > Is the colon the only "end of label" marker? > >=20 > > Thomas Fruin > >=20 > >=20 > > > On May 29, 2020 at 2:22 PM Ted Hardie < ted.ietf@gmail.com> wrote:=20 > > >=20 > > >=20 > > > Hi Tim, > > >=20 > > > Thanks for sharing your thoughts on this. Let me suggest a slightly d= ifferent formulation, which is not based on the colon itself, but on the sc= heme.=20 > > >=20 > > > The scheme indicates which type of URI a particular example is and th= us governs a bunch of the behavior you describe below (whether it is used t= o dereference resources and, if so, what protocol(s) are used, if there are= specific parameters and, if so, whether any are mandatory, and so on).. Fo= r a URI parser, the method used to identify the scheme within any example i= s basically: "it's the bit to the left of the colon". If you don't have tha= t specific marker, then a standard URI parser won't find a scheme and thus = won't know what behavior to match to the example.=20 > > >=20 > > > A common early metaphor for this was to identify the network retrieva= l protocols as different parts of the plumbing of the Web, with the scheme = names as the labels on the taps. That plumbing metaphor doesn't really work= with abstract identifiers and is stretched by schemes like HTTPS which mig= ht have more than one set of underlying protocols. But the labeling still d= oes--you can think of the schemes and the labels that tell the API which br= anch of behavior to invoke. The colon is the "end of label" marker, and tha= t's why folks are insisting on it here; without it, you can't use the URI A= PI to select a branch.=20 > > >=20 > > > best regards, > > >=20 > > > Ted=20 > > >=20 > > >=20 > > >=20 > > > On Fri, May 29, 2020 at 9:46 AM Timothy Mcsweeney < tim@dropnumber.co= m> wrote:=20 > > > > Hi Graham, > > > >=20 > > > > I would never treat suggestions from this list as arbitrary, quite = the contrary.=20 > > > > I want to change the format of this reply just for a minute to expr= ess my deductions. > > > >=20 > > > > This is an excerpt from the conversation in my head: > > > >=20 > > > >=20 > > > > If you take away all the components and subcomponents of a URI, wha= t's leftover?=20 > > > > The colon.=20 > > > > And what governs the colon?=20 > > > > The dereferencing algorithm.=20 > > > > Does http use a colon in its dereferencing?=20 > > > > It does.=20 > > > > What about a URN?=20 > > > > It does.=20 > > > > FTP and Mailto?=20 > > > > Yup the same.=20 > > > > So If you change the colon to a number sign would you get them same= output?=20 > > > > Yes.=20 > > > > All of them?=20 > > > > Yes.=20 > > > > Can you prove it?=20 > > > > Yes.=20 > > > > Why do all the delimiters have quotes around them?=20 > > > > Because they are interchangeable.=20 > > > > Interchangeable everywhere?=20 > > > > No, just within the scope of their placement. That's why URNs can u= se a bunch of colons and not interfere with the first colon after the URN s= cheme name.=20 > > > > But it says the colon is required doesn't it?=20 > > > > I can not pinpoint the sentence that says that.=20 > > > > But section 3, the colon is in the generic syntax, you can see that= right?=20 > > > > Yes but the title of section 3 is "Syntax Components" and the colon= is not a component.=20 > > > > Wait, what does generic mean?=20 > > > > Not specific.=20 > > > > So the generic syntax is not specific?=20 > > > > That's right.=20 > > > > So [RFC3986] is a specification that is defining something that is = not specific?=20 > > > > Yup, says it right there in the abstract. > > > >=20 > > > > From here my mental conversation took a left turn. But I wanted to = put this out here so that the members of this list didn't think my intent w= as for purely self interest reasons but that we can all use what's here. > > > >=20 > > > > Tim > > > >=20 > > > > > On May 29, 2020 at 6:01 AM Graham Klyne < gk@ninebynine.org> wrot= e: > > > > >=20 > > > > >=20 > > > > > Hmmm... I find that bit of RFC3986 isn't immeditely clear. But on= closer study, > > > > > I think it's simply saying that the characters are "safe" in the = sense that > > > > > they are protected from change by URI normalization, hence that w= hen used as > > > > > delimiters there is no risk that the interpretation of the URI is= affected by > > > > > URI normalization (see also section 6 of RFC 3986). > > > > >=20 > > > > > But some of these reserved characters already have defined purpos= es in URI > > > > > structure, and any scheme-dependent use needs to take care not to= interfere with > > > > > such use. For example, using "#" as a delimiter within a URI path= would > > > > > interfere with it's already-defined purpose to delimit a fragment= . > > > > >=20 > > > > > Also, current URI structure *requires* that the ":" is used to de= limit the > > > > > scheme name from the rest of the URI. Suggestions by others on th= is list to use > > > > > ":" rather than "#" are not entirely arbitrary. > > > > >=20 > > > > > As a rule of thumb, I would suggest that if you do need scheme-sp= ecific > > > > > delimiters (and it's not clear to me that you do), then using one= from the > > > > > "sub-delims" set is more likely to avoid conflicts with generic U= RI syntax and > > > > > interpretation. > > > > >=20 > > > > > #g > > > > > -- > > > > >=20 > > > > >=20 > > > > > On 28/05/2020 02:06, Timothy Mcsweeney wrote: > > > > > > Hi Dave, > > > > > >=20 > > > > > > By "safe" I meant like "..... > > > > > >=20 > > > > > > safe to be > > > > > > used by scheme-specific and producer-specific algorithms for > > > > > > delimiting data subcomponents within a URI" > > > > > >=20 > > > > > > Like it says in section 2.2 of RFC3986. > > > > > >=20 > > > > > > Tim > > > > > >=20 > > > > > > > On May 27, 2020 at 8:48 PM Dave Thaler < dthaler@microsoft.co= m> wrote: > > > > > >> s/URL/URI/ in both cases in my response J > > > > > >> > > > > > >> *From:*Uri-review < uri-review-bounces@ietf.org> *On Behalf Of= *Dave Thaler > > > > > >> *Sent:* Wednesday, May 27, 2020 5:47 PM > > > > > >> *To:* Timothy Mcsweeney < tim@dropnumber.com>; uri-review@ietf= .org > > > > > >> *Subject:* Re: [Uri-review] Request for review > > > > > >> > > > > > >> > > > > > >> I don=E2=80=99t understand your question. The URL syntax is fi= xed by that RFC. > > > > > >> > > > > > >> I don=E2=80=99t know what you mean by =E2=80=9Csafe=E2=80=9D o= r =E2=80=9Cvalid=E2=80=9D. > > > > > >> > > > > > >> If by =E2=80=9Cvalid=E2=80=9D you mean =E2=80=9Callowed by RFC= 3986=E2=80=9D, the answer is that they may only > > > > > >> appear in a URL literally > > > > > >> > > > > > >> if they have the exact meaning in the RFC, otherwise they must= be pct-encoded. > > > > > >> > > > > > >> *From:*Uri-review < uri-review-bounces@ietf.org > > > > > >> > *On Behalf Of *Timothy = Mcsweeney > > > > > >> *Sent:* Wednesday, May 27, 2020 5:05 PM > > > > > >> *To:* uri-review@ietf.org > > > > > >> *Subject:* Re: [Uri-review] Request for review > > > > > >> > > > > > >> > > > > > >> Hi Dave, > > > > > >> > > > > > >> > > > > > >> If the other six gen-delims from the reserved set were safe an= d valid, would > > > > > >> you oppose their use in URIs? > > > > > >> > > > > > >> > > > > > >> Tim > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> On May 24, 2020 at 6:08 PM Dave Thaler < dthaler@microsoft.com > > > > > >> > wrote: > > > > > >> > > > > > >> Hi Tim, > > > > > >> > > > > > >> Correct the colon is not part of the hier-part, the hier-part = is what > > > > > >> comes after the colon. RFC 3986 says: > > > > > >> > > > > > >> URI =3D scheme ":" hier-part [ "?" query ] [ "#" fragment ] > > > > > >> > > > > > >> Only strings that conform to the above are URIs. > > > > > >> > > > > > >> So =E2=80=9Cdrop#sd54g54=E2=80=9D is not a URI because it does= not conform to the above > > > > > >> syntax, as it has no =E2=80=9C:=E2=80=9D > > > > > >> > > > > > >> =E2=80=9Cdrop:sd54g54=E2=80=9D on the other hand would be a va= lid URI. > > > > > >> > > > > > >> This is what folks are saying when they say if you just change= the =E2=80=9C#=E2=80=9D to > > > > > >> a =E2=80=9C:=E2=80=9D in your draft then it becomes legal. > > > > > >> > > > > > >> Dave > > > > > >> > > > > > >> *From:*Uri-review < uri-review-bounces@ietf.org > > > > > >> > *On Behalf Of *Timothy = Mcsweeney > > > > > >> *Sent:* Sunday, May 24, 2020 11:26 AM > > > > > >> *To:* Erik Wilde < erik.wilde@dret.net >; > > > > > >> uri-review@ietf.org > > > > > >> *Subject:* Re: [Uri-review] Request for review > > > > > >> > > > > > >> > > > > > >> Hi Erik, > > > > > >> > > > > > >> > > > > > >> Thank you, I will have another look at my reference to section= 3. > > > > > >> > > > > > >> Would you agree that in " https://ietf.org (https://ietf.org/) > > > > > >> < "" rel=3D"noopener" target=3D"_blank">https://nam06.safelink= s..protection.outlook.com/?url=3Dhttps%3A%2F%2Fietf.org%2F&data=3D02%7C01%7= Cdthaler%40microsoft.com%7Cb115c7f8c70b410eb98308d802a0a8f4%7C72f988bf86f14= 1af91ab2d7cd011db47%7C1%7C0%7C637262236339204192&sdata=3DUJ7TQnKfGZMnWkBKZC= VozZQhn%2BGir1saiPQoNGV2C9M%3D&reserved=3D0>" > > > > > >> the colon is not part of the hier-part? > > > > > >> > > > > > >> On May 24, 2020 at 12:02 PM Erik Wilde < erik.wilde@dret.net > > > > > >> > wrote: > > > > > >> > > > > > >> > > > > > >> > > > > > >> hey tim. > > > > > >> > > > > > >> > > > > > >> On 2020-05-24 17:53, Timothy Mcsweeney wrote: > > > > > >> > > > > > >> Yes, I agree and understand that the same way as you. But when > > > > > >> the "#" > > > > > >> > > > > > >> leaves the client it is not leaving as a fragment, > > > > > >> > > > > > >> what people are telling you is that "#" and anything following= it never > > > > > >> > > > > > >> leaves the client, by definition.. > > > > > >> > > > > > >> > > > > > >> it is leaving as a > > > > > >> > > > > > >> way to separate the URI components, and or for= http it > > > > > >> > > > > > >> would be separating and . It is this that > > > > > >> makes me > > > > > >> > > > > > >> believe that even if the colon is required for http resolution= , it is > > > > > >> > > > > > >> not necessarily required for all URI. > > > > > >> > > > > > >> this discussion could be more productive if you had a brief lo= ok at the > > > > > >> > > > > > >> specs you're depending on. the very first rule shown in > > > > > >> > > > > > >> https://tools.ietf.org/html/rfc3986#section-3 > > > > > >> < https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%= 3A%2F%2Ftools.ietf..org%2Fhtml%2Frfc3986%23section-3&data=3D02%7C01%7Cdthal= er%40microsoft.com%7Cb115c7f8c70b410eb98308d802a0a8f4%7C72f988bf86f141af91a= b2d7cd011db47%7C1%7C0%7C637262236339214150&sdata=3DupZbOkALJ8SuEk%2FpLLqhdD= DUNMhdpSmjWqpMAyITzc8%3D&reserved=3D0 (https://nam06.safelinks.protection.o= utlook..com/?url=3Dhttps%3A%2F%2Ftools.ietf..org%2Fhtml%2Frfc3986%23section= -3&data=3D02%7C01%7Cdthaler%40microsoft.com%7Cb115c7f8c70b410eb98308d802a0a= 8f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637262236339214150&sdata= =3DupZbOkALJ8SuEk%2FpLLqhdDDUNMhdpSmjWqpMAyITzc8%3D&reserved=3D0)> > > > > > >> is > > > > > >> > > > > > >> > > > > > >> URI =3D scheme ":" hier-part [ "?" query ] [ "#" fragment ] > > > > > >> > > > > > >> > > > > > >> each URI is defined like this and must have a colon. > > > > > >> > > > > > >> > > > > > >> cheers, > > > > > >> > > > > > >> > > > > > >> dret. > > > > > >> > > > > > >> > > > > > >> -- > > > > > >> > > > > > >> erik wilde | mailto: erik.wilde@dret.net | > > > > > >> > > > > > >> | http://dret.net/netdret > > > > > >> < https://nam06.safelinks.protection.outlook.com/?url=3Dhttp%3= A%2F%2Fdret.net%2Fnetdret&data=3D02%7C01%7Cdthaler%40microsoft.com%7Cb115c7= f8c70b410eb98308d802a0a8f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637= 262236339214150&sdata=3Dhq8QVDrXxRmV3iS6DF7R%2FeXFtDKntMcYOHnLSMqx5zo%3D&re= served=3D0 (https://nam06.safelinks.protection.outlook..com/?url=3Dhttp%3A%= 2F%2Fdret.net%2Fnetdret&data=3D02%7C01%7Cdthaler%40microsoft.com%7Cb115c7f8= c70b410eb98308d802a0a8f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63726= 2236339214150&sdata=3Dhq8QVDrXxRmV3iS6DF7R%2FeXFtDKntMcYOHnLSMqx5zo%3D&rese= rved=3D0)> > > > > > >> | > > > > > >> > > > > > >> | http://twitter.com/dret > > > > > >> < https://nam06..safelinks.protection.outlook.com/?url=3Dhttp%= 3A%2F%2Ftwitter.com%2Fdret&data=3D02%7C01%7Cdthaler%40microsoft.com%7Cb115c= 7f8c70b410eb98308d802a0a8f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63= 7262236339224105&sdata=3D9V5l2cgygLF2GJbT9Eh0ptd2mv4YRbvZm6oaYSrf8fE%3D&res= erved=3D0 (https://nam06.safelinks.protection.outlook..com/?url=3Dhttp%3A%2= F%2Ftwitter.com%2Fdret&data=3D02%7C01%7Cdthaler%40microsoft.com%7Cb115c7f8c= 70b410eb98308d802a0a8f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637262= 236339224105&sdata=3D9V5l2cgygLF2GJbT9Eh0ptd2mv4YRbvZm6oaYSrf8fE%3D&reserve= d=3D0)> > > > > > >> | > > > > > >> > > > > > >> > > > > > >=20 > > > > > > _______________________________________________ > > > > > > Uri-review mailing list > > > > > > Uri-review@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/uri-review > > > > _______________________________________________=20 > > > > Uri-review mailing list=20 > > > > Uri-review@ietf.org=20 > > > > https://www.ietf.org/mailman/listinfo/uri-review=20 > >=20 > >=20 > > _______________________________________________=20 > > Uri-review mailing list=20 > > Uri-review@ietf.org=20 > > https://www.ietf.org/mailman/listinfo/uri-review=20 > >=20 > > _______________________________________________ Uri-review mailing list= Uri-review@ietf.org https://www.ietf.org/mailman/listinfo/uri-review >=20 > From nobody Wed Nov 11 08:33:14 2020 Return-Path: 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 3D27B3A1008 for ; Wed, 11 Nov 2020 08:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 TjDBpYQFblND for ; Wed, 11 Nov 2020 08:33:07 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (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 040393A1278 for ; Wed, 11 Nov 2020 08:32:58 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0Lmae5-1k4eQj0gmx-00aIB9 for ; Wed, 11 Nov 2020 17:32:58 +0100 Date: Wed, 11 Nov 2020 11:32:57 -0500 (EST) From: Timothy Mcsweeney To: uri-review@ietf.org Message-ID: <568680860.11783.1605112377874@email.ionos.com> In-Reply-To: <1192631250.937545.1592251697716@email.ionos.com> 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> <1081815563.141711.1590624311343@email.ionos.com> <117630321.142251.1590627970509@email.ionos.com> <8ae1641a-74c8-6c2d-7092-6cf53e745fb7@ninebynine.org> <797476254.282655.1590770737009@email.ionos.com> <1729337515.289325.1590778487527@email.ionos.com> <4CEF6E3B-6116-4CDB-B660-16554A9638B5@mac.com> <1192631250.937545.1592251697716@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:OgxH+oeksEbtbNRsIoywZwu7UZOkpoNDueIHkgbk5x3ImNKKhM3 KRmycSdVKddU5JxmRFkdU5XgoOhtmF3qW7+inle1W9PmqZntJhyCkBMvTypfhAcq/dhV08y TOhIr7bZSrPBln8fTmHYn+VoltnOPWXhpfSgelL5KkRK+I6jrAY5WIX1i8w0GNaFvogoERF pER3R7G1KdjrZOuxUG1hA== X-UI-Out-Filterresults: notjunk:1;V03:K0:P81qqxPKfKI=:Xil8hNQegsP3DVoTz1Urro EuvKtCNivqNz5sapj+2+LHgO4iECyxRVCxkReOiwnwvZy96B++Y8KymR+o1uciv7R5JQC6DH6 FXD9cd5JRH9qCipX3NExGZdJDA86uQIk+p+WNlgN2CxHogvOO6txDBfwIuW079vdOF07Gy3uF FQbkfer5Hh+QqOMS0mVaOk0iHjtVtfyPfye8wklsL9oDNoc+Zot6gIY06UIGAvcnSfU+9OAkG srlhxK4uVtk1PcbPUQae8+QcZOeHDY4dWW3Kl8znumui+gAuU2LmOWP1L/FVwHzzVOlzGRJVi sb98UCIUKMOh+ydqQuApoW49aaIAKk9zzjjiJaz87EGzPt2Ujr0nhzcirWgtpbfWIffc0fu9N WESfjip7fEh7O3oRUmMi6ANt94J6eN/Hfxqay022HuAGugXeQw040dUeaWCq1+gPH6vNS5g96 L4t8ZoiSbQ== Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 16:33:13 -0000 text version: Hello, I have given things a lot of thought over the last two weeks and I have a q= uestion for the group. Lets say, even with the objections on the number si= gn, what harm can come from trying it? >From what I gather from the feedback, the parsers wont parse it correctly. = Is that so bad? I mean, if my idea only work sometimes, or somewheres, is= that bad for everyone, or just bad for me? > On 06/15/2020 4:08 PM Timothy Mcsweeney wrote: >=20 >=20 > Hello, >=20 > I have given things a lot of thought over the last two weeks and I have a= question for the group. Lets say, even with the objections on the number s= ign, what harm can come from trying it? >=20 > From what I gather from the feedback, the parsers wont parse it correctly= . Is that so bad? I mean, if my idea only work sometimes, or somewheres, is= that bad for everyone, or just bad for me? >=20 >=20 > > On May 29, 2020 at 7:01 PM Thomas Fruin wrote:=20 > >=20 > > The usefulness of this mailing list is clear, when needing the help of = the community in difficult or ambiguous situations that are not covered in = the RFCs. > >=20 > > For these recently posted, very simple and unambiguous questions, may I= kindly suggest reading the RFCs, because that is what they are for.=20 > >=20 > >=20 > >=20 > > >> For a URI parser, the method used to identify the scheme within any = example is basically: "it's the bit to the left of the colon". > > > Is it basically this, or exactly this? > >=20 > > >> The colon is the "end of label" marker, and that's why folks are ins= isting on it here; without it, you can't use the URI API to select a branch > > > Is the colon the only "end of label" marker? > >=20 > > Thomas Fruin > >=20 > >=20 > > > On May 29, 2020 at 2:22 PM Ted Hardie < ted.ietf@gmail.com> wrote:=20 > > >=20 > > >=20 > > > Hi Tim, > > >=20 > > > Thanks for sharing your thoughts on this. Let me suggest a slightly d= ifferent formulation, which is not based on the colon itself, but on the sc= heme.=20 > > >=20 > > > The scheme indicates which type of URI a particular example is and th= us governs a bunch of the behavior you describe below (whether it is used t= o dereference resources and, if so, what protocol(s) are used, if there are= specific parameters and, if so, whether any are mandatory, and so on).. Fo= r a URI parser, the method used to identify the scheme within any example i= s basically: "it's the bit to the left of the colon". If you don't have tha= t specific marker, then a standard URI parser won't find a scheme and thus = won't know what behavior to match to the example.=20 > > >=20 > > > A common early metaphor for this was to identify the network retrieva= l protocols as different parts of the plumbing of the Web, with the scheme = names as the labels on the taps. That plumbing metaphor doesn't really work= with abstract identifiers and is stretched by schemes like HTTPS which mig= ht have more than one set of underlying protocols. But the labeling still d= oes--you can think of the schemes and the labels that tell the API which br= anch of behavior to invoke. The colon is the "end of label" marker, and tha= t's why folks are insisting on it here; without it, you can't use the URI A= PI to select a branch.=20 > > >=20 > > > best regards, > > >=20 > > > Ted=20 > > >=20 > > >=20 > > >=20 > > > On Fri, May 29, 2020 at 9:46 AM Timothy Mcsweeney < tim@dropnumber.co= m> wrote:=20 > > > > Hi Graham, > > > >=20 > > > > I would never treat suggestions from this list as arbitrary, quite = the contrary.=20 > > > > I want to change the format of this reply just for a minute to expr= ess my deductions. > > > >=20 > > > > This is an excerpt from the conversation in my head: > > > >=20 > > > >=20 > > > > If you take away all the components and subcomponents of a URI, wha= t's leftover?=20 > > > > The colon.=20 > > > > And what governs the colon?=20 > > > > The dereferencing algorithm.=20 > > > > Does http use a colon in its dereferencing?=20 > > > > It does.=20 > > > > What about a URN?=20 > > > > It does.=20 > > > > FTP and Mailto?=20 > > > > Yup the same.=20 > > > > So If you change the colon to a number sign would you get them same= output?=20 > > > > Yes.=20 > > > > All of them?=20 > > > > Yes.=20 > > > > Can you prove it?=20 > > > > Yes.=20 > > > > Why do all the delimiters have quotes around them?=20 > > > > Because they are interchangeable.=20 > > > > Interchangeable everywhere?=20 > > > > No, just within the scope of their placement. That's why URNs can u= se a bunch of colons and not interfere with the first colon after the URN s= cheme name.=20 > > > > But it says the colon is required doesn't it?=20 > > > > I can not pinpoint the sentence that says that.=20 > > > > But section 3, the colon is in the generic syntax, you can see that= right?=20 > > > > Yes but the title of section 3 is "Syntax Components" and the colon= is not a component.=20 > > > > Wait, what does generic mean?=20 > > > > Not specific.=20 > > > > So the generic syntax is not specific?=20 > > > > That's right.=20 > > > > So [RFC3986] is a specification that is defining something that is = not specific?=20 > > > > Yup, says it right there in the abstract. > > > >=20 > > > > From here my mental conversation took a left turn. But I wanted to = put this out here so that the members of this list didn't think my intent w= as for purely self interest reasons but that we can all use what's here. > > > >=20 > > > > Tim > > > >=20 > > > > > On May 29, 2020 at 6:01 AM Graham Klyne < gk@ninebynine.org> wrot= e: > > > > >=20 > > > > >=20 > > > > > Hmmm... I find that bit of RFC3986 isn't immeditely clear. But on= closer study, > > > > > I think it's simply saying that the characters are "safe" in the = sense that > > > > > they are protected from change by URI normalization, hence that w= hen used as > > > > > delimiters there is no risk that the interpretation of the URI is= affected by > > > > > URI normalization (see also section 6 of RFC 3986). > > > > >=20 > > > > > But some of these reserved characters already have defined purpos= es in URI > > > > > structure, and any scheme-dependent use needs to take care not to= interfere with > > > > > such use. For example, using "#" as a delimiter within a URI path= would > > > > > interfere with it's already-defined purpose to delimit a fragment= . > > > > >=20 > > > > > Also, current URI structure *requires* that the ":" is used to de= limit the > > > > > scheme name from the rest of the URI. Suggestions by others on th= is list to use > > > > > ":" rather than "#" are not entirely arbitrary. > > > > >=20 > > > > > As a rule of thumb, I would suggest that if you do need scheme-sp= ecific > > > > > delimiters (and it's not clear to me that you do), then using one= from the > > > > > "sub-delims" set is more likely to avoid conflicts with generic U= RI syntax and > > > > > interpretation. > > > > >=20 > > > > > #g > > > > > -- > > > > >=20 > > > > >=20 > > > > > On 28/05/2020 02:06, Timothy Mcsweeney wrote: > > > > > > Hi Dave, > > > > > >=20 > > > > > > By "safe" I meant like "..... > > > > > >=20 > > > > > > safe to be > > > > > > used by scheme-specific and producer-specific algorithms for > > > > > > delimiting data subcomponents within a URI" > > > > > >=20 > > > > > > Like it says in section 2.2 of RFC3986. > > > > > >=20 > > > > > > Tim > > > > > >=20 > > > > > > > On May 27, 2020 at 8:48 PM Dave Thaler < dthaler@microsoft.co= m> wrote: > > > > > >> s/URL/URI/ in both cases in my response J > > > > > >> > > > > > >> *From:*Uri-review < uri-review-bounces@ietf.org> *On Behalf Of= *Dave Thaler > > > > > >> *Sent:* Wednesday, May 27, 2020 5:47 PM > > > > > >> *To:* Timothy Mcsweeney < tim@dropnumber.com>; uri-review@ietf= .org > > > > > >> *Subject:* Re: [Uri-review] Request for review > > > > > >> > > > > > >> > > > > > >> I don=E2=80=99t understand your question. The URL syntax is fi= xed by that RFC. > > > > > >> > > > > > >> I don=E2=80=99t know what you mean by =E2=80=9Csafe=E2=80=9D o= r =E2=80=9Cvalid=E2=80=9D. > > > > > >> > > > > > >> If by =E2=80=9Cvalid=E2=80=9D you mean =E2=80=9Callowed by RFC= 3986=E2=80=9D, the answer is that they may only > > > > > >> appear in a URL literally > > > > > >> > > > > > >> if they have the exact meaning in the RFC, otherwise they must= be pct-encoded. > > > > > >> > > > > > >> *From:*Uri-review < uri-review-bounces@ietf.org > > > > > >> > *On Behalf Of *Timothy = Mcsweeney > > > > > >> *Sent:* Wednesday, May 27, 2020 5:05 PM > > > > > >> *To:* uri-review@ietf.org > > > > > >> *Subject:* Re: [Uri-review] Request for review > > > > > >> > > > > > >> > > > > > >> Hi Dave, > > > > > >> > > > > > >> > > > > > >> If the other six gen-delims from the reserved set were safe an= d valid, would > > > > > >> you oppose their use in URIs? > > > > > >> > > > > > >> > > > > > >> Tim > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> On May 24, 2020 at 6:08 PM Dave Thaler < dthaler@microsoft.com > > > > > >> > wrote: > > > > > >> > > > > > >> Hi Tim, > > > > > >> > > > > > >> Correct the colon is not part of the hier-part, the hier-part = is what > > > > > >> comes after the colon. RFC 3986 says: > > > > > >> > > > > > >> URI =3D scheme ":" hier-part [ "?" query ] [ "#" fragment ] > > > > > >> > > > > > >> Only strings that conform to the above are URIs. > > > > > >> > > > > > >> So =E2=80=9Cdrop#sd54g54=E2=80=9D is not a URI because it does= not conform to the above > > > > > >> syntax, as it has no =E2=80=9C:=E2=80=9D > > > > > >> > > > > > >> =E2=80=9Cdrop:sd54g54=E2=80=9D on the other hand would be a va= lid URI. > > > > > >> > > > > > >> This is what folks are saying when they say if you just change= the =E2=80=9C#=E2=80=9D to > > > > > >> a =E2=80=9C:=E2=80=9D in your draft then it becomes legal. > > > > > >> > > > > > >> Dave > > > > > >> > > > > > >> *From:*Uri-review < uri-review-bounces@ietf.org > > > > > >> > *On Behalf Of *Timothy = Mcsweeney > > > > > >> *Sent:* Sunday, May 24, 2020 11:26 AM > > > > > >> *To:* Erik Wilde < erik.wilde@dret.net >; > > > > > >> uri-review@ietf.org > > > > > >> *Subject:* Re: [Uri-review] Request for review > > > > > >> > > > > > >> > > > > > >> Hi Erik, > > > > > >> > > > > > >> > > > > > >> Thank you, I will have another look at my reference to section= 3. > > > > > >> > > > > > >> Would you agree that in " https://ietf.org (https://ietf.org/) > > > > > >> < "" rel=3D"noopener" target=3D"_blank">https://nam06.safelink= s..protection.outlook.com/?url=3Dhttps%3A%2F%2Fietf.org%2F&data=3D02%7C01%7= Cdthaler%40microsoft.com%7Cb115c7f8c70b410eb98308d802a0a8f4%7C72f988bf86f14= 1af91ab2d7cd011db47%7C1%7C0%7C637262236339204192&sdata=3DUJ7TQnKfGZMnWkBKZC= VozZQhn%2BGir1saiPQoNGV2C9M%3D&reserved=3D0>" > > > > > >> the colon is not part of the hier-part? > > > > > >> > > > > > >> On May 24, 2020 at 12:02 PM Erik Wilde < erik.wilde@dret.net > > > > > >> > wrote: > > > > > >> > > > > > >> > > > > > >> > > > > > >> hey tim. > > > > > >> > > > > > >> > > > > > >> On 2020-05-24 17:53, Timothy Mcsweeney wrote: > > > > > >> > > > > > >> Yes, I agree and understand that the same way as you. But when > > > > > >> the "#" > > > > > >> > > > > > >> leaves the client it is not leaving as a fragment, > > > > > >> > > > > > >> what people are telling you is that "#" and anything following= it never > > > > > >> > > > > > >> leaves the client, by definition.. > > > > > >> > > > > > >> > > > > > >> it is leaving as a > > > > > >> > > > > > >> way to separate the URI components, and or for= http it > > > > > >> > > > > > >> would be separating and . It is this that > > > > > >> makes me > > > > > >> > > > > > >> believe that even if the colon is required for http resolution= , it is > > > > > >> > > > > > >> not necessarily required for all URI. > > > > > >> > > > > > >> this discussion could be more productive if you had a brief lo= ok at the > > > > > >> > > > > > >> specs you're depending on. the very first rule shown in > > > > > >> > > > > > >> https://tools.ietf.org/html/rfc3986#section-3 > > > > > >> < https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%= 3A%2F%2Ftools.ietf..org%2Fhtml%2Frfc3986%23section-3&data=3D02%7C01%7Cdthal= er%40microsoft.com%7Cb115c7f8c70b410eb98308d802a0a8f4%7C72f988bf86f141af91a= b2d7cd011db47%7C1%7C0%7C637262236339214150&sdata=3DupZbOkALJ8SuEk%2FpLLqhdD= DUNMhdpSmjWqpMAyITzc8%3D&reserved=3D0 (https://nam06.safelinks.protection.o= utlook..com/?url=3Dhttps%3A%2F%2Ftools.ietf..org%2Fhtml%2Frfc3986%23section= -3&data=3D02%7C01%7Cdthaler%40microsoft.com%7Cb115c7f8c70b410eb98308d802a0a= 8f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637262236339214150&sdata= =3DupZbOkALJ8SuEk%2FpLLqhdDDUNMhdpSmjWqpMAyITzc8%3D&reserved=3D0)> > > > > > >> is > > > > > >> > > > > > >> > > > > > >> URI =3D scheme ":" hier-part [ "?" query ] [ "#" fragment ] > > > > > >> > > > > > >> > > > > > >> each URI is defined like this and must have a colon. > > > > > >> > > > > > >> > > > > > >> cheers, > > > > > >> > > > > > >> > > > > > >> dret. > > > > > >> > > > > > >> > > > > > >> -- > > > > > >> > > > > > >> erik wilde | mailto: erik.wilde@dret.net | > > > > > >> > > > > > >> | http://dret.net/netdret > > > > > >> < https://nam06.safelinks.protection.outlook.com/?url=3Dhttp%3= A%2F%2Fdret.net%2Fnetdret&data=3D02%7C01%7Cdthaler%40microsoft.com%7Cb115c7= f8c70b410eb98308d802a0a8f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637= 262236339214150&sdata=3Dhq8QVDrXxRmV3iS6DF7R%2FeXFtDKntMcYOHnLSMqx5zo%3D&re= served=3D0 (https://nam06.safelinks.protection.outlook..com/?url=3Dhttp%3A%= 2F%2Fdret.net%2Fnetdret&data=3D02%7C01%7Cdthaler%40microsoft.com%7Cb115c7f8= c70b410eb98308d802a0a8f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63726= 2236339214150&sdata=3Dhq8QVDrXxRmV3iS6DF7R%2FeXFtDKntMcYOHnLSMqx5zo%3D&rese= rved=3D0)> > > > > > >> | > > > > > >> > > > > > >> | http://twitter.com/dret > > > > > >> < https://nam06..safelinks.protection.outlook.com/?url=3Dhttp%= 3A%2F%2Ftwitter.com%2Fdret&data=3D02%7C01%7Cdthaler%40microsoft.com%7Cb115c= 7f8c70b410eb98308d802a0a8f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63= 7262236339224105&sdata=3D9V5l2cgygLF2GJbT9Eh0ptd2mv4YRbvZm6oaYSrf8fE%3D&res= erved=3D0 (https://nam06.safelinks.protection.outlook..com/?url=3Dhttp%3A%2= F%2Ftwitter.com%2Fdret&data=3D02%7C01%7Cdthaler%40microsoft.com%7Cb115c7f8c= 70b410eb98308d802a0a8f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637262= 236339224105&sdata=3D9V5l2cgygLF2GJbT9Eh0ptd2mv4YRbvZm6oaYSrf8fE%3D&reserve= d=3D0)> > > > > > >> | > > > > > >> > > > > > >> > > > > > >=20 > > > > > > _______________________________________________ > > > > > > Uri-review mailing list > > > > > > Uri-review@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/uri-review > > > > _______________________________________________=20 > > > > Uri-review mailing list=20 > > > > Uri-review@ietf.org=20 > > > > https://www.ietf.org/mailman/listinfo/uri-review=20 > >=20 > >=20 > > _______________________________________________=20 > > Uri-review mailing list=20 > > Uri-review@ietf.org=20 > > https://www.ietf.org/mailman/listinfo/uri-review=20 > >=20 > > _______________________________________________ Uri-review mailing list= Uri-review@ietf.org https://www.ietf.org/mailman/listinfo/uri-review >=20 > From nobody Wed Nov 11 08:34:30 2020 Return-Path: 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 7F28D3A0FB5 for ; Wed, 11 Nov 2020 08:34:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 7uVd7QYF8u05 for ; Wed, 11 Nov 2020 08:34:26 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (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 C3EF53A110C for ; Wed, 11 Nov 2020 08:33:44 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MDRDX-1kVUfn43x7-00Gqic; Wed, 11 Nov 2020 17:33:39 +0100 Date: Wed, 11 Nov 2020 11:33:38 -0500 (EST) From: Timothy Mcsweeney To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= , uri-review@ietf.org Message-ID: <600118887.11810.1605112418427@email.ionos.com> In-Reply-To: <423303294.393105.1592315876635@email.ionos.com> References: <491516506.246380.1589851279474@email.ionos.com> <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> <1081815563.141711.1590624311343@email.ionos.com> <117630321.142251.1590627970509@email.ionos.com> <8ae1641a-74c8-6c2d-7092-6cf53e745fb7@ninebynine.org> <797476254.282655.1590770737009@email.ionos.com> <1729337515.289325.1590778487527@email.ionos.com> <4CEF6E3B-6116-4CDB-B660-16554A9638B5@mac.com> <1192631250.937545.1592251697716@email.ionos.com> <8783b642-c4bd-ce63-9113-c13c340abad1@it.aoyama.ac.jp> <423303294.393105.1592315876635@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:GFavtm0ArUkaBY4S4ZmET9NRIJKTYREv3Bes9JbyzfCkYz64HrV p3g6IN2tPpzaDHS7tOLQrGgRpLKkiOlWWE0UGpqBoKgyUBPiSE13fh7RwuTl+CeX92Sx/wz 0CXL2WWnxUMNAOYo0vQTRaSXu4sEAbqC1eDey/97DNxZWxufORv8+97vF2gajBBiSfPuRjp bDcXEc5tt9koOs2MAQ4Ag== X-UI-Out-Filterresults: notjunk:1;V03:K0:7A9jgn+ug7s=:PMMZ5K2Fd2vAhWO/snfj/L fJiAufvTnqs6TLAWQdfaXgsv4AEe8yJoimjtQWFn6TcpqHeRpH25q/rc4GIQoQp/Xyy5lXU0T LoDOJX5Bk4ymVubnha3KhUDD7TLFclVqOTEK+w/RCCeGXK1Ag0rhSMgzK3tkC6JYNYLDFsjRb IKR7joGJtjgfKa+UwGK5dci2YvNztC/buVcTsq5175tYuXU2maRJwlssSPqtnE+mteSsEGxjh XPEcWBD5OnWfexVo0HBKOkhM/WmF3el0h9g9pdqebccQSBdLisDutTbuPuYtR9kRLJ1i72maD g1FNeNrYYebX7aPtVe8YcK1aC1pmGtEcogddSMCY+tRxMRChrYC7Ald8nbXveMDD6KAbNjYQg FcLpfxTbSOOmn1BOKlKr1Qx4e4UurE4iP7fxeu615uYTV1wTzikXt9CN0rWFR1NzSERPj2Nh/ IvV1ElsK3Q== Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 16:34:27 -0000 text version: Does anyone disagree with Martin? > On 06/16/2020 9:57 AM Timothy Mcsweeney wrote: >=20 >=20 > Does anyone disagree with Martin? >=20 > > On June 15, 2020 at 9:05 PM "Martin J. D=C3=BCrst" < duerst@it.aoyama.a= c.jp> wrote: > >=20 > >=20 > > On 16/06/2020 05:08, Timothy Mcsweeney wrote: > > > Hello, > > >=20 > > > I have given things a lot of thought over the last two weeks and I ha= ve a > > > question for the group. Lets say, even with the objections on the num= ber sign, > > > what harm can come from trying it? > > >=20 > > > From what I gather from the feedback, the parsers wont parse it corre= ctly. Is > > > that so bad? I mean, if my idea only work sometimes, or somewheres, i= s that bad > > > for everyone, or just bad for me? > > Apologies for putting it in the following way: > >=20 > > I think it's only bad for you. > > Everyone else just won't care, they won't use your "drop" non-scheme. > >=20 > > Regards, Martin. > >=20 > >=20 > > >> On May 29, 2020 at 7:01 PM Thomas Fruin < thomasfruin=3D40mac.com@dm= arc.ietf.org> > > >> wrote: > > >> > > >> The usefulness of this mailing list is clear, when needing the help = of the > > >> community in difficult or ambiguous situations that are not covered = in the RFCs. > > >> > > >> For these recently posted, very simple and unambiguous questions, ma= y I kindly > > >> suggest reading the RFCs, because that is what they are for. > > >> > > >> >> For a URI parser, the method used to identify the scheme within a= ny example > > >> is basically: "it's the bit to the left of the colon". > > >> > Is it basically this, or exactly this? > > >> > > >> >> The colon is the "end of label" marker, and that's why folks are = insisting > > >> on it here; without it, you can't use the URI API to select a branch > > >> > Is the colon the only "end of label" marker? > > >> > > >> Thomas Fruin From nobody Wed Nov 11 09:39:39 2020 Return-Path: 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 9EC2A3A2739 for ; Wed, 11 Nov 2020 09:39:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 284lJf5Y35pZ for ; Wed, 11 Nov 2020 09:39:31 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (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 E52653A2733 for ; Wed, 11 Nov 2020 09:28:06 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1MNtKu-1kwk6o2hqa-00OJGv; Wed, 11 Nov 2020 18:27:50 +0100 Date: Wed, 11 Nov 2020 12:27:49 -0500 (EST) From: Timothy Mcsweeney To: Barry Leiba , Carsten Bormann , "uri-review@ietf.org" , =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= , "Henry S. Thompson" , "Daniel R. Tobias" Message-ID: <770670659.14196.1605115669303@email.ionos.com> In-Reply-To: <1405032752.10758.1602779803501@email.ionos.com> References: <1274574756.248916.1602686518898@email.ionos.com> <1411985880.134425.1602705672052@email.ionos.com> <1405032752.10758.1602779803501@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:6vNE48km6kMFtZer0JabLtekQ6ofsoywt7RyzetFNhn3YxD+2tQ vjh2kNkm6khzlsf9wDlaMvfOssgNImhI5d5ju1ak2h4lNIClbi8smOpf8Oork5oUtJdZyuQ Y3nPz8qr8UO7FF/ee3luZ4lr76v+gwVnb6vWg+omvfbXUbWsrJePPxDqAlr29USooIFN5ds eN9ihZIU9HT1iUB3FxK9A== X-UI-Out-Filterresults: notjunk:1;V03:K0:SohKtWyV00o=:tBb0DB4QWv49VPMi1BAs7F 7wfyyLK3bDRoKplfEWL1H7nKasKM3/3ulC85K4m8uxK07vkc8j4dMmlT2y/7PnQ7LZIYmpRpk zbgvKBdht9MJKZWZN8M6BntEhloxiZ1H7eT5KBO7nIB/D0gLW3RUhvF9EZV+C1HP+T0yvsBe1 jjZN/XIuCEEbJLklbziKoIscITH/R2RqV+32oNj3KQk0ReoikljpZXMEgMrNpq7SFfFvD6LF0 rHKcstcvEk9KZd8h0b3znWzCjANJcixeAVXnULjyGCGtypyyIRGBgE1Ss7XYfmFplmZ18gXYp 6qvtgeaWqWs1Tm0R1nKdFXGLuTX1IryrK7gbHEPZK5/AKK3A68NgVGYSeqTPT0wHvCkl77zsn sMnMSgNWprmqzD9jq6HTsOjUtD2EBpMbZu1uCXBjDEMH5z2AzAbbKOXP6+bFI0iJ9lc1uQ49Q UMFi8XEBOg== Archived-At: Subject: Re: [Uri-review] AD sponsorship X-BeenThere: uri-review@ietf.org 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: Wed, 11 Nov 2020 17:39:38 -0000 > On 10/15/2020 12:36 PM Timothy Mcsweeney wrote: > > > Barry, > > >Sometimes are specs are not clear on some points; we know that. This > >isn't one of those cases: the syntax of a URI is very clearly > >specified. > > Why don't you do a tiny update for RFC3986 like Ted did for RFC3405 and make it abundantly clear that only the colon can be used for any URI? Or better yet, I will and you can sponsor it. That be ok with you? > > Tim > > I cc'd the people that I think would be agreeable to the idea to get some early traction.