Re: draft-ietf-6man-rfc6874bis-00.txt

[Brian E Carpenter <[e-mail]>]

On 22-Mar-22 05:56, Michael Sweet wrote:
> Hi,
> 
> Saw this get posted and I have feedback... :)
> 
> - Section 1: For the CUPS reference, I'd add OpenPrinting CUPS since that is where all future development is happening (<https://openprinting.github.io/cups>). Also, IPP in general defines this behavior as part of the IPP (RFC 3510) and IPPS (RFC 7472) URI schemes which map from IPP(S) to HTTP(S).

Thanks for that.

> 
> - Section 2: I very must appreciate dropping the language in 6874 concerning stripping of zone identifiers, as that was one of my strongest objections to the prior RFC.
> 
> - Section 3: Extending the URI syntax in this way *will* break existing URI parsers in unfortunate ways, particularly if the zone identifier has two initial characters that are valid hex, e.g. if the zone ID is "20" on a Windows system, the newly encoded URI would look like "https://[fe80::abcd%20]/..." and existing URI parsers (which otherwise don't need to special-case percent encoding of any kind of URI) will treat that as a space in the address... For non-hex characters you'll likely trigger an error/exception when the URI is parsed.

It *may* break some parsers in some circumstances, but I am not convinced, and I am reasonably convinced that they can be fixed, from my own investigations and from feedback we've received. These parsers are not syntax-driven parsers that blindly follow the ABNF. They are hand coded and the IPv6 literal syntax is a separate branch in the code, in the cases I have examined. If a URL happens to arrive percent-encoded, it would get decoded before parsing. So %25eth0] would become %eth0] before parsing starts. But %25] needs to stay as %25].
That's codable even if it's horrible. (I didn't do this in my patch to wget, but maybe I should...)

I agree there may prove to be cases of unfortunately named interfaces where it may be necessary to use percent-encoding in the UI anyway. But personally I'm a bit reluctant to discuss that in an RFC.

>    In the interests of interoperability, backwards compatibility, etc., it might be better for the actual URI wire encoding to stick with "%25" (still "breaks" strict RFC 3986 parsers but with fewer side-effects) and then provide some guidance to browser developers to tweak their processing of URIs in the location field (which is already done, for example for web searches). Remember that there are billions of IPP printers out there that would be affected by this, and while CUPS can certainly rewrite URIs for existing implementations, that won't help people trying to access the printer's web page to configure things...
> 
> - Section 4: It isn't specifically the request URI that is used as-is, but the address in the URI. In the case of CUPS, an IPP URI ("ipp://[fe80::abcd%zoneid]/printers/example") is re-written as a HTTP URI ("http://[fe80::abcd%zoneid]:631/printers/example"), and for some resources the path may also be changed (icons, strings files, etc.)

Ack

> - Section 7.2: Please add OpenPrinting CUPS ("[OP-CUPS]", <https://openprinting.github.io/cups>), 

Ack

> LITERAL-ZONE reference might be more useful if it pointed to the last draft that was submitted (<https://www.ietf.org/archive/id/draft-fenner-literal-zone-02.txt>).

XML2RFC does what it does...

Thanks
    Brian