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

Andrew Cady <andy@cryptonomic.net> Tue, 06 July 2021 16:09 UTC

Return-Path: <andy@cryptonomic.net>
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 89AFE3A2CF2 for <ipv6@ietfa.amsl.com>; Tue, 6 Jul 2021 09:09:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 1lKBUQCpDonL for <ipv6@ietfa.amsl.com>; Tue, 6 Jul 2021 09:09:29 -0700 (PDT)
Received: from zukertort.childrenofmay.org (zukertort.childrenofmay.org [IPv6:2607:5300:201:3100::27b7]) by ietfa.amsl.com (Postfix) with ESMTP id D4D173A2D16 for <ipv6@ietf.org>; Tue, 6 Jul 2021 09:09:26 -0700 (PDT)
Received: by zukertort.childrenofmay.org (Postfix, from userid 1000) id 837F7F2DE5C; Tue, 6 Jul 2021 12:09:26 -0400 (EDT)
Resent-From: Andrew Cady <andy@childrenofmay.org>
Resent-Date: Tue, 6 Jul 2021 12:09:26 -0400
Resent-Message-ID: <20210706160926.jxgaqxd5pw4kjn26@zukertort.childrenofmay.org>
Resent-To: 6MAN WG <ipv6@ietf.org>
Date: Tue, 6 Jul 2021 12:00:27 -0400
From: Andrew Cady <andy@cryptonomic.net>
To: 6MAN WG <ipv6@ietf.org>
Subject: Re: I-D Action: draft-carpenter-6man-rfc6874bis-00.txt
Message-ID: <20210706160027.cexcl2b6vxqkducz@zukertort.childrenofmay.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> <01289d8c-a470-1867-448f-3d616647ba5f@gmail.com> <87bl7flww8.fsf@ungleich.ch> <6771.1625578366@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6771.1625578366@localhost>
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/W6jsffHHSSqeQwY5y6iCN_X_9_8>
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 16:09:40 -0000

On Tue, Jul 06, 2021 at 09:32:46AM -0400, Michael Richardson wrote:
> 
> Nico Schottelius <nico.schottelius@ungleich.ch> wrote:
>     > While copy & paste won't work with this proposal, I believe the %25
>     > escape should be "good enough" for most daily usage.
> 
> Also, ping and/or getaddrinfo() could become tolerant of %25 as a special
> case (and given that few Windows machines have 25 interfaces), which would
> let the copy&paste work the other way.

I stated in another message today:

  The unfixable problem for implementors is where to strip the
  redundantly-added "25".  The URL fragment needs to move like this:

    1.User --> 2.Location Bar --> 3. Web client --> 4.Web server --,
                                                                   |
                                         ,-- 5.Web application <---'
                                         |
                                         .------------------,
                                                            |
    8.User <-- 7.UA rendered content <-- 6.Web client <-----'

  If a point of mangling is specified, then a corresponding point of
  de-mangling must be specified.  Neither have been properly specified.





You are proposing de-mangling occur at (8).

Where should mangling occur?





Should it not occur at (1) to match?  Thus a {1,8} solution!  I had not
considered that!

In that case, no implementation of software need mangle any name.  We
rely on the user to provide the mangling AND the de-mangling.

* Require the user to strip "25" from browser output.
* Require the user to input "25" as browser input.

The symmetry is beautiful.

Acceptable?

Is there any name or address NOT supported by the {1,8} solution?