[w3ctag/design-reviews] updated URI syntax for IPv6 link-local zone identifiers (Issue #774)

Wotcher TAG!

I'm requesting a TAG review of "Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers" ([draft-ietf-6man-rfc6874bis](https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6874bis/)).

# Explainer

From the abstract:

>    This document describes how the zone identifier of an IPv6 scoped
>   address, defined as <zone_id> in the IPv6 Scoped Address Architecture
>   (RFC 4007), can be represented in a literal IPv6 address and in a
>   Uniform Resource Identifier that includes such a literal address.  It
>   updates the URI Generic Syntax and Internationalized Resource
>   Identifier specifications (RFC 3986, RFC 3987) accordingly, and
>   obsoletes RFC 6874.

This IETF draft proposes updating URI/IRI `IP-literal` syntax as follows:

>      IP-literal = "[" ( IPv6address / IPv6addrz / IPvFuture  ) "]"
>
>      ZoneID = 1*( unreserved )
>
>      IPv6addrz = IPv6address "%" ZoneID

in order to help ensure adoption within browsers and other tools.  One goal is to ease use of IPv6 link-local address literals in browsers when/where on-link device configuration is being performed.

This is a clarification and, importantly, simplification of [RFC 6874](https://datatracker.ietf.org/doc/html/rfc6874).

# Specification

The latest version of this draft can be found at [https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc6874bis](https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc6874bis).

# Tests

None of the kind TAG might expect.  With respect to implementation, at a minimum, a [patch to wget](https://github.com/becarpenter/wget6) to support this change exists.

# User research

[Section 2](https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc6874bis-02#section-2) and [Section 4](https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc6874bis-02#section-4) of [draft -02](https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc6874bis-02) capture observations of IP address literal parsers and use (or lack thereof) currently.  This forms part of the motivation for this document.

# Security and Privacy self-review

[Section 5](https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc6874bis-02#section-5) of [draft -02](https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc6874bis-02) covers security and privacy considerations.

# Primary contacts

- Brian E Carpenter ([becarpenter](https://github.com/becarpenter))
- Jen Linkova ([furry13](https://github.com/furry13))
- Erik Kline ([ekline](https://github.com/ekline))

# Organization

This document is a product of the [IETF](https://ietf.org) IPv6 Maintenance working group ([6man](https://datatracker.ietf.org/wg/6man/about/)).

# Key pieces of review

This document updates the `IP-literal` ABNF specification of URIs/IRIs.  As such, any feedback on the correctness or additional thoughts on the document in general would be very much appreciated.

# External trackers

* The document status tracker [here](https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6874bis/)

# Further details:

  - [X] I have reviewed the TAG's [Web Platform Design Principles](https://www.w3.org/TR/design-principles/)
  - Relevant time constraints or deadlines: before the end of September, 2022
  - The group where the work on this specification is currently being done: [IETF 6man working group](https://datatracker.ietf.org/wg/6man/about/)

We'd prefer the TAG provide feedback as (please delete all but the desired option):

  💬 leave review feedback as a **comment in this issue** and @-notify [becarpenter](https://github.com/becarpenter), [furry13](https://github.com/furry13), [ekline](https://github.com/ekline)




-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/774

You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/774@github.com>