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

[Michael Sweet <[e-mail]>]

Matt,

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

> On Aug 3, 2016, at 9:14 PM, Matt Miller <[e-mail]> 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