Thanks Michael. The updated digest text is fine with me. I look forward to the updated revision!
- m&m Matt Miller Cisco Systems, Inc. On 2016-8-5 08:56, Michael Sweet wrote: > Matt, > > Thanks for a thorough review! Responses inline below... > >> On Aug 3, 2016, at 9:14 PM, Matt Miller <[email protected]> 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 > OPTIONAL. > > 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 > end-of-attributes-tag > 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 > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
