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

Ted Hardie <ted.ietf@gmail.com> Mon, 05 July 2021 10:08 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 829903A10D4 for <ipv6@ietfa.amsl.com>; Mon, 5 Jul 2021 03:08:59 -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, 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 EHi9hKEUit3Q for <ipv6@ietfa.amsl.com>; Mon, 5 Jul 2021 03:08:52 -0700 (PDT)
Received: from mail-oo1-xc2b.google.com (mail-oo1-xc2b.google.com [IPv6:2607:f8b0:4864:20::c2b]) (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 1012A3A10D0 for <ipv6@ietf.org>; Mon, 5 Jul 2021 03:08:51 -0700 (PDT)
Received: by mail-oo1-xc2b.google.com with SMTP id i26-20020a4ad39a0000b02902554d87361cso1070612oos.13 for <ipv6@ietf.org>; Mon, 05 Jul 2021 03:08:51 -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=EWnnSo1czF5xgORuz+bH8Dh/VvX/LI1NXmawC8V/23Y=; b=PXV2g9+SrPBhozRY8Dq/wjBUYhq6lxnA0A5YtCD8ZfsKFTyF7UTrcycQ1G3yyo8IqN ztcMtBkRYw80cOL+Awypp9GQQIDaTbgHk2OYLCf3gHur3p3TuZVwbso5bVqHzKbd9vCp t3IMFvaQJbZTYWVSgnJIhrriWX+pmwZDSd4/DwJnc0iLEWU1B/DVFp+VzYf4jRlL4dc3 pfBFoARx0eCs0vbJBMjPhNiESqqYGhq2MGHxq1Zw3LTLSE0JvAuaxuRi+8nmk2z+xhqE ripqgZ8Q9QhKDqY6ft0wUaf4KvQeDCHuauL2SCmduTfhKKLFH/Pds7MVtaQnWyNOhZjn JsPg==
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=EWnnSo1czF5xgORuz+bH8Dh/VvX/LI1NXmawC8V/23Y=; b=mZuSdiw78m5CXEyRrUlGVg5xnTo16x35jX1aA4/ybPKH4LeibMyiNG4LmLsA7CjYat +TShWlWKPy/6xx94feBQ74McmhM8wLn3SsL+3VBl+Xlc94QyYeE7UQpYQsVjY/5UVUQx NYr1YhYBqlcWQ3W9GAv/oRGjrsmtGlAj2xaXqRySAFPuMpdwzxJr/059SieyBoLKy284 v8mhTekoKey+ixTvWx+QnfZAYn79PGpy+ExPqT99LP2f/tcOToRgxIM5BdCdvbQ/SNII NElX9Cvklper+lzYtjQiQX1VVT7xE2rFraIE7lWJExdrX+ekG2u46vh5J3weYOmkB60O +0Gw==
X-Gm-Message-State: AOAM532Li027JUpFbZDmhWSKfeupQZ1uRThXKJjiDg6LqcXutrVtL8ob 3Jlh+MZ6/ccNjHpnpv+/PmgRKu+J9SCvZUDC1hY=
X-Google-Smtp-Source: ABdhPJzOVYD2pWsZyMmvx0aNlnCdBjsTBfttUsnbbqtu6XRewxKFH/1hp1F0ZvJWkYpREsowyzh+t0QF9N81HYAKeRw=
X-Received: by 2002:a4a:9d47:: with SMTP id f7mr9528334ook.67.1625479730408; Mon, 05 Jul 2021 03:08:50 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <87a6n13y0j.fsf@ungleich.ch>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Mon, 5 Jul 2021 11:08:24 +0100
Message-ID: <CA+9kkMBx4F0FGZasdk11ogyCOwQZecAEkO4JbECDr4osySN-4w@mail.gmail.com>
Subject: Re: I-D Action: draft-carpenter-6man-rfc6874bis-00.txt
To: Nico Schottelius <nico.schottelius@ungleich.ch>
Cc: Brian Carpenter <brian.e.carpenter@gmail.com>, Bob Hinden <bob.hinden@gmail.com>, 6MAN WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ebb08e05c65d7d93"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/14E_kCOhx8z7DGj7G1rJ-PPgkn4>
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: Mon, 05 Jul 2021 10:09:00 -0000

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.

Just my two cents, of course,

Ted

On Mon, Jul 5, 2021 at 10:33 AM Nico Schottelius <
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> 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> 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> 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 (still live but
> >>> officially closed WONTFIX) and
> >>> 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
> >>>
> >>> 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
> >>> Reply-To: internet-drafts@ietf.org
> >>> To: 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/
> >>>
> >>> There is also an HTML version available at:
> >>>
> 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/
> >>>
> >>>
> >>> _______________________________________________
> >>> I-D-Announce mailing list
> >>> I-D-Announce@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/i-d-announce
> >>> Internet-Draft directories: http://www.ietf.org/shadow.html
> >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >>>
> >>> --------------------------------------------------------------------
> >>> IETF IPv6 working group mailing list
> >>> ipv6@ietf.org
> >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>> --------------------------------------------------------------------
> >>>
> >>
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
>
> --
> Sustainable and modern Infrastructures by ungleich.ch
>