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

Andrew Cady <andy@cryptonomic.net> Fri, 09 July 2021 05:19 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 6A42F3A10D3 for <ipv6@ietfa.amsl.com>; Thu, 8 Jul 2021 22:19:49 -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 kqCHfBhT9x8t for <ipv6@ietfa.amsl.com>; Thu, 8 Jul 2021 22:19:47 -0700 (PDT)
Received: from zukertort.childrenofmay.org (zukertort.childrenofmay.org [IPv6:2607:5300:201:3100::27b7]) by ietfa.amsl.com (Postfix) with ESMTP id 05E973A10CF for <ipv6@ietf.org>; Thu, 8 Jul 2021 22:19:46 -0700 (PDT)
Received: by zukertort.childrenofmay.org (Postfix, from userid 1000) id F3FEBF330E3; Fri, 9 Jul 2021 01:19:43 -0400 (EDT)
Date: Fri, 9 Jul 2021 01:19:43 -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: <20210709051943.7p2jx6pfivujbrqp@zukertort.childrenofmay.org>
References: <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> <20210706200508.tc6tl4s7cqe4k3ga@zukertort.childrenofmay.org> <54007d49-0bb7-d97e-a7cc-6d6d982c0493@gmail.com> <CA+9kkMCOWVtjrZwrSp-qO9r4oOCSwm90sJ9NVb8uXDB3xraQWA@mail.gmail.com> <9cdae794-0f9d-1b40-9aac-7c09e604324a@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <9cdae794-0f9d-1b40-9aac-7c09e604324a@gmail.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/wHlI1gFEO6ndaCRn-zpdCXUrFws>
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: Fri, 09 Jul 2021 05:19:50 -0000

On Thu, Jul 08, 2021 at 09:56:43AM +1200, Brian E Carpenter wrote:
> On 07-Jul-21 19:39, Ted Hardie wrote:
> >
> > The difficulty with this approach is that it requires you to treat
> > the % with different semantics depending on where it occurs in the
> > URI. 
> >
> > From a specification perspective, that's a major change from the
> > philosophy in the development of URIs which were attempting to be,
> > well, uniform.  From a practical perspective, it may look easy when
> > you use a parser with a specific order of operations, but it ends up
> > ossifying that order into the base spec.  That may not be a great
> > thing (or possibly, given the breadth of schemes which might use
> > this production).
>
> Exactly my point, Ted, but Andrew disputes it.

I acknowledge that you can't pct-decode unreserved characters on a
first pass before parsing out the IPv6 literal field and still use the
unencoded % as syntax within that field.

Yet even a parser that _does_ decode unreserved before parsing still
won't ever mix up the _boundary_ of the IPv6 address based on whether %
is within it.  So why does it matter?

Either an implementation has been updated to support the fe80 address
syntax or not.

If not, the fact those addresses won't work doesn't matter.  It only
matters whether a failure mode is harmful.  It looks like the failure
mode is at worst IPv6 parse constructing an unzoned fe80 address that
can't be connected to, and in practice probably a parse error like "URL
using bad/illegal format or missing URL".

If the implementation has been updated, the update can simply include
not decoding %25 within the square brackets.