[IPP] Fwd: draft-ietf-6man-rfc6874bis-00.txt

ISTO-PWG Internet Printing Protocol workgroup discussion forum via ipp <ipp@pwg.org> Mon, 21 March 2022 16:58 UTC

Return-Path: <ipp-bounces@pwg.org>
X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B9B3A1A5F for <ietfarch-ipp-archive@ietfa.amsl.com>; Mon, 21 Mar 2022 09:58:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.007
X-Spam-Level:
X-Spam-Status: No, score=-8.007 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, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pwg.org header.b=JU0HhG0f; dkim=pass (1024-bit key) header.d=pwg.org header.b=mye7alve; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=msweet.org header.b=J4BMpsIU
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 kausD2YvQlHc for <ietfarch-ipp-archive@ietfa.amsl.com>; Mon, 21 Mar 2022 09:58:54 -0700 (PDT)
Received: from mail.pwg.org (mail.pwg.org [50.116.7.199]) by ietfa.amsl.com (Postfix) with ESMTP id 06F1E3A1A55 for <ipp-archive2@ietf.org>; Mon, 21 Mar 2022 09:58:33 -0700 (PDT)
Received: by mail.pwg.org (Postfix, from userid 1002) id 05036E782; Mon, 21 Mar 2022 16:58:31 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.pwg.org 05036E782
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=pwg.org; s=default; t=1647881912; bh=IE1RyMmPd6Ov9MQghAKXVjLs/FCbMqrDx/o4Ujcx6eo=; h=Date:References:To:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=JU0HhG0fL4/M5AXGN3dPoekxo2R4HVCPQHKy8a/t4PftDIfMB4Q1PjdgWN5pzYLEW z30/PNo1+f2po13/IKyIF/LrtKNmTKDFMBWLAC4K1DthTYR98ZrTclCiAvNJZVjkYv rqYeSMi9COLEJanYXZr4PkVTChYfVVReJiWdOIrU=
Received: from mail.pwg.org (localhost [IPv6:::1]) by mail.pwg.org (Postfix) with ESMTP id 40C6AE159; Mon, 21 Mar 2022 16:58:29 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.pwg.org 40C6AE159
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=pwg.org; s=default; t=1647881909; bh=IE1RyMmPd6Ov9MQghAKXVjLs/FCbMqrDx/o4Ujcx6eo=; h=Date:References:To:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=mye7alve2759+e9eZAqZWYScpJUh+7uvpp1jOJjKaMLZTEpRoBzSbCWMTi71MYHvZ x4GNDVroDjrNvdP6r5Qn6tvKRKvHiVgN1C8hNSidUnqOEwJE0xCGafq7mSkozJ1t9X HhxRvDr4prNrbJMu1rsAkPJRde15RyNV5Kf2s7BY=
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.pwg.org CBD7AE159
Authentication-Results: mail.pwg.org; dkim=pass (1024-bit key) header.d=msweet.org header.i=@msweet.org header.b="J4BMpsIU"
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.pwg.org 0EF1C3EA
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.msweet.org 10CEB80B71
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=msweet.org; s=default; t=1647881906; bh=E7JFDpzYyKobZgB68x31vqHJsyTgjl2YBpPN2QKgbEw=; h=From:Date:Subject:References:To:From; b=J4BMpsIU4NbiYcvFJqGZj8cvp68ko8o0DLtkFogSdiflOGoTJ4HZTcka1WXKH1kgZ MEo1fR6CkE5aSGfGlQeCFKht7Mw1+5nLbCvtjg5tzPRIXh08NKhaWBeNVeMcffLgtv 2xanDmANsqH6KTaGqe5C6zuDM2TiGQn87DbyDKG0=
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\))
Date: Mon, 21 Mar 2022 12:58:24 -0400
References: <A3047267-85F4-4515-9220-FFF40790838A@msweet.org>
To: PWG IPP Workgroup <ipp@pwg.org>
X-Mailer: Apple Mail (2.3696.80.82.1.1)
Message-ID: <mailman.171.1647881908.17602.ipp@pwg.org>
Subject: [IPP] Fwd: draft-ietf-6man-rfc6874bis-00.txt
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: ISTO-PWG Internet Printing Protocol workgroup discussion forum <ipp.pwg.org>
List-Unsubscribe: <https://www.pwg.org/mailman/options/ipp>, <mailto:ipp-request@pwg.org?subject=unsubscribe>
List-Archive: <http://www.pwg.org/pipermail/ipp/>
List-Post: <mailto:ipp@pwg.org>
List-Help: <mailto:ipp-request@pwg.org?subject=help>
List-Subscribe: <https://www.pwg.org/mailman/listinfo/ipp>, <mailto:ipp-request@pwg.org?subject=subscribe>
From: ISTO-PWG Internet Printing Protocol workgroup discussion forum via ipp <ipp@pwg.org>
Reply-To: ISTO-PWG Internet Printing Protocol workgroup discussion forum <ipp@pwg.org>
Content-Type: multipart/mixed; boundary="===============2266811308135189399=="
Errors-To: ipp-bounces@pwg.org
Sender: ipp <ipp-bounces@pwg.org>

FYI, my feedback to the IETF 6man WG...


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



_______________________________________________
ipp mailing list
ipp@pwg.org
https://www.pwg.org/mailman/listinfo/ipp