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

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 07 July 2021 21:56 UTC

Return-Path: <brian.e.carpenter@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 B7BFA3A0C5F for <ipv6@ietfa.amsl.com>; Wed, 7 Jul 2021 14:56:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.435
X-Spam-Level:
X-Spam-Status: No, score=-2.435 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, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_BLOCKED=0.001, 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 b9HHv34Yx-tY for <ipv6@ietfa.amsl.com>; Wed, 7 Jul 2021 14:56:49 -0700 (PDT)
Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (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 D596A3A0C5E for <ipv6@ietf.org>; Wed, 7 Jul 2021 14:56:49 -0700 (PDT)
Received: by mail-pj1-x1033.google.com with SMTP id b5-20020a17090a9905b029016fc06f6c5bso2505369pjp.5 for <ipv6@ietf.org>; Wed, 07 Jul 2021 14:56:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ib996Ex5Csyh3dawOTmMJW/ER2GOsHUcAwOmueSPI/k=; b=AGZ1V+czev25i+/rwDDM6HIpyh4yE8vw0bkdHvQFEAIFUs4O8DRYVn0sG1NRGLly4m wgf5PMClQMdH7Qbrg6AQzUBRrUZMSuxHcFVTKCO8DTWqbPvk5bnZFkA6GJ/JFNe8ePLM Oymh7vVRsWG3TpDU5/JdM7yWWPKvjAsqteMYsNxKPeAbMPodhxlojSCSWVN7eHeeJHej +H7ebUTFghM4qBkSsU8NeeQsWZT0gi0ea3/p22o4FgKDldk366mgXblXVoc+VAMRs8JA 1B9mbMyVAPCt+CsK0GfNGQfP8NrPCn4oHBkunXrxreiIbkzaKsfSrtBy+HsEEkJmj3LN jIdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ib996Ex5Csyh3dawOTmMJW/ER2GOsHUcAwOmueSPI/k=; b=KrL7hBZA01JQdRzMRb/qcQrKz8vhWRrajhiDWz/plpvoI8E0lo5SAavGVZGGHm3c7R fjLuGz472oyS19ABmQ6M0lZJToXmFznhd5DG2Q7lnRyep1kWxt8zZFXoX6pfDmewtsNv zBmj56H2rwj5o7vcxu9U65CCWOjIKWOBDUMxtKrIvp95JwNrQoVPDDzHq2yCUXz28oEJ CpQXy9WQXCru9j9EcO17czoH/JJJukODlBeZZpPYzNoUYj6hkMdKiUBGX/tveqT6jMIv qiW0H8yGwx8DNpj/An7YYw2HpZMfSNjEEj9Ws581rcX8CpW+lnhZ2G5PQYV0r/s3LfrR vFJQ==
X-Gm-Message-State: AOAM531iSosjngyCBo2cZLrmp0S0B6rF8HhnbUWMk2lOzSkHEYa6yYcn 9bdPZPDStmjzyjIe7HUKQ0eBSs1nlR5wsw==
X-Google-Smtp-Source: ABdhPJzqpiX94jFNoTX7rjDhiB+6E9ic9FwQUcB/hlmt+t4Un5wF778p4Co+7AQWusOYLm+j6K7Ung==
X-Received: by 2002:a17:902:fe8b:b029:129:7797:ff4d with SMTP id x11-20020a170902fe8bb02901297797ff4dmr18493276plm.17.1625695008434; Wed, 07 Jul 2021 14:56:48 -0700 (PDT)
Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id o1sm134626pjf.56.2021.07.07.14.56.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Jul 2021 14:56:47 -0700 (PDT)
Subject: Re: I-D Action: draft-carpenter-6man-rfc6874bis-00.txt
To: Ted Hardie <ted.ietf@gmail.com>
Cc: Andrew Cady <andy@cryptonomic.net>, 6MAN WG <ipv6@ietf.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> <20210706200508.tc6tl4s7cqe4k3ga@zukertort.childrenofmay.org> <54007d49-0bb7-d97e-a7cc-6d6d982c0493@gmail.com> <CA+9kkMCOWVtjrZwrSp-qO9r4oOCSwm90sJ9NVb8uXDB3xraQWA@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <9cdae794-0f9d-1b40-9aac-7c09e604324a@gmail.com>
Date: Thu, 8 Jul 2021 09:56:43 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <CA+9kkMCOWVtjrZwrSp-qO9r4oOCSwm90sJ9NVb8uXDB3xraQWA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/mN9vG2GDbH2UZeKgyGaKG5FtpdM>
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 21:56:54 -0000

On 07-Jul-21 19:39, Ted Hardie wrote:
> Hi Brian,
> 
> On Wed, Jul 7, 2021 at 3:17 AM Brian E Carpenter <brian.e.carpenter@gmail.com <mailto: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). 

Exactly my point, Ted, but Andrew disputes it.
 
> 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.

I don't see much there that addresses our dilemma.
 
> 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.

We will do that in any case.

Thanks
   Brian
> 
> 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 <mailto:ipv6@ietf.org>
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 
<https://www.ietf.org/mailman/listinfo/ipv6>
>     --------------------------------------------------------------------
>