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

[Andrew Cady <[e-mail]>]

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.

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.