Hi Dale,
Note that since the Last Call has ended, there's now a -03 drfat
that attempts to respond to the actionable comments from various
reviews.
(https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6874bis/)
More in line:
On 05-Oct-22 13:51, Dale R. Worley wrote:
I'm not an expert in this area, but it seems that these points can be
made:
1. RFC 4007 is rather comical because it says in section 6 "The actual
representation to encode the scope is implementation dependent and is
out of the scope of this document." but section 11 has 7 subsections
discussing how to represent zone indexes.
Yes, but it's really out of scope for *this* draft to fix everything
that's wrong with RFC4007. Some of us believe that 6MAN should work
on that, but as an orthogonal effort.
2. It doesn't seem to be a philosophical problem that we define a type
of URI that can only be properly interpreted within a very small part of
the Internet. There's no requirement that URIs be universally
interpretable; "U" stands for "uniform" as in uniform syntax. Or for
that matter, that they might be interpreted differently in different
places. There is vast elasticity regarding what it means to "identify"
a "resource". (I've been involved in a working group that defined URNs
that were abstract properties, and would only be realized by comparing a
prioritized sequence of URNs against the signals that a device was
capable of producing.)
We agree. The -03 draft makes this point.
3. Given #2, it's not a problem that many implementations would be
unable to parse these URLs because their syntax is not
upward-compatible, as long as the beneficial use cases are generally
implemented.
Exactly. The -03 draft makes this point too.
4. There seems to be concern that this could introduce situations where
a single URL would refer to different resources when resolved in
different locations, or that the same resource would be referred to by
two different URLs. But there are plenty of situations now where those
are true. Presumably security implementations default to rejecting
URLs that they don't understand the significance of.
Again, exactly. It's a bit uncomfortable, but the U means Uniform,
not Universal or Unique, as you say.
5. There's a significant amount of trouble because RFC 4007 chose "%" as
the delimiter for zone indexes but "%" has a special syntax in URLs. In
principle, this shouldn't be a problem. "%" is used as the first
character of "%xx" escapes, but within URLs, that's just a constraint on
the contexts in which "%" may be used. Unfortunately, many people are
sloppy and e.g. consider the URL "http://example.com/foo-bar"; to be
equivalent to "http://example.com/foo%2dbar";, which leads to a lot of
software attempting to "normalize" URIs that contain "%". But the fact
that such software would choke on URLs containing zone indexes doesn't
seem to be important, as we expect zone indexes to have limited use.
Correct. That's exactly why the necessary patch to wget is two lines of C.
(https://github.com/becarpenter/wget6/blob/main/wget-6874bis.md)
It's *significantly* harder for the browsers, since their parsers are much
more complex than wget, but your analysis seems to be spot on.
The unfortunate circumstance is that RFC 4007 has pretty much frozen "%"
as the delimiter character. If we could change that, life would be
easier. But there's a lot of deployed software and current practice
that would have to be changed.
Exactly. It's unfortunate, but at the time of RFC4007, nobody noticed
this gotcha.
6. To get full usage of the new syntax, both the browsers and servers
that would be accessed by link-local addresses need to be changed. In
practice, the browsers are likely to be general-purpose but the servers
are likely to be resident on a small subset of devices that are
self-consciously network devices.
That's correct. As now noted in the draft, in some use cases even an
HTTP error response is a fine result for diagnostic purposes, because
it confirms connectivity.
Regards
Brian
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
