Re: [Gen-art] Telechat Review of draft-sweet-rfc2910bis-08

Michael Sweet <> Fri, 05 August 2016 14:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B1AE12D8D5 for <>; Fri, 5 Aug 2016 07:56:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.588
X-Spam-Status: No, score=-5.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rUT4jdASbaXq for <>; Fri, 5 Aug 2016 07:56:29 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B6EF012D8CE for <>; Fri, 5 Aug 2016 07:56:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256;; s=mailout2048s; c=relaxed/simple; q=dns/txt;; t=1470408989; x=2334322589; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=HVo9bFZhd7aao//xqiVagNz90ANID1h1FNKk7nCiE9c=; b=odhNPOKrKvcWc6kUjysRFj/m50k0sPr/wnO9LA3/llUSlYoOzCHg2FwiKgEMqzwU lM13Hdh5DTEZNZp+dJ1LvYcp5EmUP/Fe1JGGGGETr4NSHPbMa+TbUJBqY3uGwq6U LCnvjv0TDlcCLojI/DZr5HAY20ir3DchWLxKSpjWq3u8hSuQFL+MKYmFYj3Pk9bg n14uC34ZlKLJka1mFtVW7T/sARhLxhVyzn/H8850eqJUNzULDJKv1TnSdFvTDCO/ 6LklzGMBNTQ1T/VNOoIsvNw1I7VTgR4GyUCsbbpTn4B+stJlqiexBKcFRLCPF0QG jX+sPYs+ASc2CZWofOSyoQ==;
Received: from ( []) by (Apple Secure Mail Relay) with SMTP id 9E.CD.07273.D19A4A75; Fri, 5 Aug 2016 07:56:29 -0700 (PDT)
X-AuditID: 11973e13-f794a6d000001c69-71-57a4a91da31d
Received: from ( []) by (Apple SCV relay) with SMTP id AC.5A.30701.D19A4A75; Fri, 5 Aug 2016 07:56:29 -0700 (PDT)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_x+XGypiKlkUrf1PAqUQxJg)"
Received: from [] (unknown []) by (Oracle Communications Messaging Server 64bit (built Jun 15 2016)) with ESMTPSA id <>; Fri, 05 Aug 2016 07:56:29 -0700 (PDT)
From: Michael Sweet <>
In-reply-to: <>
Date: Fri, 05 Aug 2016 10:56:25 -0400
Message-id: <>
References: <>
To: Matt Miller <>
X-Mailer: Apple Mail (2.3124)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUi2FAYoSu7ckm4wY0PIhZNs7uZLK6++sxi 8fnhbVYHZo8pvzeyeixZ8pMpgCmKyyYlNSezLLVI3y6BK2P5691sBY/iK25MnMTWwHgtoIuR k0NCwERi7sE+RghbTOLCvfVsXYxcHEICexklrq/uZIUp2rC9jwXEFhI4xCjx6ZMeiM0rICjx Y/I9sDizQJjEhEMzmCCau5gkji1+CdYsLCAhcbx/IZRtKdF2YwkziM0moCbxe1IfWJxTwFbi cdcqsEEsAqoSz6Z2M0EM9ZB4dPonK8QyG4kDR9ezQxxhI/G1ZT9YvYiAisSP3X9ZIA6VlXhy chELyBESAivYJO5cesEygVF4FpJjZyE5FsLWkvj+qBUozgFky0scPC8LEdaUeHbvEzuErS3x 5N0F1gWMbKsYhXITM3N0M/NM9RILCnJS9ZLzczcxgqJlup3wDsbTq6wOMQpwMCrx8CrELg4X Yk0sK67MPcQozcGiJM5bfR8oJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgZHpzi5G0zOt9xxz 7c/zcX9qbFkYGfzo/6eEtU84fzTziD538NuXFmHddiv4bPCymPWvF7i/SJj2InE6F8ui7hN3 XyluuDfH1UJUabPh6qUzmEt+Z/rzBfTdKGvkbuX8u4X7f3RJc7Xlhoz2XOE4mcJDs+Z8kLBY 8rwwZdOTE7IXN8ouiIvdW6HEUpyRaKjFXFScCAAA5F7mdwIAAA==
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUi2FA8W1d25ZJwg48P+C2aZnczWVx99ZnF 4vPD26wOzB5Tfm9k9Viy5CdTAFMUl01Kak5mWWqRvl0CV8by17vZCh7FV9yYOImtgfFaQBcj J4eEgInEhu19LBC2mMSFe+vZQGwhgUOMEp8+6YHYvAKCEj8m3wOrYRYIk5hwaAZTFyMXUE0X k8SxxS9ZQRLCAhISx/sXQtmWEm03ljCD2GwCahK/J/WBxTkFbCUed60CG8QioCrxbGo3E8RQ D4lHp3+yQiyzkThwdD07xBE2El9b9oPViwioSPzY/RfqUFmJJycXsUxgFJiF5L5ZSO6DsLUk vj9qBYpzANnyEgfPy0KENSWe3fvEDmFrSzx5d4F1ASPbKkaBotScxEpTvcSCgpxUveT83E2M 4OAujNjB+H+Z1SFGAQ5GJR5ehdjF4UKsiWXFlbnAMOJgVhLh5V6xJFyINyWxsiq1KD++qDQn tfgQozQHi5I4r98coGqB9MSS1OzU1ILUIpgsEwenVAPjTPnrQl4uamE5/OapYtyP4p997zln +kvqUazOr49TfYTipzZGXUqctjjFhOdgUk1evblmdcHy5WvzuB4ma69fm3n2/qXpawSX/dt8 yf3Id1kmr1XcgpYruO44SYc02/MmvRR37bU3+vGR+cR5J41DaRkuS08IcwdeLbKJ5Pv2vvMO 37af6SeUWIozEg21mIuKEwGCJdX3agIAAA==
Archived-At: <>
Cc: IETF Gen-ART <>,
Subject: Re: [Gen-art] Telechat Review of draft-sweet-rfc2910bis-08
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 05 Aug 2016 14:56:32 -0000


