Re: Next steps for rfc6874bis

[David Farmer <[e-mail]>]

I’m probably about as enthusiastic as Nick is for actually changing the
delimiter. However, I think it is premature to take any valid solution off
the table until we have had a conversation with the browser people. If
there was an easy answer to this, it would have been solved by now.

At this point, taking any valid option off the table is more likely to lead
to another failed attempt, than lead to a successfully outcome. And,
however much I dislike it, changing the delimiter is a valid option. In my
opinion the only thing worse that changing the delimiter, is another failed
attempt to fix this.

We need to get it right this time, whatever the solution is, so be it.

Thanks.

On Wed, Aug 11, 2021 at 21:20 Brian E Carpenter <[e-mail]>
wrote:

> Hi Michael,
> On 12-Aug-21 02:28, Michael Richardson wrote:
> >
> > Brian E Carpenter <[e-mail]> wrote:
> >     >> Brian E Carpenter wrote on 01/08/2021 23:17:
> >     >>> During the original discussion in 2012, and again recently, it
> was
> >     >>> suggested to change the delimiter from "%" to something else.
> (The
> >     >>> discussion in 2012 suggested "-", e.g. http://[fe80::abcd-en1].)
> >     >>> This was rejected in 2012 because it "Requires all IPv6 address
> >     >>> literal parsers and generators to be updated in order to allow
> simple
> >     >>> cut and paste; inconsistent with existing tools and practice."
> >     >>>
> >     >>> Do we want to revisit this?
> >     >>
> >     >> Definitely, but can we deal with more tractable issues first, e.g.
> >     >> global warming, slaac vs dhcpv6, world peace, etc?
> >
> >     bc> Since nobody has argued against Nick, can we put this issue to
> one
> >     bc> side (as we did 9 years ago)? If we do that, we can have a fairly
> >     bc> straightforward discussion with the URI and browser community,
> >     bc> focusing entirely on % vs %25.
> >
> > I disagree.
> > I think that changing the delimiter should be on the table in the
> discussion.
> > If the browser community doesn't like it, then fine, but let's let the
> group
> > make the decision.
>
> OK, but maybe we should update the draft to state that clearly as an
> open issue.
>
> >
> > My argument is:
> >
> > 1) in order to maintain cut&paste, if we do %25, then we have to change
> >    everything anyway.
>
> I agree; it would be wonderful if the browser implementors could deal
> with a non-encoded % but that is unclear right now.
>
> > 2) people using command-line tools probably can cope with swapping around
> >    stuff in the short-term.
>
> Certainly it's better than no way of using a browser at all.
>
> > 3) On GNU-Linux glibc systems, it's probably an update to getaddrinfo()
> only.
> >    A new character is probably easier to put in than %25.
>
> Much easier. I would never envisage supporting percent-encoding in
> the socket API.
>
> >    That could happen really quickly.
>
> I'm not convinced. Across all o/s and all libraries? Quickly?
>
> > Of course, it doesn't have to stop
> >    understanding %.
> >    Ditto BSD systems.  Few utilities parse that stuff themselves.
>
> I agree, although in my GRASP code, I needed to parse it on Windows
> until a fairly recent Python change. And in Posix systems, it has
> to be done too. GRASP is very dependent on getting link-local
> stuff right.
>
> > 4) If we'd started in 2012, we'd already be done.  We don't have
> >    interoperability now anyway.
> >
> > [I abhor %25, btw]
> >
> > --
> > Michael Richardson <[e-mail]>   . o O ( IPv6 IøT
> consulting )
> >            Sandelman Software Works Inc, Ottawa and Worldwide
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
-- 
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================