FYI, my feedback to the IETF 6man WG...
> Begin forwarded message:
>> From: Michael Sweet <msweet at msweet.org>
> Subject: Re: draft-ietf-6man-rfc6874bis-00.txt
> Date: March 21, 2022 at 12:56:46 PM EDT
> To: ipv6 at ietf.org>> 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).
>> - 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.
>> 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.)
>> - Section 7.2: Please add OpenPrinting CUPS ("[OP-CUPS]", <https://openprinting.github.io/cups>), 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>).
>> ________________________
> Michael Sweet
>>>
________________________
Michael Sweet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20220321/79d0ab69/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://www.pwg.org/pipermail/ipp/attachments/20220321/79d0ab69/attachment.sig>