Thanks for a thorough review! Responses inline below...

> On Aug 3, 2016, at 9:14 PM, Matt Miller <> wrote:
> ...
> Major issues:
> * In Section 8.1.1. "Digest Authentication", support for MD5 and
>  MD5-sess is a MUST, which contradicts the NOT RECOMMENDED in
>  RFC 7616.  I this is likely because of the giant number of existing
>  implementations, but it's a bad idea to continue the practice given
>  how compromised MD5-based schemes are.  Maybe the following helps
>  find something acceptable?

The updated text we seem to have settled on is:

   8.1.1.  Digest Authentication

   IPP Clients and Printers SHOULD support Digest Authentication
   [RFC7616].  Use of the Message Integrity feature (qop="auth-int") is

   Note: Previous versions of this document required support for the MD5
   algorithms, however [RFC7616] makes SHA2-256 mandatory to implement
   and deprecates MD5, allowing its use for backwards compatibility
   reasons.  IPP implementations that support Digest Authentication MUST
   support SHA2-256 and SHOULD support MD5 for backwards-compatibility.

   Note: The reason that IPP Clients and Printers SHOULD (rather than
   MUST) support Digest Authentication is that there is a certain class
   of output devices where it does not make sense.  Specifically, a low-
   end device with limited ROM space and low paper throughput may not
   need Client Authentication.  This class of device typically requires
   firmware designers to make trade-offs between protocols and
   functionality to arrive at the lowest-cost solution possible.
   Factored into the designer's decisions is not just the size of the
   code, but also the testing, maintenance, usefulness, and time-to-
   market impact for each feature delivered to the customer.  Forcing
   such low-end devices to provide security in order to claim IPP/1.1
   conformance would not make business sense.  Print devices that have
   high-volume throughput and have available ROM space will typically
   provide support for Client Authentication that safeguards the device
   from unauthorized access because these devices are prone to a high
   loss of consumables and paper if unauthorized access occurs.

> ...
> Minor issues:
> * The "meta-data" states this document obsoletes 2910 and 3382,
>  but the Abstract does not explicitly say this.  There is the
>  editor's note, but it is helpful to put at least a mention in
>  the Abstract.

This has been added, per comments from several people... :)

> * In Section 3.2. "Syntax of Encoding", the ABNF in Figure 10 does
>  not parse in the tools I tried, because of the duplicate
>  reference.  The following seems to me to accomplish the intent
>  while still parsing:

Thanks, I'll incorporate this change but probably use future-delimiter-tag in the begin-attribute-group-tag rule since the future delimiters are all group tags:

delimiter-tag = begin-attribute-group-tag /   ; see section 3.5.1
begin-attribute-group-tag = %x00 / operation-attributes-tag /
   job-attributes-tag / printer-attributes-tag /
   unsupported-attributes-tag / future-group-tags
operation-attributes-tag   = %x01             ; tag of 1
job-attributes-tag         = %x02             ; tag of 2
end-of-attributes-tag      = %x03             ; tag of 3
printer-attributes-tag     = %x04             ; tag of 4
unsupported-attributes-tag = %x05             ; tag of 5
future-group-tags          = %x06-0F          ; future extensions

> ...
> * Section 3.3. "Attribute-group", the last row in Table 1 indicates
>  the document content is "in a special position as described above",
>  which appears to be Section 3.1.1.  It seems better to be more
>  explicit and say "in a special position as described in Section
>  3.1.1".

Works for me, changed.

> Nits/editorial comments:
> * idnits complains that this document is attempting to reference
>  "rfc2910bis" (this document) without declaring the reference.
>  These are all in the IANA Considerations, so it seems enough to
>  me to change them to "this document".

Already changed... :)

Michael Sweet, Senior Printing System Engineer