Re: I-D Action: draft-carpenter-6man-rfc6874bis-00.txt
Ted Hardie <ted.ietf@gmail.com> Tue, 06 July 2021 16:00 UTC
Return-Path: <ted.ietf@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED0B3A2CA1 for <ipv6@ietfa.amsl.com>; Tue, 6 Jul 2021 09:00:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 pgpQCKk_BHwF for <ipv6@ietfa.amsl.com>; Tue, 6 Jul 2021 09:00:33 -0700 (PDT)
Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1E9A3A2CA8 for <ipv6@ietf.org>; Tue, 6 Jul 2021 09:00:32 -0700 (PDT)
Received: by mail-ot1-x32f.google.com with SMTP id i12-20020a05683033ecb02903346fa0f74dso22029546otu.10 for <ipv6@ietf.org>; Tue, 06 Jul 2021 09:00:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tAzeykSKQysnXdUtlBjlp5455ob9+eWmqqe3bnqIKOQ=; b=a3NpiYqZUBazPtfZq59kG2Jgu1dXrvwT7SHD0obf73a8I1kg3LQyR05Qrl1ZokJhTg nJn7GiVBFRTEFArrViZodGcBR8L5t5871GBtl8P9CFUOMnaomd3xS8axuHit8Iw+mzrI 7CEF6Ajye4msclkx9qZE6/oZVtIXauZQbi//2UDIkwiXX4xLXl7+BvjQYVMbvhh1HUZ4 3eXR1s9OgTnZsg0TgDhzsfsEEYujb/1YsjAqWSb/sT+70eSl0kXRHcxMoNzNVSptc9Y1 VOt0lcYTPRkgiV21j9+TqHKwSf/5i8XXg5+a5v3ZknZbrdkaTp+yk9Ek+3N0OrPNHTcV 7BHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tAzeykSKQysnXdUtlBjlp5455ob9+eWmqqe3bnqIKOQ=; b=a9CkhUu0+Y+Nueq/Bq0T/TsZ0ANlOka0T6fwK14NBggD9bwAK4tRxhUBvT4vlQSxgD PdCHbN73d6AccauzkPifoyCGVmU5Ngyb0pycmnuRaI+JUehg5zgaBqjB+8daroWd9KxV +s2omlDBMZJ6u3Fmk3e+4jEQw6+W7CFRyWXilL1bXKexL0N3VjYS++NlfepUJNfRnGg1 GU8MAfZlgHDh2RymQPfEdx6FcmSiyoK2OQCq+HZwDq+UvfYSGefzpJQUuhNx/fSn1ygI LYEvF+hI5OAfYGERBDvE8RxOTMZGV2zL5CaVh5oD/yTszpGbiIZrb8T8svuPqHqOG5+E XT9w==
X-Gm-Message-State: AOAM533eqn1fVwXv8nTqweu6frMzn3MnR6Sc/r6Z7DHYUSalB3voqZ1K hdrSBNn5Bmc/g3B1pXTraSKGQtSGC3WtoIjEeMU=
X-Google-Smtp-Source: ABdhPJxOSY9XRqpuSapF/VbiSBfLOousMZo/YvdseC5Ta5LH30LgYdGf7ThZoueh/S2bPAbOGub2C+PkxTeynSFREUU=
X-Received: by 2002:a9d:4c0c:: with SMTP id l12mr13669445otf.165.1625587230645; Tue, 06 Jul 2021 09:00:30 -0700 (PDT)
MIME-Version: 1.0
References: <162545101341.19246.8566193740265797873@ietfa.amsl.com> <95a7dbe5-e0a3-4676-9dcc-005ff53725e0@gmail.com> <CA+9kkMD3iSgo-KMM5Ed8bVnVCu_G3f2kB6zHKoOx2ta=x8QucA@mail.gmail.com> <CANMZLAbmdWHDRBPpHgy_e4_0-WUVW2gjnbXWwu2pF_xi-S0vWQ@mail.gmail.com> <87a6n13y0j.fsf@ungleich.ch> <CA+9kkMBx4F0FGZasdk11ogyCOwQZecAEkO4JbECDr4osySN-4w@mail.gmail.com> <20210706152527.j47rcxas5nwz5d63@zukertort.childrenofmay.org>
In-Reply-To: <20210706152527.j47rcxas5nwz5d63@zukertort.childrenofmay.org>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Tue, 06 Jul 2021 17:00:04 +0100
Message-ID: <CA+9kkMDGQxFD6v=NJaDXRdRJ3jaRriTnhnyKeK3cG=jaosQhBQ@mail.gmail.com>
Subject: Re: I-D Action: draft-carpenter-6man-rfc6874bis-00.txt
To: Andrew Cady <andy@cryptonomic.net>
Cc: 6MAN WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006f218205c67685be"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Y4e7FEk_sLJvKPd_6rM2NCE6CxE>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Jul 2021 16:00:40 -0000
Hi Andrew, A short reply in-line. On Tue, Jul 6, 2021 at 4:26 PM Andrew Cady <andy@cryptonomic.net> wrote: > On Mon, Jul 05, 2021 at 11:08:24AM +0100, Ted Hardie wrote: > > Hi Nico, > > Essentially, the % symbol in a URI is an indicator that what > > follows is percent encoded; see RFC 3986, section 2.1. Section > > 2.4 also says: Because the percent ("%") character serves as the > > indicator for percent-encoded octets, it must be percent-encoded as > > "%25" for that octet to be used as data within a URI. > > > > This proposal treats the % which starts a scope identifier as "data > > within a URI" and so it percent-encodes the percent symbol. > > That is a bug. The '%' must be treated as the syntactic delimiter it is. > > My apologies; it appears that I didn't get my intent across. Let me try to rephrase. Because of a collision between the defined zone-id scope-id separator and the URI syntax, this proposal percent encodes the zone-id separator, and updates the URI syntax to permit the percent-encoded zone-id separator to be included in the IP literal syntax. Since this update RFC 3986, this would be permitted if this is approved, even though this is a change from RFC 3986. I hope that remedies any lack of clarity on my part, regards, Ted > We don't encode the '[' or the ':' either. We only allow > percent-encoding in the percent-decoded data parts of the URI. The '%' > is a delimiter between two separate data parts. It is not a data part. > The user cannot input different values there. > > No other percent-encoded character is allowed there. It is not a data > part! It is a constant, not a variable! It is not a percent-decoded > component! > > You are not allowed by RFC3986 to treat it as a data part, because that > document states correctly that it is not one. > > > > > Please remember two facts and a corollary that I posted here last week: > > 1. RFC3986 says percent-decoding is done AFTER parsing into components > and subcomponents > > 2. The IPv6 literal subcomponent is NOT percent-encoded. > > 2a. No percent-decoding is done (or allowed) on this parsed subcomponent. > > (Ref:< > https://mailarchive.ietf.org/arch/msg/ipv6/FPLeDZXqJ1zwE1yF_Qkh7Ldq120/>) > > > > > > > The technical question before us is whether to put a percent-encoded > character into a non-percent-decoded field! > > > > > > > The unfixable problem for implementors is where to strip the > redundantly-added "25". The URL fragment needs to move like this: > > 1.User --> 2.Location Bar --> 3. Web client --> 4.Web server --, > | > ,-- 5.Web application <---' > | > .------------------, > | > 8.User <-- 7.UA rendered content <-- 6.Web client <-----' > > If a point of mangling is specified, then a corresponding point of > de-mangling must be specified. Neither have been properly specified. > > > > > I claim ONLY if the fragment is mangled at 3 and de-mangled at 4, then > it can be made to work with the full range of addresses. Mangle at the > latest possible chance, unmangle at the first possible chance. Thus > protecting the user AND the developer of the web application AND the > developer of the OS insofar as the web application developer depends on > the OS interface. > > In the case of {3,4} mangling is harmless -- but serves no purpose. > > I claim no other choice of mangle/de-mangle locations even works. > > Note: It is NOT acceptable to require the user to handle any mangling or > de-mangling at 1 or 8. > > > > > > > > > Other > > approaches, such as a bare percent symbol within the square brackets > > have been rejected (see the long Mozilla bug thread Brian posted). > > That Mozilla bug thread explains the correct approach to the scopeid > parsing in comment 39: > https://bugzilla.mozilla.org/show_bug.cgi?id=700999#c39 > > > heinz.repp > Comment 39 • 5 years ago > > (In reply to Brian E Carpenter from comment #38) > > But the real objection from > > the browser side is that it's a horrible thing to implement. > > I know, this stems from Ryan Sleevi's 2015 comment, but having > some experience in networks and C programming for decades I can > hardly understand this. I see only 2 distinct jobs here: > > 1. expand the parser of the url-decoded URI that already can > parse IPv6-address-raw: instead of > > IPv6-literal = '[', IPv6-address-raw, ']'; > > parse > > IPv6-literal = '[', IPv6-address-raw, [ '%', IPv6-scope-id ], ']'; > IPv6-scope-id = '0'-'9' | 'a'-'z' | 'A'-'Z', { '0'-'9' | 'a'-'z' | > 'A'-'Z' | ' ' | '_' | '-' }; > > difficulty: 'create your own parser' course, beginner's lesson > > > > > This is the ONLY correct implementation because it is the ONLY > implementation that guarantees that information is not lost in between > the user and the server. We do not need a special case that loses > information here. That loss is simply a bug. A standard that mandates > a bug itself has a bug. > > We simply need to fix the bug to get implementation. The bug cannot be > accepted. The bug must be removed from all existing standards. > > We cannot allow some other standard to block this standard that blocks > the software bugfix: instead, the bug in the software must be fixed, so > that all standards mandating the bug must surrender their priority to > the need to fix the software bug itself. > > Any standard that claims to have higher priority than fixing the bug in > the code must be laughed at by the gods and looked at with suspicion by > mortals. > > > I think that taking this approach is worth trying, but I believe that > > consistency is needed. Making this the valid form but accepting the > > bare % in some circumstances seems likely to me result in lack of > > interoperability. If I can paste when going into browser 1 but not > > browser 2, the result is confusing for the user. > > Yes. The one correct solution is to fix the percent-encoding bug > entirely. It does not make sense to try to support any mangling. > > However, isn't this just about Microsoft, and theirs the sole broken > name-mangling implementation? Is it just Microsoft here demanding that > everyone else match their bug? Just one firm? > > Then let Microsoft ignore the standard -- do not let them ruin it. > Their browser can be the one we call confusingly different. It cannot > be allowed to lead. > > Name-mangling is wrong. It is anti-user. It does not serve any user > interest. It is an "anti-feature." > > Name-mangling cuts off the user from access to software written by many > developers. > > Name-mangling breaks much software written behind the web server _and_ > potentially software written behind the /etc/nsswitch.conf module > system, which allows great diversity of supply of names into the system. > > That is a system that allows developers to plug in their own new > implementations of new ideas. Don't try to take that away! > > > > > > # Solution to Problem # > > The way to fix port 80 is to abolish the name-mangling middle-man > forever. > > Let the server know exactly what the browser's location bar says. > Let the user tell the location bar exactly what the user will. > Make the unbroken user<->server bond a requirement of HTTP. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >
- Fwd: I-D Action: draft-carpenter-6man-rfc6874bis-… Brian E Carpenter
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Ted Hardie
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Brian Carpenter
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Nico Schottelius
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Ted Hardie
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Nick Hilliard
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Eric Vyncke (evyncke)
- Re: Fwd: I-D Action: draft-carpenter-6man-rfc6874… Michael Richardson
- Re: Fwd: I-D Action: draft-carpenter-6man-rfc6874… Brian E Carpenter
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Brian E Carpenter
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Pascal Thubert (pthubert)
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Brian E Carpenter
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Nico Schottelius
- Re: Fwd: I-D Action: draft-carpenter-6man-rfc6874… Ted Hardie
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Michael Richardson
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Andrew Cady
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Ted Hardie
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Andrew Cady
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Andrew Cady
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Andrew Cady
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Michael Richardson
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Jared Mauch
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Andrew Cady
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Nico Schottelius
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Nico Schottelius
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Michael Richardson
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Michael Richardson
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Carsten Bormann
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Andrew Cady
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Jared Mauch
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Brian E Carpenter
- Re: Fwd: I-D Action: draft-carpenter-6man-rfc6874… Brian E Carpenter
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Brian E Carpenter
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Brian E Carpenter
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Ted Hardie
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Philip Homburg
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Michael Richardson
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Brian E Carpenter
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Brian E Carpenter
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Philip Homburg
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Michael Richardson
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Brian E Carpenter
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Brian E Carpenter
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Michael Richardson
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Brian E Carpenter
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Andrew Cady
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Michael Richardson
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Brian E Carpenter
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Brian E Carpenter
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Nick Hilliard
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Nick Hilliard
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Michael Richardson
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Brian E Carpenter
- Re: I-D Action: draft-carpenter-6man-rfc6874bis-0… Brian E Carpenter