Re: Artart last call review of draft-ietf-6man-rfc6874bis-02

Sorry to be late with this answer, but there are a few points below than 
need to be corrected.

On 2022-10-05 12:02, Brian E Carpenter wrote:
> 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:

>> 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.

This is definitely correct. There's no requirement that an URI has to be 
dereferenceable everywhere. But while there's no philosophical problem 
with that, it seems quite strange to change a very fundamental part of 
URIs (percent escaping) for such a small use case.

>> There's no requirement that URIs be universally
>> interpretable; "U" stands for "uniform" as in uniform syntax.

Yes. And part of that uniform syntax is the uniformity of percent 
escaping, which this proposal squarely ignores.

>> 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.

It depends on what "unable to parse" means. Many parsers and other 
software are written so that edge cases and errors get processed just 
'somehow', possibly producing unexpected results.


>> 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.

Such software isn't sloppy at all, it follows RFC 3986. Please see in 
particular Section 2.4 
(https://www.rfc-editor.org/rfc/rfc3986.html#section-2.4). 
"http://example.com/foo-bar" and "http://example.com/foo%2dbar" are 
equivalent. See also Section 6.2.2 
(https://www.rfc-editor.org/rfc/rfc3986.html#section-6.2.2).

> 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.

The gotcha can't be fixed anymore. But for those who created it, it 
might at least be possible to acknowledge it and compromise in a greater 
context. If all the Windows users who are accustomed to '\' as a path 
separator can change that to '/' in URIs, why is it so difficult for the 
very rare and localized case of zone ids to find another character than '%'?

Regards,   Martin.

>> 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
> 

_______________________________________________
art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/art