Re: [Uri-review] Request for review

Graham Klyne <gk@ninebynine.org> Fri, 29 May 2020 10:02 UTC

Return-Path: <gk@ninebynine.org>
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 5316D3A0D97 for <uri-review@ietfa.amsl.com>; Fri, 29 May 2020 03:02:00 -0700 (PDT)
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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSSHne0bKrZF for <uri-review@ietfa.amsl.com>; Fri, 29 May 2020 03:01:57 -0700 (PDT)
Received: from relay12.mail.ox.ac.uk (relay12.mail.ox.ac.uk [129.67.1.163]) (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 779123A0CA8 for <uri-review@ietf.org>; Fri, 29 May 2020 03:01:57 -0700 (PDT)
Received: from smtp5.mail.ox.ac.uk ([163.1.2.207]) by relay12.mail.ox.ac.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <gk@ninebynine.org>) id 1jebpr-00009t-f5; Fri, 29 May 2020 11:01:55 +0100
Received: from gklyne38.plus.com ([81.174.129.24] helo=spare-94.atuin.ninebynine.org) by smtp5.mail.ox.ac.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <gk@ninebynine.org>) id 1jebpn-00085k-IC; Fri, 29 May 2020 11:01:51 +0100
To: Timothy Mcsweeney <tim@dropnumber.com>, uri-review@ietf.org
References: <491516506.246380.1589851279474@email.ionos.com> <5EC9B257.31362.CC5E003@dan.tobias.name> <1783049000.100771.1590323508943@email.ionos.com> <5ECA8A94.23977.101292FE@dan.tobias.name> <1426881880.158099.1590335585858@email.ionos.com> <94368b41-c15b-da2c-421d-fdd9300be6e9@dret.net> <1310141163.159340.1590344745080@email.ionos.com> <BL0PR2101MB102738EF50D7C8AD647E10BBA3B20@BL0PR2101MB1027.namprd21.prod.outlook.com> <1081815563.141711.1590624311343@email.ionos.com> <BL0PR2101MB102762C4CAFACC383412D5D8A38E0@BL0PR2101MB1027.namprd21.prod.outlook.com> <BL0PR2101MB10278A5360398EFF2E73FC0BA38E0@BL0PR2101MB1027.namprd21.prod.outlook.com> <117630321.142251.1590627970509@email.ionos.com>
From: Graham Klyne <gk@ninebynine.org>
Message-ID: <8ae1641a-74c8-6c2d-7092-6cf53e745fb7@ninebynine.org>
Date: Fri, 29 May 2020 11:01:48 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <117630321.142251.1590627970509@email.ionos.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-Oxford-Username: zool0635
Archived-At: <https://mailarchive.ietf.org/arch/msg/uri-review/zV-L04u7KbDYvXbxrqFtdQfDWBY>
Subject: Re: [Uri-review] Request for review
X-BeenThere: uri-review@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proposed URI Schemes <uri-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uri-review>, <mailto:uri-review-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uri-review/>
List-Post: <mailto:uri-review@ietf.org>
List-Help: <mailto:uri-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 May 2020 10:02:00 -0000

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 when 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 purposes 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 delimit 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-specific 
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 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>om>; uri-review@ietf.org
>> *Subject:* Re: [Uri-review] Request for review
>>
>>
>> I don’t understand your question.   The URL syntax is fixed by that RFC.
>>
>> I don’t know what you mean by “safe” or “valid”.
>>
>> If by “valid” you mean “allowed by RFC 3986”, 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
>> *To:* uri-review@ietf.org <mailto: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 valid, would 
>> you oppose their use in URIs?
>>
>>
>> Tim
>>
>>
>>
>>
>>     On May 24, 2020 at 6:08 PM Dave Thaler <dthaler@microsoft.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         = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
>>
>>     Only strings that conform to the above are URIs.
>>
>>     So “drop#sd54g54” is not a URI because it does not conform to the above
>>     syntax, as it has no “:”
>>
>>     “drop:sd54g54” on the other hand would be a valid URI.
>>
>>     This is what folks are saying when they say if you just change the “#” to
>>     a “:” 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:erik.wilde@dret.net>>;
>>     uri-review@ietf.org <mailto: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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fietf.org%2F&data=02%7C01%7Cdthaler%40microsoft.com%7Cb115c7f8c70b410eb98308d802a0a8f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637262236339204192&sdata=UJ7TQnKfGZMnWkBKZCVozZQhn%2BGir1saiPQoNGV2C9M%3D&reserved=0>"
>>     the colon is not part of the hier-part?
>>
>>         On May 24, 2020 at 12:02 PM Erik Wilde < erik.wilde@dret.net
>>         <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.   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, <scheme> and <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 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
>>         <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf..org%2Fhtml%2Frfc3986%23section-3&data=02%7C01%7Cdthaler%40microsoft.com%7Cb115c7f8c70b410eb98308d802a0a8f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637262236339214150&sdata=upZbOkALJ8SuEk%2FpLLqhdDDUNMhdpSmjWqpMAyITzc8%3D&reserved=0>
>>         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 <mailto:erik.wilde@dret.net> |
>>
>>         | http://dret.net/netdret
>>         <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdret.net%2Fnetdret&data=02%7C01%7Cdthaler%40microsoft.com%7Cb115c7f8c70b410eb98308d802a0a8f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637262236339214150&sdata=hq8QVDrXxRmV3iS6DF7R%2FeXFtDKntMcYOHnLSMqx5zo%3D&reserved=0>
>>         |
>>
>>         | http://twitter.com/dret
>>         <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftwitter.com%2Fdret&data=02%7C01%7Cdthaler%40microsoft.com%7Cb115c7f8c70b410eb98308d802a0a8f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637262236339224105&sdata=9V5l2cgygLF2GJbT9Eh0ptd2mv4YRbvZm6oaYSrf8fE%3D&reserved=0>
>>         |
>>
>>
> 
> 
> _______________________________________________
> Uri-review mailing list
> Uri-review@ietf.org
> https://www.ietf.org/mailman/listinfo/uri-review
>