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

Andrew Cady <> Tue, 06 July 2021 16:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7C8073A2D23 for <>; Tue, 6 Jul 2021 09:19:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hYLwZeLhxo_z for <>; Tue, 6 Jul 2021 09:19:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 397193A2D22 for <>; Tue, 6 Jul 2021 09:18:59 -0700 (PDT)
Received: by (Postfix, from userid 1000) id 5B29BF2DF5D; Tue, 6 Jul 2021 12:18:59 -0400 (EDT)
Date: Tue, 06 Jul 2021 12:18:59 -0400
From: Andrew Cady <>
To: 6MAN WG <>
Subject: Re: I-D Action: draft-carpenter-6man-rfc6874bis-00.txt
Message-ID: <>
References: <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 06 Jul 2021 16:19:06 -0000

On Tue, Jul 06, 2021 at 05:00:04PM +0100, Ted Hardie wrote:
>    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

I've already explained to this list, last week, why there is no
collision.  So it appears to me, not that I've failed to understand your
intent, but that you didn't even read that.  :(

To be fair, it was long.  Today I reiterate everything.

There is no such collision because IPv6-Literal is not a percent-decoded
data component.  Percent-decoding is done AFTER parsing into components,
only some of which are encoded like that.  It's done on OTHER COMPONENTS
but not done on the component where you say it conflicts.

It would only be a conflict if it was in one of the components that
allowed that encoding.

>    Since this update RFC 3986, this would be permitted if this is
>    approved, even though this is a change from RFC 3986.

You acknowledge that the RFC specifies that the field is not subjected
to percent-decoding.

The point you miss is that therefore there is no conflict with using it
as a syntactic delimiter.