Re: Reopening RFC6874?

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 17 June 2021 01:51 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 9AC603A12D0 for <ipv6@ietfa.amsl.com>; Wed, 16 Jun 2021 18:51:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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.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 zxfV210VA9Nr for <ipv6@ietfa.amsl.com>; Wed, 16 Jun 2021 18:51:30 -0700 (PDT)
Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 3C9A83A12CE for <ipv6@ietf.org>; Wed, 16 Jun 2021 18:51:30 -0700 (PDT)
Received: by mail-pg1-x530.google.com with SMTP id t17so3615146pga.5 for <ipv6@ietf.org>; Wed, 16 Jun 2021 18:51:30 -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=z2vMNg10OSlNzSYD6aK5KHTv4AbrQo29fHk50MAGm58=; b=XrPmygcmfukqhCfZEwjq/8GIzQZuH0Dv222sCkXL5Jm7bvAHL9e3xQiwmobvtZXPT1 pejpfxLgUEvkqJNaf6n1LXHDM+Njx4G5d2k5KryalEotfI68ILOZQiQsm/fClwxAVgnx H3RFahx3pCJ4cubGTcK7xUjUA1AWxdWZHYBsKqJ9YlXPd8Dqtu+l2lQAiNESyKaFmIr4 Q96vLZo0BFPtq0oP2slkhTj4TiPH8gHTOXX5TK3izFHXuvNkBLLCsdxBUA2WMki7bhAr OQZC0cytnXB2FLUGY1Xe6qVgw7KNHLcQ0rs/hhzWHKo3FcC+8fMJsz9wxvu90LHXDkTu AjUg==
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=z2vMNg10OSlNzSYD6aK5KHTv4AbrQo29fHk50MAGm58=; b=OMzlfvNk6x2jXfsVgfWtueL+uZW8ldCPo6A22RXWDKYMGzgizgxEWCu1tllGk81rbF FLjEljC9yX9pheXVDELRSxwjeW0TrgQ/igPuDHxJJsDDwBPF3RlawRdW5KZDfXgseLSd gEpy7XEAykqKyzOIVkEiUFXCZdnvS14AGqsjAqgDV/tX1GDMbtC3Ym0MBlYTwWrEmwKg 3DMH45rgAzfb+FUZqMt5ujFCt2AQSheqsByX3KMazkbauHz+zaxWzhEN2wgBqbeAFg64 6LbVnXhDmO1o9ZBy4n694uiGoFBFZSZX3WP6B5GWHmG8b6R5lguglox8xd+dQEQSnaA8 YsPA==
X-Gm-Message-State: AOAM530zE2WV2tzxd55+PTyrqVCn6YexWmw5iOWFM3cxW1RzULtfhxqR If1jgf6H8p7wneIygf+pHJU=
X-Google-Smtp-Source: ABdhPJyIVACHLellh9xXYvjbUpr7mIkIMXCpGwv4V+AFBb6oxg92UXBUkhlZaawRmeIqE6NVZPV+lA==
X-Received: by 2002:a63:180c:: with SMTP id y12mr2700291pgl.180.1623894688502; Wed, 16 Jun 2021 18:51:28 -0700 (PDT)
Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id o139sm3495497pfd.96.2021.06.16.18.51.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Jun 2021 18:51:27 -0700 (PDT)
Subject: Re: Reopening RFC6874?
To: Kerry Lynn <kerlyn@ieee.org>
Cc: 6man <ipv6@ietf.org>, Stuart Cheshire <cheshire@apple.com>, valentin.gosu@gmail.com
References: <c1270055-9d41-d826-8ff2-3647feb9861c@gmail.com> <CABOxzu0bDdVKts7ryehxgWNZ6y8yF8Q6CCx7fboTkOxwbvLyLw@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <ec905c22-2d5d-0616-7226-bdd7b7285ab7@gmail.com>
Date: Thu, 17 Jun 2021 13:51:24 +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: <CABOxzu0bDdVKts7ryehxgWNZ6y8yF8Q6CCx7fboTkOxwbvLyLw@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/m3GktGFYGeaSmX4_tlSUYlQ5RUo>
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: Thu, 17 Jun 2021 01:51:35 -0000

Kerry,

Comment below...

On 17-Jun-21 12:15, Kerry Lynn wrote:
> On Wed, Jun 16, 2021 at 7:58 PM Brian E Carpenter <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> wrote:
> 
>     Hi,
> 
>     It is probably necessary to re-open RFC6874 "Representing IPv6 Zone 
Identifiers in Address Literals and Uniform Resource Identifiers."
> 
>     Here's the problem. Web browsers do not correctly support Link Local literal addresses, because they cannot parse the zone identifier (aka the interface identifier).
> 
>     There are of course no "average user" use cases for this, but there 
are several technical use cases. Rather than trying to summarise them, I refer you to the Firefox bug thread about this, which has been open for 10 years:
>     https://bugzilla.mozilla.org/show_bug.cgi?id=700999 <https://bugzilla.mozilla.org/show_bug.cgi?id=700999>
>     Officially it's status is WONTFIX, but every year or two discussion 
restarts.
> 
>     There's also an issue at WHATWG: https://github.com/whatwg/url/issues/392 <https://github.com/whatwg/url/issues/392>
> 
>     My conclusion from the latest round of discussion of those two threads is that if we don't update RFC6874, nothing will change. So I propose 
that we do update RFC6874. As far as I can tell, the main issue is as follows:
> 
>     The security considerations say:
> 
>     >    An HTTP client, proxy, or other intermediary MUST remove any ZoneID
>     >    attached to an outgoing URI, as it has only local significance at the
>     >    sending host.
> 
>     There is also non-normative text saying:
> 
>     >    However,
>     >    URIs including a ZoneID have no meaning outside the originating node.
>     >    It would therefore be highly desirable for a browser 
to remove the
>     >    ZoneID from a URI before including that URI in an HTTP request.
> 
>     As I understand it, those requirements are considered unreasonable and
>     too hard to code by browser implementors. Also, there is a use case
>     that Andrew Cardy can describe better than me where the deletion of 
the
>     Zone ID breaks a higher-level protocol. (CUPS printing; Michael Sweet
>     raised the issue on this list 8 years ago.)
> 
>     Would the WG be interested in taking up this work? I think most of it
>     would consist of using the "delete" key on RFC6874.
> 
> Hi Brian,
> 
> Am I correct in assuming that no implementation will proceed without WHATWG's
> approval? In the event, we might first try to initiate a conversation with them to
> explain why this functionality would be useful and see if there's a solution they
> would find acceptable.

Certainly the process would involve both W3C and WHATWG liaison, but we have to bootstrap the work somewhere, so why not here?

(One of the things I'll do is discover whether the IETF even has a liaison channel to WHATWG.)

   Brian