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

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 06 July 2021 04:57 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 D50E43A0A24 for <ipv6@ietfa.amsl.com>; Mon, 5 Jul 2021 21:57:32 -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 OJKlOeo5e4sa for <ipv6@ietfa.amsl.com>; Mon, 5 Jul 2021 21:57:27 -0700 (PDT)
Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (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 8495F3A0A1E for <ipv6@ietf.org>; Mon, 5 Jul 2021 21:57:27 -0700 (PDT)
Received: by mail-pl1-x629.google.com with SMTP id u19so11349630plc.3 for <ipv6@ietf.org>; Mon, 05 Jul 2021 21:57:27 -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=hMYstp+JTpLI74Bb3+hT5rCOCPpbt745yyUf0KXtRP4=; b=GP+JxYY73G0aWBZmuGIS3wgP0ZbJ3BgIfhf6dobdtW7qWq/zNYFDa3c4cWVvTE129I lGuE/tIibuil69mee0iwxQV6roYt7y9hxyEXn34R8q4NOoOeCBasaUn+g4J7dUTokCU7 SWbb7eHJOQ2JDVitosiGxcjWlpLxuShl7yCDMJoGiF4fAKJSkG5prxeL25wQILatfDc7 V6EAmFVqu4tTz7I/3TUABJEnM50jzkANnB5l0LxZJBWhK2aaAAxdW8aCYgMLZd3hILvr jlzTFPJV/20zGVw4ewu3XSO78zejm+uLonEsC4fnxce5MWium/qxCj3CmeEtgSxAQxjr 1KHg==
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=hMYstp+JTpLI74Bb3+hT5rCOCPpbt745yyUf0KXtRP4=; b=KNdhCFKFPgEwgnsWZV2N8GbbQIR+0My11+VN4Io++jGR2j/LbPkTiqi6YvHPg2LwKY tDWkPHeHmDrvtWlJLRxyO8b3QR0l+iCGJo5zO6C1utxezKrRboBXApf75F+vR/SU9bd7 VPp33P9XCarPFsclGnwyp9x3HCrdiqanlUDX90lfh9Aj8Tie3XtEk05qHjyfixVU9vUj gIuRFvSwLp94AI/rn2pMPWR97W21JxOD8+4MrtB0XRTfuMMB0rxHIJd3r7vT/ygYXUHQ arFj6ADJvSHoR/OuBzcInzl+eXVTpYNFsWaBtNTqlOXC3VAZK9xJQcVLxfMz/fDKKXVr cE3Q==
X-Gm-Message-State: AOAM530CHmu28hIopIndaWhCOkm5mws0MOj6DV59Mz4quYfCAZ6+yGW7 F4KWP/QRZUO3D9OCpOBP8AKNiiBUdNNTLA==
X-Google-Smtp-Source: ABdhPJy4+5WHOa1yZ98nWWy3yIISrPtukqOaCxOcLZOsLBIom6df+vn645cGYWwbLKD1piaEFH4vOQ==
X-Received: by 2002:a17:902:f682:b029:128:e54c:f58a with SMTP id l2-20020a170902f682b0290128e54cf58amr15385847plg.13.1625547445637; Mon, 05 Jul 2021 21:57:25 -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 v7sm15537830pgv.81.2021.07.05.21.57.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Jul 2021 21:57:24 -0700 (PDT)
Subject: Re: I-D Action: draft-carpenter-6man-rfc6874bis-00.txt
To: Ted Hardie <ted.ietf@gmail.com>, Nico Schottelius <nico.schottelius@ungleich.ch>
Cc: Bob Hinden <bob.hinden@gmail.com>, 6MAN WG <ipv6@ietf.org>
References: <162545101341.19246.8566193740265797873@ietfa.amsl.com> <95a7dbe5-e0a3-4676-9dcc-005ff53725e0@gmail.com> <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>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <01289d8c-a470-1867-448f-3d616647ba5f@gmail.com>
Date: Tue, 6 Jul 2021 16:57:20 +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+9kkMBx4F0FGZasdk11ogyCOwQZecAEkO4JbECDr4osySN-4w@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/96XxDqKN4dumd7f1jTRx695yRIE>
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: Tue, 06 Jul 2021 04:57:35 -0000

Ted,

On 05-Jul-21 22:08, Ted Hardie wrote:
> Hi Nico,
> 
> Essentially, the % symbol in a URI is an indicator that what follows is 
percent encoded; see RFC 3986, section 2.1.  Section 2.4 also 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.
> 
>  This proposal treats the % which starts a scope identifier as "data within a URI" and so it percent-encodes the percent symbol.  Other approaches, such as a bare percent symbol within the square brackets have been rejected (see the long Mozilla bug thread Brian posted).
> 
> I think that taking this approach is worth trying, but I believe that consistency is needed.  Making this the valid form but accepting the bare % in some circumstances seems likely to me result in lack of interoperability.  If I can paste when going into browser 1 but not browser 
2, the result is confusing for the user.

Yes, that is a fairly persuasive argument.

Just to play devil's advocate for a moment, once consequence of the % escape is that
the user could execute
   ping6  fe80::80b2:5c79:2266:e431%eth0
but in a browser window would have to type
   https://[fe80::80b2:5c79:2266:e431%25eth0]
so a simple cut-and-paste won't do it.

Appendix A of the draft, which is unchanged from RFC6874, summarizes the options considered the previous time round.

Regards
   Brian

> 
> Just my two cents, of course,
> 
> Ted
> 
> On Mon, Jul 5, 2021 at 10:33 AM Nico Schottelius <nico.schottelius@ungleich.ch <mailto:nico.schottelius@ungleich.ch>> wrote:
> 
> 
>     I am bit puzzled about the interface ID discussion. While I understand
>     that % inside square brackets is treated differently than outside, the
>     overall complexity still seems to be low, isn't it?
> 
>             On encountering "[ + valid IPv6 address" browsers should (must?)
>             accept an interface identifier of the form of "%string]".
> 
>     This covers automatically the integer case as well as the named network
>     interfaces. Or am I missing something?
> 
> 
> 
>     Brian Carpenter <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> writes:
> 
>     > Ted, I agree about the complexity. otoh I believe that at least one browser
>     > used to do this. How about saying that such a mechanism is not forbidden?
>     >
>     > Regards,
>     >     Brian Carpenter
>     >     (via tiny screen & keyboard)
>     >
>     > On Mon, 5 Jul 2021, 20:06 Ted Hardie, <ted.ietf@gmail.com <mailto:ted.ietf@gmail.com>> wrote:
>     >
>     >> Hi Brian, Bob,
>     >>
>     >> Your draft says:
>     >>
>     >>    In the spirit of "be liberal with what you
>     >>    accept", we also suggest that URI parsers accept bare "%" signs when
>     >>    possible (i.e., a "%" not followed by two valid and 
meaningful
>     >>    hexadecimal characters).  This would make it possible for a user to
>     >>    copy and paste a string such as "fe80::a%en1" from the output of a
>     >>    "ping" command and have it work.  On the other 
hand, "%ee1" would
>     >>    need to be manually rewritten to "fe80::a%25ee1" to 
avoid any risk of
>     >>    misinterpretation.
>     >>
>     >> I would prefer the document without this suggestion, as I think the
>     >> resulting logic for a uri parser is a good bit harder than the " 
%s are
>     >> handled differently within IPv6 literals" approach.  This requires the
>     >> parser to treat %s  differently within IPv6 literals except 
when the result
>     >> would be a "valid and meaningful" pair of hexadecimal characters.  If I
>     >> follow your logic correctly, that would mean not simply checking 
to be sure
>     >> that these are hex but also checking to be sure that the resulting
>     >> characters are within the syntax for the ZoneID production.
>     >>
>     >> I think the proposal is much cleaner without this, and I encourage you to
>     >> reconsider including it.
>     >>
>     >> regards,
>     >>
>     >> Ted Hardie
>     >>
>     >>
>     >> On Mon, Jul 5, 2021 at 3:41 AM Brian E Carpenter <
>     >> brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> wrote:
>     >>
>     >>> Hi,
>     >>>
>     >>> In case people aren't aware, no web browser that we know of supports
>     >>> RFC6874, i.e. the extension to URI/URL syntax for a link-local
>     >>> zone index in literal IPv6 addresses. This is annoying in several
>     >>> use cases.
>     >>>
>     >>> This new draft tackles what seems to be the main objection from
>     >>> the browser community, namely that RFC6874 requires browsers to
>     >>> remove the zone index before sending the URL out in a standard
>     >>> HTTP message. That's a coding annoyance and it also breaks HTTP/1.1
>     >>> rules for the "Host" header according to RFC7230.
>     >>>
>     >>> There's background to this issue at:
>     >>> https://bugzilla.mozilla.org/show_bug.cgi?id=700999 <https://bugzilla.mozilla.org/show_bug.cgi?id=700999> (still live but
>     >>> officially closed WONTFIX) and
>     >>> https://github.com/whatwg/url/issues/392 <https://github.com/whatwg/url/issues/392>
>     >>>
>     >>> The new draft proposes to update the RFC accordingly. The changes
>     >>> are relatively small but significant. There's a diff between the
>     >>> RFC and this draft at:
>     >>>
>     >>> https://www.cs.auckland.ac.nz/~brian/Diff-rfc6874-draft-carpenter-6man-rfc6874bis-00.html <https://www.cs.auckland.ac.nz/~brian/Diff-rfc6874-draft-carpenter-6man-rfc6874bis-00.html>
>     >>>
>     >>> Comments welcome. If we want to go ahead with this fix, we will 
need to
>     >>> reach out to the URI specialists and the browser community, to be sure
>     >>> it isn't a waste of time.
>     >>>
>     >>> Regards
>     >>>      Brian & Bob
>     >>>
>     >>>
>     >>> -------- Forwarded Message --------
>     >>> Subject: I-D Action: draft-carpenter-6man-rfc6874bis-00.txt
>     >>> Date: Sun, 04 Jul 2021 19:10:13 -0700
>     >>> From: internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>
>     >>> Reply-To: internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>
>     >>> To: i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>
>     >>>
>     >>>
>     >>> A New Internet-Draft is available from the on-line Internet-Drafts
>     >>> directories.
>     >>>
>     >>>
>     >>>         Title        
   : Representing IPv6 Zone Identifiers in Address
