Subject: Status of draft-carpenter-6man-rfc6874bis

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Oct 2021 08:29:31 +1300

Hi 6man,

We haven't updated draft-carpenter-6man-rfc6874bis for IETF 112.
As discussed previously, we contacted various people in the
browser implementation community for their feedback. A short
summary is that they are open to discussion, but do not see
significant user pressure for support of link-local address
literals. To quote one reply it "is complex to gauge implementor
interest and user need." In particular, in the case of open
source browsers, there is a need for implementors with the right
expertise to be willing to spend time on this.

As a hobby project, I (Brian) patched the wget utility to
support 6874bis on Linux, and it proved quite easy, supporting
both %zoneid and %25zoneid. See https://github.com/becarpenter/wget6 .
(The patch has not been submitted to the wget developers.) Also,
curl already supports the %zoneid format, at least on Linux
and cygwin.

However, I had a look at the Firefox source and it is not
so simple, with multiple modules in several programming
languages apparently being involved. Only a Firefox developer
with a good knowledge of all aspects of URL handling could
figure this out.

Our dilemma at the moment is whether it is worth the effort
of proceeding with 6874bis with no assurance that the browser
community would implement the result. The alternative, bluntly,
is to give up and declare RFC6874 obsolete. (Today, it is
only supported in an obsolete browser, namely Internet Explorer.)

Feedback from the WG would be welcome.
   
Regards
     Brian Carpenter & Bob Hinden

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 27 Oct 2021 20:40:14 +0100

> only supported in an obsolete browser, namely Internet Explorer.)

The rfc + update are a nice-to-have, and not contentious. I don't see 
any reason not to proceed with the update.  If it's not specified, then 
we can be ~guaranteed that the browser won't support it.  If it is 
there, they might support it in time, or if someone with money comes 
along and requests it. Overall, it's a win and gets my support.

Nick

---

From: Bob Hinden <[email-masked]>
Date: Wed, 27 Oct 2021 12:48:30 -0700

Nick,

> On Oct 27, 2021, at 12:40 PM, Nick Hilliard <[email-masked]> wrote:
> 
> The rfc + update are a nice-to-have, and not contentious. I don't see any reason not to proceed with the update.  If it's not specified, then we can be ~guaranteed that the browser won't support it.  If it is there, they might support it in time, or if someone with money comes along and requests it. Overall, it's a win and gets my support.

I agree (and I am a co-author).

We (for some value of we) can submit updates to open source utilities like wget once an updated RFC is published.   Hopefully the browser community will add support later when they revise their URL parsers.

Bob

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 28 Oct 2021 08:28:51 +0000

Hi all,
The proper question is "does the support of such a feature is needed for protocol stack completeness?"
IMHO: needed.
Then some active RFC SHOULD be.
Even in the case that nobody would implement it.
The standards package should be consistent.
If somebody would decide to implement it later - the solution is better to have already standardized.

It is just very important to guess what delimiter is the best for this purpose.
Only very experienced software professionals could make a good guess.
Eduard
-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden
Sent: Wednesday, October 27, 2021 10:49 PM
To: Nick Hilliard <[email-masked]>
Cc: IPv6 List <[email-masked]>; Bob Hinden <[email-masked]>
Subject: Re: Status of draft-carpenter-6man-rfc6874bis

Nick,

>> Our dilemma at the moment is whether it is worth the effort of 
>> proceeding with 6874bis with no assurance that the browser community 
>> would implement the result. The alternative, bluntly, is to give up 
>> and declare RFC6874 obsolete. (Today, it is only supported in an 
>> obsolete browser, namely Internet Explorer.)
> 

Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 29 Oct 2021 10:33:58 +1300

> Only very experienced software professionals could make a good guess.

I don't claim expertise, but from (a) patching the wget URL parser (b) testing
the curl parser and (c) having a look at the Firefox code, I am pretty sure
that pretty much any delimiter could be made to work, including a plain %.

I did not find an ABNF-driven parser in either wget or Firefox, by the way.

My inclination at the moment would be to recommend the plain % (and Andrew
Cady supplied corresponding ABNF a while back.) As the wget example shows,
it is perfectly possible for a URL parser to accept both % and %25, in case
the incoming string happens to have been percent-encoded.

    Brian

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 29 Oct 2021 00:07:23 +0200

