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, 6 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
> --------------------------------------------------------------------
>