I believe too that IPv6 fundamentally needs the capability to address LLA (address types) in applications. Maybe proposed is not the best way. Is it possible to hear alternatives from everybody who said "No"? Eduard -----Original Message----- From: ipv6 [mailto:ipv6-bounces@xxxxxxxx] On Behalf Of Brian E Carpenter Sent: Saturday, September 17, 2022 7:33 AM To: Roy T. Fielding <fielding@xxxxxxxx>; Martin Thomson <mt@xxxxxxxxxxxxxx> Cc: art@xxxxxxxx; draft-ietf-6man-rfc6874bis.all@xxxxxxxx; ipv6@xxxxxxxx; last-call@xxxxxxxx Subject: Re: [art] Artart last call review of draft-ietf-6man-rfc6874bis-02 Roy, On 17-Sep-22 08:48, Roy T. Fielding wrote: >> On Sep 16, 2022, at 12:31 PM, Martin Thomson via Datatracker <noreply@xxxxxxxx> wrote: >> <snip> > [1] > https://mailarchive.ietf.org/arch/msg/last-call/4vEKZosvKvqJ9cufSm5ivs > Cho_A/ [2] https://url.spec.whatwg.org/#concept-host-parser > > ditto > > I will add that this work was not discussed on the uri mailing list, > which is the responsible forum for updates to RFC3986. Hmm. I don't recall anybody on the DISPATCH list telling us that. > Also, the chosen syntax of % to indicate a zone ID is not, and will > never be, compatible with any implementation of URIs on the server > side because we need to strictly prohibit client-provided data in host > that might later be misinterpreted as a control character or space or > delimiter after percent-decoding, including a bare % error-case being > handled differently on one server than it is handled on a downstream recipient. That's incompatible with Martin's reference to [2] above. And it doesn't seem to be a problem if you obey the percent-encoding rules in the ABNF either. > IOW, this is not only incompatible with 3986, but cannot be > implemented without potentially adding request and response smuggling > vulnerabilities down the chain. Down what chain? These are Local Resource Identifiers that will never travel more than one hop. > It's not as if Appendix A doesn't recognize these problmes > > Disadvantage: requires code changes to all URI parsers. > > and then blithely ignores the fact that it is impossible to change the > code of all deployed URI parsers, even if we wanted to do so. Obviously, we're not talking about backwards compatibility with legacy systems. In many cases, it will simply fail. But as I mentioned in my reply to Martin, at least some existing servers apparently aren't troubled by it. > The short answer is that, no, this cannot be an update to RFC3986. > The stability of that standard is far more important than this use case. It's strictly an extension, not an amendment. So how does it create instability? > In the incredibly rare occasions It isn't "incredibly" rare. Now that IPv6 is getting close to the tipping point, it's surely going to be as common as http://192.168.178.1 > when one might want to refer to a > link-local address, it should be done via a separate attribute, or via > a compatible syntax extension that doesn't deliberately break the > existing implementations. Can you describe those in a bit more detail? What would that give us in place of http://[fe80::1%eth0] ? Regards, Brian > > Cheers, > > ....Roy T. Fielding, Senior Principal Scientist, Adobe > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@xxxxxxxx Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
