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

Ted Hardie <ted.ietf@gmail.com> Wed, 07 July 2021 07:39 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 A5D183A0AD6 for <ipv6@ietfa.amsl.com>; Wed, 7 Jul 2021 00:39:58 -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 MTng9ZQfkUNq for <ipv6@ietfa.amsl.com>; Wed, 7 Jul 2021 00:39:54 -0700 (PDT)
Received: from mail-oo1-xc33.google.com (mail-oo1-xc33.google.com [IPv6:2607:f8b0:4864:20::c33]) (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 48AF93A0AD4 for <ipv6@ietf.org>; Wed, 7 Jul 2021 00:39:54 -0700 (PDT)
Received: by mail-oo1-xc33.google.com with SMTP id r14-20020a4ad4ce0000b029024b4146e2f5so298477oos.1 for <ipv6@ietf.org>; Wed, 07 Jul 2021 00:39:54 -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=WF7c1OqcvQZR1oEpIf5GebyukNYzPh3TkaogfKOPwq0=; b=IvJ/Wln49nHmFTL/rDnMWIdxJxdDzw1VRGqfwPJbfS1JtLghYPPzeX8vckd00WBFjr QE8zEMOecpxpZ3IUc4tWaO1uUNB71Mt0tPrBxsZNtNOk2LT4IyUP0muaO1hfGDq539mk WKQQFA5ppdT8pkFAm0Mdr14FZ5VzgoHQpWuk+f/8mPWeKgsfmb57vvDNm1CVbNwYJ01J v8+SxV0R6bz66cr9pDBg3UeSnsIppTSQ+guYCTPvluetwiSdEihsk4SJlKlGZ6dxVJ1F l4wfFSh5dpnzu6DfdyspM+6c9mvMx+FUf+zGeWL9nA+p48u3ztVtGQHqcqLU1Knl0ayQ qpmA==
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=WF7c1OqcvQZR1oEpIf5GebyukNYzPh3TkaogfKOPwq0=; b=oMa2fJX1jBta5u3aAIQoKwkJI1ei+3fU/1iMlqVSKL3BxdBanQwi8MLPgeX7RBp+f9 E4HmWQwsvKgvyvYKPITmHuM1DwQC56jTddQGiFetu/Qg4FSRmeSWlhM9unkKuv4Go35a 036n8HTX8uWlFPr+3Zzy4cgcZSlUSW94kikwfIMZWupfd8EGgmrk5leswmiBKpCSkZjh UKB6eqT2iojwN+j7sL2re+kC53DYaAPX8MQrDKVVxWtrcDJSI+VxUDTLaMLdjLk1P1ld 4KaMIi2dswjacFpThKBZB/l07lwIULveYyRFnJCX+t/vHbR1riAzYiT3vG4JQIFgMa3x 2rPA==
X-Gm-Message-State: AOAM531NeG/o6o3y28ti+pRKUHKnh4n74/QCElTOST6L10kxjyJEKeri qCsGFPrZcGiBmKMtwHve7gLQdX3erJfLI7U0a50=
X-Google-Smtp-Source: ABdhPJwm23U3NkNgScIGhva5k8+bTRXN3oNBoiZU2kn5xkWLNab0f4vNp93XMSxQZjQMDxKifKuK7Gx4bGcdUUvK5ZE=
X-Received: by 2002:a4a:8503:: with SMTP id k3mr8072096ooh.25.1625643592688; Wed, 07 Jul 2021 00:39:52 -0700 (PDT)
MIME-Version: 1.0
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> <20210706200508.tc6tl4s7cqe4k3ga@zukertort.childrenofmay.org> <54007d49-0bb7-d97e-a7cc-6d6d982c0493@gmail.com>
In-Reply-To: <54007d49-0bb7-d97e-a7cc-6d6d982c0493@gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Wed, 7 Jul 2021 08:39:26 +0100
Message-ID: <CA+9kkMCOWVtjrZwrSp-qO9r4oOCSwm90sJ9NVb8uXDB3xraQWA@mail.gmail.com>
Subject: Re: I-D Action: draft-carpenter-6man-rfc6874bis-00.txt
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Andrew Cady <andy@cryptonomic.net>, 6MAN WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000dfa75705c683a4ef"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/MDREVDa-t336wLZuE5OWAzoKc88>
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: Wed, 07 Jul 2021 07:39:59 -0000

Hi Brian,

On Wed, Jul 7, 2021 at 3:17 AM Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> Andrew,
>
> On 07-Jul-21 08:05, Andrew Cady wrote:
> > 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
> >
>
> Thanks for making a concrete proposal. My belief back when
> we did RFC6874 was that this would not be acceptable in the
> URI world. I'd be glad to test this belief again.
>
>
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).

I'd also like to draw your attention to RFC 8820, which updates RFC 3986 to
give best practices in defining structure and semantics in URIs.  Its
guidelines, specifically in section 2, may help guide your thinking here.

As a practical matter, I suggest you ask for a slot in the upcoming
DISPATCH/ART area open meeting; that will help get a different community
focused on your proposal.

best regards,

Ted Hardie


> > 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.
>
> Well, it *is* allowed in a URI precisely because RFC6874 formally updates
> RFC3986. I agree that the production for IPv6address in RFC3986 doesn't
> include pct-encoded. However, RFC3986 section 2.4 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."
>
> As I recall the discussion nine years ago, that statement was taken
> literally to mean *anywhere* in a URI. You are probably correct that a
> strictly ABNF-driven parser wouldn't apply the escape mechanism except
> within pct-encoded, but what do real-world parsers do?
>
> Personally I'd be happy if we could make the change you suggest, but
> we'd need to hear from the implementers.
>
>    Brian
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>