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

ISTO-PWG Internet Printing Protocol workgroup discussion forum via ipp <[email protected]> Mon, 21 Mar 2022 12:58:24 -0400
Newsgroups	gmane.ietf.ipp
Message-ID	<[email protected]>
FYI, my feedback to the IETF 6man WG...


> Begin forwarded message:
> 
> From: Michael Sweet <[email protected]>
> Subject: Re: draft-ietf-6man-rfc6874bis-00.txt
> Date: March 21, 2022 at 12:56:46 PM EDT
> To: [email protected]
> 
> 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

_______________________________________________
ipp mailing list
[email protected]
https://www.pwg.org/mailman/listinfo/ipp
signature.asc (application/pgp-signature, 833 B)