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

[Ted Hardie <[e-mail]>]

Hi Andrew,

A short reply in-line.

On Tue, Jul 6, 2021 at 4:26 PM Andrew Cady <[e-mail]> wrote:

> On Mon, Jul 05, 2021 at 11:08:24AM +0100, 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.
>
> That is a bug.  The '%' must be treated as the syntactic delimiter it is.
>
>
My apologies; it appears that I didn't get my intent across.  Let me try to
rephrase.  Because of a collision between the defined zone-id scope-id
separator and the URI syntax, this proposal percent encodes the zone-id
separator, and updates the URI syntax to permit the percent-encoded zone-id
separator to be included in the IP literal syntax.

Since this update RFC 3986, this would be permitted if this is approved,
even though this is a change from RFC 3986.

I hope that remedies any lack of clarity on my part,

regards,

Ted


> We don't encode the '[' or the ':' either.  We only allow
> percent-encoding in the percent-decoded data parts of the URI.  The '%'
> is a delimiter between two separate data parts.  It is not a data part.
> The user cannot input different values there.
>
> No other percent-encoded character is allowed there.  It is not a data
> part!  It is a constant, not a variable!  It is not a percent-decoded
> component!
>
> You are not allowed by RFC3986 to treat it as a data part, because that
> document states correctly that it is not one.
>
>
>
>
> Please remember two facts and a corollary that I posted here last week:
>
>   1.  RFC3986 says percent-decoding is done AFTER parsing into components
>       and subcomponents
>
>   2.  The IPv6 literal subcomponent is NOT percent-encoded.
>
>   2a. No percent-decoding is done (or allowed) on this parsed subcomponent.
>
> (Ref:<
> https://mailarchive.ietf.org/arch/msg/ipv6/FPLeDZXqJ1zwE1yF_Qkh7Ldq120/>)
>
>
>
>
>
>
> The technical question before us is whether to put a percent-encoded
> character into a non-percent-decoded field!
>
>
>
>
>
>
> 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.
>
>
>
>
> I claim ONLY if the fragment is mangled at 3 and de-mangled at 4, then
> it can be made to work with the full range of addresses.  Mangle at the
> latest possible chance, unmangle at the first possible chance.  Thus
> protecting the user AND the developer of the web application AND the
> developer of the OS insofar as the web application developer depends on
> the OS interface.
>
> In the case of {3,4} mangling is harmless -- but serves no purpose.
>
> I claim no other choice of mangle/de-mangle locations even works.
>
> Note: It is NOT acceptable to require the user to handle any mangling or
> de-mangling at 1 or 8.
>
>
>
>
>
>
>
> >    Other
> >    approaches, such as a bare percent symbol within the square brackets
> >    have been rejected (see the long Mozilla bug thread Brian posted).
>
> That Mozilla bug thread explains the correct approach to the scopeid
> parsing in comment 39:
> https://bugzilla.mozilla.org/show_bug.cgi?id=700999#c39
>
>
>         heinz.repp
>         Comment 39 • 5 years ago
>
>         (In reply to Brian  E Carpenter from comment #38)
>         > But the real objection from
>         > the browser side is that it's a horrible thing to implement.
>
>         I know, this stems from Ryan Sleevi's 2015 comment, but having
>         some experience in networks and C programming for decades I can
>         hardly understand this. I see only 2 distinct jobs here:
>
>         1. expand the parser of the url-decoded URI that already can
>         parse IPv6-address-raw: instead of
>
>         IPv6-literal = '[', IPv6-address-raw, ']';
>
>         parse
>
>         IPv6-literal = '[', IPv6-address-raw, [ '%', IPv6-scope-id ], ']';
>         IPv6-scope-id = '0'-'9' | 'a'-'z' | 'A'-'Z', { '0'-'9' | 'a'-'z' |
> 'A'-'Z' | ' ' | '_' | '-' };
>
>         difficulty: 'create your own parser' course, beginner's lesson
>
>
>
>
> This is the ONLY correct implementation because it is the ONLY
> implementation that guarantees that information is not lost in between
> the user and the server.  We do not need a special case that loses
> information here.  That loss is simply a bug.  A standard that mandates
> a bug itself has a bug.
>
> We simply need to fix the bug to get implementation.  The bug cannot be
> accepted.  The bug must be removed from all existing standards.
>
> We cannot allow some other standard to block this standard that blocks
> the software bugfix: instead, the bug in the software must be fixed, so
> that all standards mandating the bug must surrender their priority to
> the need to fix the software bug itself.
>
> Any standard that claims to have higher priority than fixing the bug in
> the code must be laughed at by the gods and looked at with suspicion by
> mortals.
>
> >    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.  The one correct solution is to fix the percent-encoding bug
> entirely.  It does not make sense to try to support any mangling.
>
> However, isn't this just about Microsoft, and theirs the sole broken
> name-mangling implementation?  Is it just Microsoft here demanding that
> everyone else match their bug?  Just one firm?
>
> Then let Microsoft ignore the standard -- do not let them ruin it.
> Their browser can be the one we call confusingly different.  It cannot
> be allowed to lead.
>
> Name-mangling is wrong.  It is anti-user.  It does not serve any user
> interest.  It is an "anti-feature."
>
> Name-mangling cuts off the user from access to software written by many
> developers.
>
> Name-mangling breaks much software written behind the web server _and_
> potentially software written behind the /etc/nsswitch.conf module
> system, which allows great diversity of supply of names into the system.
>
> That is a system that allows developers to plug in their own new
> implementations of new ideas.  Don't try to take that away!
>
>
>
>
>
> # Solution to Problem #
>
> The way to fix port 80 is to abolish the name-mangling middle-man
> forever.
>
> Let the server know exactly what the browser's location bar says.
> Let the user tell the location bar exactly what the user will.
> Make the unbroken user<->server bond a requirement of HTTP.
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>