>     >>> Literals and Uniform Resource Identifiers
>     >>>         Authors         : Brian Carpenter
>     >>>                           Robert M. Hinden
>     >>>         Filename        : draft-carpenter-6man-rfc6874bis-00.txt
>     >>>         Pages        
   : 10
>     >>>         Date        
    : 2021-07-04
>     >>>
>     >>> Abstract:
>     >>>    This document describes how the zone identifier of 
an IPv6 scoped
>     >>>    address, defined as <zone_id> in the IPv6 Scoped Address Architecture
>     >>>    (RFC 4007), can be represented in a literal IPv6 address and in a
>     >>>    Uniform Resource Identifier that includes such a literal address.  It
>     >>>    updates the URI Generic Syntax specification (RFC 3986) accordingly,
>     >>>    and obsoletes RFC 6874.
>     >>>
>     >>>
>     >>> The IETF datatracker status page for this draft is:
>     >>> https://datatracker.ietf.org/doc/draft-carpenter-6man-rfc6874bis/ <https://datatracker.ietf.org/doc/draft-carpenter-6man-rfc6874bis/>
>     >>>
>     >>> There is also an HTML version available at:
>     >>> https://www.ietf.org/archive/id/draft-carpenter-6man-rfc6874bis-00.html <https://www.ietf.org/archive/id/draft-carpenter-6man-rfc6874bis-00.html>
>     >>>
>     >>>
>     >>> Internet-Drafts are also available by anonymous FTP at:
>     >>> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
>     >>>
>     >>>
>     >>> _______________________________________________
>     >>> I-D-Announce mailing list
>     >>> I-D-Announce@ietf.org <mailto:I-D-Announce@ietf.org>
>     >>> https://www.ietf.org/mailman/listinfo/i-d-announce <https://www.ietf.org/mailman/listinfo/i-d-announce>
>     >>> Internet-Draft directories: http://www.ietf.org/shadow.html <http://www.ietf.org/shadow.html>
>     >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
>     >>>
>     >>> --------------------------------------------------------------------
>     >>> 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>
>     >>> --------------------------------------------------------------------
>     >>>
>     >>
>     > --------------------------------------------------------------------
>     > 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>
>     > --------------------------------------------------------------------
> 
> 
>     --
>     Sustainable and modern Infrastructures by ungleich.ch <http://ungleich.ch>
>