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
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
