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 >
- [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Henry S. Thompson
- Re: [Uri-review] Request for review Martin J. Dürst
- Re: [Uri-review] Request for review Ted Hardie
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Martin J. Dürst
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Daniel R. Tobias
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Daniel R. Tobias
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Daniel R. Tobias
- Re: [Uri-review] Request for review Daniel R. Tobias
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Erik Wilde
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Dave Thaler
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Dave Thaler
- Re: [Uri-review] Request for review Dave Thaler
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Graham Klyne
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Ted Hardie
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Graham Klyne
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Michael Wojcik
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Michael Wojcik
- Re: [Uri-review] Request for review Daniel R. Tobias
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Larry Masinter
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Thomas Fruin
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Martin J. Dürst
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Henry S. Thompson
- Re: [Uri-review] Request for review Daniel R. Tobias
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Timothy Mcsweeney
- Re: [Uri-review] Request for review Timothy Mcsweeney