Re: I-D Action: draft-carpenter-6man-rfc6874bis-00.txt

Andrew Cady <andy@cryptonomic.net> Tue, 06 July 2021 20:05 UTC

Return-Path: <andy@cryptonomic.net>
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 8FE083A3400 for <ipv6@ietfa.amsl.com>; Tue, 6 Jul 2021 13:05:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 PT3bQiUGg8ON for <ipv6@ietfa.amsl.com>; Tue, 6 Jul 2021 13:05:13 -0700 (PDT)
Received: from zukertort.childrenofmay.org (zukertort.childrenofmay.org [IPv6:2607:5300:201:3100::27b7]) by ietfa.amsl.com (Postfix) with ESMTP id 36A2E3A33F2 for <ipv6@ietf.org>; Tue, 6 Jul 2021 13:05:12 -0700 (PDT)
Received: by zukertort.childrenofmay.org (Postfix, from userid 1000) id EFA40F2E54C; Tue, 6 Jul 2021 16:05:08 -0400 (EDT)
Date: Tue, 6 Jul 2021 16:05:08 -0400
From: Andrew Cady <andy@cryptonomic.net>
To: 6MAN WG <ipv6@ietf.org>
Subject: Re: I-D Action: draft-carpenter-6man-rfc6874bis-00.txt
Message-ID: <20210706200508.tc6tl4s7cqe4k3ga@zukertort.childrenofmay.org>
References: <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> <CA+9kkMDGQxFD6v=NJaDXRdRJ3jaRriTnhnyKeK3cG=jaosQhBQ@mail.gmail.com> <20210706161859.2wdw7mkeg4b7nd66@zukertort.childrenofmay.org> <28125.1625590441@localhost> <20210706170435.2dfvdx2aynpqxwl6@zukertort.childrenofmay.org> <24972.1625597141@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <24972.1625597141@localhost>
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/vYeqwJvjQOq7BGaxLyaUkohQm6o>
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 20:05:22 -0000

On Tue, Jul 06, 2021 at 02:45:41PM -0400, Michael Richardson wrote:
>
>     >> So why do the browser implementers have such difficulties with
>     >> processing this?  Running code wins.
>
>     > There is no difficulty implementing it the way that I say to do
>     > it!
>
>     > The difficulty (or rather, refusal) is implementing it the
>     > broken way that the standard says to do.
>
> Well, each time I read your (multiple) posts, I see you describing
> what I think that the standard already says.  Obviously, I'm wrong.
>
> You also seem to be disagreeing with Brian's text, which is why
> I'm confused.  Maybe you could just make a pull request to Brian's
> document?

The problem isn't with the changes Brian made.  Those changes were
needed and good.  (By the way, thanks Brian.)

The problem is in what was left unchanged.  Brian did not break with
rfc6874 but that break is what is needed.  We need to propagate the fix
back to all relevant RFCs.






Specifically, these definitions must change:

    ZoneID = 1*( unreserved / pct-encoded )
    IPv6addrz = IPv6address "%25" ZoneID


These definitions can be used instead:

    ZoneID = 1*( unreserved )
    IPv6addrz = IPv6address "%" ZoneID






By the way, there is a relevant mistake of fact in rfc6874:

    According to URI syntax [RFC3986], "%" is always treated as an
    escape character in a URI,

The "always" part is untrue.  It is only treated that way where BNF says
"pct-encoded".  Inside of square brackets it must instead be treated as
an error.  Pct-encoded data is not allowed there.