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/4vEKZosvKvqJ9cufSm5ivsCho_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
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
