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

Michael Sweet <msweet@msweet.org> Mon, 21 March 2022 16:56 UTC

Return-Path: <msweet@msweet.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A390C3A0F35 for <ipv6@ietfa.amsl.com>; Mon, 21 Mar 2022 09:56:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.828
X-Spam-Level:
X-Spam-Status: No, score=-4.828 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FAKE_REPLY_B=2.282, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=msweet.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2pcqVhvYg6s for <ipv6@ietfa.amsl.com>; Mon, 21 Mar 2022 09:56:49 -0700 (PDT)
Received: from mail.msweet.org (mail.msweet.org [173.255.209.91]) by ietfa.amsl.com (Postfix) with ESMTP id F10513A1A52 for <ipv6@ietf.org>; Mon, 21 Mar 2022 09:56:48 -0700 (PDT)
Received: from smtpclient.apple (cbl-66-186-76-47.vianet.ca [66.186.76.47]) by mail.msweet.org (Postfix) with ESMTPSA id F279C80B71; Mon, 21 Mar 2022 16:56:47 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.msweet.org F279C80B71
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=msweet.org; s=default; t=1647881808; bh=NZw+6baqeDGmW7DUbxPTHF7BRY12hU8rlUPGBoPmoKQ=; h=From:Date:Subject:To:From; b=LhmDiFEJ1UB8UrSkaAj4dXqTOpJhXgBqR3IH4iketOrNn8KUqOtQKMUVHz/OxHYmz G0fn3pXHb2dd+fqYOjmqmsTEpqC/ny/gdHgAw0/opNOOCFQh30jCKnEVG7XCjZizji HQNz9CT69596lScFkEyNAKvDvyfY+wOR09lLvMmM=
From: Michael Sweet <msweet@msweet.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_AC0ADBF7-BBBD-4155-9727-956D57E941A7"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\))
Date: Mon, 21 Mar 2022 12:56:46 -0400
Subject: Re: draft-ietf-6man-rfc6874bis-00.txt
Message-Id: <A3047267-85F4-4515-9220-FFF40790838A@msweet.org>
To: ipv6@ietf.org
X-Mailer: Apple Mail (2.3696.80.82.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/lCh3K00lD_huJs9I88GPv7lCkVU>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Mar 2022 16:56:54 -0000

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