Re: [IPv6] Fwd: I-D Action: draft-carpenter-6man-zone-ui-00.txt

[Toerless Eckert <[e-mail]>]

On Tue, Feb 20, 2024 at 04:30:41PM +1300, Brian E Carpenter wrote:
> > The draft does not explain this justification to obsolete rfc6874 at all, and at minimum you
> > should put that text into the new text if this is what will prevail.
> 
> We can, but I think everybody knows that some of the requirements in RFC 6874 were essentially impossible to implement (and it's a shame we didn't get such feedback at the time, but we didn't).

It is to me an open question whether rfc6874 was the best solution for the problem,
and if we could find fundamentally better solutions, we should of course use those.

But from all those things i have read, i can not conclude that the mayor issues
where just smaller things, such as not strict spec of the zone_id for parsers
as well as the fact that the local application should immediately remove this
local information from the pre-existing URL as opposed to proxies or other.

Of course, that local transformation of the URL then gets to the core point of whether
it would be better to appropritely separate that local vs. remote URL information in
a different way.

> > However, i do not buy the argument. URIs are becoming a generic way to pass API parameters,
> > in modern programming enviroments and it is trivial for a recipient to ignore it.
> > If we can not represent LL addresses with zone EVERYWHERE where we can represent a global
> > IPv6 address, then we're just making it less usable and force more than necessary
> > global address allocation/management. So i am totally against eliminating LL representation
> > in URI. I am fine with updating and better justifying it though.
> 
> But there is a fundamental issue with putting "fe80::1%junk" on the wire, because it is specified by RFC4007 to be *meaningless* outside the originating host. And for the same reason, "fe80::1" is explicitly *ambiguous* inside the originating host. Confront the browserland concept of "origin" that ekr mentioned with those facts and, quite honestly, there appears to be an insoluble problem if we try to solve the problem at the URI level.

I think we are not talking arbitrary URI, but URL. 

But yes, if you have an encoding scheme where you need to separate local from remote
information then rfc4007 isn't ideal. But that does not mean we could not come up with
something better, right ?

> (The problem seems just as bad for IPv4 link-local addresses; it's just hidden by the lack of an RFC 4007 for IPv4.)

Sure.

> I am still not convinced that browsers couldn't handle this as a UI issue, despite the undoubted complexities.

The main issue is that IMHO UI is the wrong term to scope the work.
No normal user should ever need to deal with IP/IPv6 addresses anyhow.

In fact, a normal user may rather have to deal with a zone_id and a DNS name to
force using a particular interface than to use an IPv6 address.

But tthn there are poor users called operators that have to deal with routers, where
reasonably you can not always rely on DNS, but where also zone index are used (which we have not
resolved),

Ad finally, and i think this is the foremost type of use-case, we're talking about any form of
m2m software, where if you can, you will also want to avoid dependencies against DNS,
but where REST / URLs are also the common way to communicate.

Cheers
    toerless
> 
>     Brian
> 
> > Note that the problems of contextual limitations also exist for NAT'ed addresses (without
> > zones) (which also existin IPv6), and relative domain names.
> > 
> > Cheers
> >      Toerless
> > 
> > > (I see there's a comment further down the thread from Michael Sweet, so I will leave my comment about the CUPS use case for that.)
> > > > 
> > > > Also, this document seems to accept the necessity of allowing a different delimiter other than "%" and RECOMMENDS "-" as an alternative delimiter. Why not just change the delimiter in RFC6874bis to "-"?
> > > > 
> > > > I realize that the "%" delimiter isn't the only issue with RFC6874bis, but that seems to be one of the biggest issues.
> > > 
> > > The parsing problem is relatively simple; in the limit I agree, we could have changed the delimiter. However, the CORS issue was far deeper and harder to overcome. RFC6874 actually avoided that issue by specifying that the URI would be rewritten on the wire, but that was also unacceptable to the Web people. I was thinking about that when I realised that the real problem was a UI problem.
> > > > Also, maybe we should consider alternatives to IPv6 Link-Local Literals with Zone Identifiers, such as encouraging the use of mDNS to discover the HTTP services for the initial configuration page of a router or their device with only a link-local address.
> > > 
> > > That's a different issue, though. I personally won't work on it, but it sounds like a good thing to do.
> > > 
> > >     Brian
> > > 
> > > > 
> > > > Thanks
> > > > 
> > > > On Mon, Jan 15, 2024 at 1:57 PM Brian E Carpenter <[e-mail] <mailto:[e-mail]>> wrote:
> > > > 
> > > >      Hi,
> > > > 
> > > >      As the WG may have noticed, draft-ietf-6man-rfc6874bis has been stuck in the IESG since March 2023, despite multiple revisions and discussions with the ADs and other objectors, particularly those in the W3C and browser (WHATWG**) communities.
> > > > 
> > > >      We (Brian and Bob) have reluctantly concluded that the disconnects on this topic between the IETF, the W3C and WHATWG are such that an acceptable compromise cannot be reached.
> > > > 
> > > >      We therefore propose to transform the discussion by withdrawing rfc6874bis and RFC6874, and replacing them by a generic requirement that when a user interface supports the input of IPv6 addresses, it MUST support the input of link-local addresses with interface IDs (a.k.a. zone IDs). How any particular software tool does this is a choice for its implementer.
> > > > 
> > > >      A first draft has just been submitted, please comment. It intentionally makes no reference whatever to browser or other web issues.
> > > > 
> > > >      Regards
> > > >             Brian Carpenter
> > > >             Bob Hinden
> > > > 
> > > > 
> > > >      -------- Forwarded Message --------
> > > >      Subject: I-D Action: draft-carpenter-6man-zone-ui-00.txt
> > > >      Date: Mon, 15 Jan 2024 11:51:18 -0800
> > > >      From: [e-mail] <mailto:[e-mail]>
> > > >      Reply-To: [e-mail] <mailto:[e-mail]>
> > > >      To: [e-mail] <mailto:[e-mail]>
> > > > 
> > > >      Internet-Draft draft-carpenter-6man-zone-ui-00.txt is now available.
> > > > 
> > > >           Title:   Entering IPv6 Zone Identifiers in User Interfaces
> > > >           Authors: Brian Carpenter
> > > >                    Robert M. Hinden
> > > >           Name:    draft-carpenter-6man-zone-ui-00.txt
> > > >           Pages:   7
> > > >           Dates:   2024-01-15
> > > > 
> > > >      Abstract:
> > > > 
> > > >           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.
> > > > 
> > > >      Discussion Venue
> > > > 
> > > >           This note is to be removed before publishing as an RFC.
> > > > 
> > > >           Discussion of this document takes place on the 6MAN mailing list
> > > >           ([e-mail] <mailto:[e-mail]>), which is archived at
> > > >      https://mailarchive.ietf.org/arch/browse/ipv6/ <https://mailarchive.ietf.org/arch/browse/ipv6/>
> > > >           (https://mailarchive.ietf.org/arch/browse/ipv6/ <https://mailarchive.ietf.org/arch/browse/ipv6/>).
> > > > 
> > > >      The IETF datatracker status page for this Internet-Draft is:
> > > >      https://datatracker.ietf.org/doc/draft-carpenter-6man-zone-ui/ <https://datatracker.ietf.org/doc/draft-carpenter-6man-zone-ui/>
> > > > 
> > > >      There is also an HTML version available at:
> > > >      https://www.ietf.org/archive/id/draft-carpenter-6man-zone-ui-00.html <https://www.ietf.org/archive/id/draft-carpenter-6man-zone-ui-00.html>
> > > > 
> > > >      Internet-Drafts are also available by rsync at:
> > > >      rsync.ietf.org::internet-drafts
> > > > 
> > > > 
> > > >      _______________________________________________
> > > >      I-D-Announce mailing list
> > > >      [e-mail] <mailto:[e-mail]>
> > > >      https://www.ietf.org/mailman/listinfo/i-d-announce <https://www.ietf.org/mailman/listinfo/i-d-announce>
> > > > 
> > > >      --------------------------------------------------------------------
> > > >      IETF IPv6 working group mailing list
> > > >      [e-mail] <mailto:[e-mail]>
> > > >      Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
> > > >      --------------------------------------------------------------------
> > > > 
> > > > 
> > > > 
> > > > -- 
> > > > ===============================================
> > > > David Farmer Email:[e-mail] <mailto:[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
> > > > ===============================================
> > > --------------------------------------------------------------------
> > > IETF IPv6 working group mailing list
> > > [e-mail]
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > --------------------------------------------------------------------
> > 

-- 
---
[e-mail]