こんにちは TAG-さん!

I'm requesting a TAG review of Entering IPv6 Zone Identifiers in User Interfaces.

This document describes how the zone identifier of an IPv6 scoped address, defined in the IPv6 Scoped Address Architecture (RFC 4007), should be entered into a user interface. It obsoletes RFC 6874.

• Explainer: https://datatracker.ietf.org/doc/html/draft-ietf-6man-zone-ui-02
• Specification URL: https://datatracker.ietf.org/doc/html/draft-ietf-6man-zone-ui-02
• Tests: n/a
• User research: none
• Security and Privacy self-review: see below
• GitHub repo: none
• Primary contacts:
  • Brian Carpenter (@becarpenter), Editor
  • Bob Hinden (@bobhinden), Editor
  • Erik Kline (@ekline), Responsible Area Director
• Organization(s)/project(s) driving the specification: see below
• Key pieces of multi-implementer support: see below
• External status/issue trackers for this specification:

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: According to editors, a last call is imminent in the next few weeks.
• The group where the work on this specification is currently being done: 6man IETF Working Group
• Major unresolved issues with or opposition to this specification: see below
• This work is being funded by: ?

You should also know that...

tl;dr: This reverts a proposed change to URL syntax that, while it was published in RFC 6874, never gained any real standing in Web standards. What was a concrete proposal for how to express zone identifiers in URLs would revert to a state of having absolutely no specification. Consequently, there would be no standardized way to identify the applicable zone when identifying a resource that as an IPv6 literal for a host. The document suggests a syntax for expressing IPv6 literals in some user interfaces, but it completely avoids those that involve URLs.

This is a bit of an irregular request, but it would be worthwhile getting the TAG's input on this subject. Given where things are, that might be as simple as "yeah OK", but the exercise of writing this out and discussing the situation seems worth doing.

RFC 6874 attempted to modify URL syntax in a way that was not strictly backward compatible. This was to introduce a feature of IPv6 addressing that is not widely used and is largely limited to private networks.

The zone identifier is a host-local identifier for a network interface that is sometimes necessary to disambiguate a non-global or non-unique IPv6 address. For instance, the address "fe80::1" is a "link-local" address that can be assigned to a different host on different network segments. A host that has multiple interfaces might participate in networks that use the same address. A zone identifier is appended to addresses to disambiguate them. Continuing the example, "fe80::1%wifi" or "fe80::1%9" might be used.

Zone identifiers only have local significance, so there is no consistent way to use them on the Web, but RFC 6874 nevertheless tried to change URI syntax to include a zone identifier. The idea was to let people type in a disambiguated address so that they were able to reach the intended host.

The problems with this approach took a long time to identify, but you can see some of that from the discussion on the WHATWG URL spec. Picking a few:

• One does not simply change URL syntax. Some effort was made to identify places where code was intolerant of the extra characters, but the way in which this potentially touches a whole.
• The rules for case-folding seem to be incompatible with RFC 3986.
• The effect of this on what we understand to form the Origin tuple is unclear.
• Who needs to receive this information and handle it is unclear if it is used outside of user interfaces. The identifiers for zones only make sense on a single computer, so content cannot use them in any coherent manner.

Of note is this draft that recommends the use of .local names instead. This resolves the interface issues by using a name, which could be unique. Unfortunately, that requires the use of mDNS, which is not supported enough to be consistently available.

All of which is to say that this has been a contentious problem to resolve. Some people (full disclosure: I'm one of them) think that maybe zone identifiers were a mistake. Others are frustrated that you can't type (or copy-paste) a qualified IPv6 address into a browser and have it work. (These are also mutually compatible positions.)

The proposal recognizes more formally the distinction between identifying a zone locally, which is largely a user interface choice, while specifying a convenient syntax. That syntax is available for use in any given context, but whether the syntax is adopted will need to depend on the context.

That is, the specification proposes a convenience for user interface, but does not seek to establish a new format that can be used in protocols. Personally, I have some concern that this distinction might be lost on some of the audience, which might result in undesirable results.

URLs are an important context where IPv6 literals are used. The document is silent when it comes to URLs, except to say that the URL syntax proposed in RFC 6874 is obsolete.

For a command-line tool that handles URLs, you might imagine something much more like wget --interface eth0 https://[fe80::1]/ than what was originally proposed with wget https://[fe80::1%eth0]/ (despite Brian having code that quite trivially makes that possible). Neither of those forms is explicitly considered. The idea is that any given interface (command-line or otherwise) would need to decide for itself how it wanted to operate.

Questions the TAG might consider answering:

• Is this a generally acceptable direction?
• Is the distinction between user interface and protocol format clear enough?
• Does the use case of "entering a scoped IPv6 literal into a browser" make sense?
• Does this use case warrant further work to support it on the Web platform?
• Does the mDNS approach make more sense?