On 2021-10-27, at 21:29, Brian E Carpenter <[email-masked]> wrote:
> 
> supporting
> both %zoneid and %25zoneid. 

I can’t parse this.

What does %256 mean?  Zone 256 or zone 6?

Grüße, Carsten

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 29 Oct 2021 11:31:05 +1300

> What does %256 mean?  Zone 256 or zone 6?

That depends, unfortunately. To Internet Explorer, it means zone "6" (string) whose zone index is 6 (integer). I believe that to the wget parser, it would be the same, but %2g6 would mean zone "2g6" (string) whose zone index would come from getaddrinfo(). wget does what RFC6874 suggested: if 
"%" is followed by two hex characters, it assumes percent-encoding, but not otherwise. There is a short essay on this topic as a comment in the wget source code.

curl (on cygwin) treats %256 and %6 identically, but from a few more tests its parsing is very primitive.

% was really not a good choice by RFC4007, but we are stuck with it, I fear.

    Brian

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 29 Oct 2021 00:34:14 +0200

On 2021-10-29, at 00:31, Brian E Carpenter <[email-masked]> wrote:
> 
> if "%" is followed by two hex characters, it assumes percent-encoding, but not otherwise. 

I was hoping we could get rid of that.

Grüße, Carsten

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 29 Oct 2021 16:47:00 +1300

> I was hoping we could get rid of that.

Indeed, we took that out of the 6874bis draft. I was quite surprised to find it actually implemented in wget, but it's a side effect of their general algorithm to handle percent-encoding.

You can invent some interesting constructs like %252525, which is why RFC3986 says:
   "Implementations must not
    percent-encode or decode the same string more than once, as decoding
    an already decoded string might lead to misinterpreting a percent
    data octet as the beginning of a percent-encoding, or vice versa in
    the case of percent-encoding an already percent-encoded string."

      Brian

---

From: Michael Richardson <[email-masked]>
Date: Fri, 29 Oct 2021 10:49:51 -0400

> the incoming string happens to have been percent-encoded.

It seems that we've been down this road already: you've concluded on the
status quo.

wget/curl are not firefox/chrome with what the maintainers claim is a
complicated Location/Search bar logic.  No, it's not ABNF driven, which is
why it's a problem for them.   Their requirements are not expressed in a
formal language, but rather in least-surprise test cases and feedback from users.
We have a chicken and egg situation: there are no users for IPv6-LL because
it doesn't work.

{BTW: IOTOPS WG will have a presentation from ManySecured SUIB group, which
deals with security of LL connections}

We have failed to get the browser community engaged, which was a requirement
for going forward.

Did someone manage to get into a W3C teleconference with this issue?

I suggest that we simply pause: blame the pandemic travel issues, and come
back to this in a year.  Someone has to go to a W3C in-person meeting to do
hallway chats.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 30 Oct 2021 11:22:38 +1300

> It seems that we've been down this road already: you've concluded on the

Not quite. The status quo in the draft is %25zoneid, and I personally
now think that %zoneid is marginally better. But as discussed with
Carsten, zoneids that happen to start with "25" are a messy issue
either way.

> complicated Location/Search bar logic.  

Indeed. It's the mixing of URL parsing and automatic searching that
makes the Firefox code so hard for a newcomer to understand.

> No, it's not ABNF driven, which is

No. But I don't think that whatwg or W3C are the main hurdles.
  
> back to this in a year.  Someone has to go to a W3C in-person meeting to do

What people from the major browsers have told us is that the key is to
get actual open-source contributors on board. I'm not sure which
physical or virtual hallway they meet in.

      Brian

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 30 Oct 2021 09:57:47 +0200

> Carsten, zoneids that happen to start with "25" are a messy issue

Yes, and decisive action is needed to improve on that situation.
Let’s deprecate %25 with some stout language.

(BTW, W3C probably is irrelevant here, the browser vendors are relevant, and their venue is WHATWG.)

Grüße, Carsten

---

From: Philip Homburg <[email-masked]>
Date: Sun, 31 Oct 2021 22:29:50 +0100

> Lets deprecate %25 with some stout language.
> 

If we make it just '%' then there is probably a lot more software that needs
to be tested. It would be a pity if such URLs can't be stored because some
popular library rejects it as invalid.

Of course, if we expect that the only use of these URLs is to be typed into 
a browser, talking to the browser vendors would be enough.