Internet Printing Protocol/1.1: Model and Semantics
draft-sweet-rfc2911bis-11

(I've cleared my discuss based on email discussion, with the assumption that the proposed changes will make it into the document.)

Substantive Comments:

General : IDNits points out several normative downrefs, most of which are not in the downref registry. Some are from 2911, but some are new references.

-3.4, "If a Client were to submit a Job using the secure URI, the Printer might
   assign the new Job a secure URI as well."

Only "might"? Would it ever  make sense to downgrade the URI security for the printer-assigned URI?

- 4.1.6: "MAY include the RECOMMENDED ... attributes"
MAY and RECOMMENDED are conflicting 2119 keywords for the same requirement.

- 7: "Extensions registered for use with IPP/1.1 are OPTIONAL..."
Given the existence of 2.X, do we really expect or want extensions to 1.1?

- 7.1: Is "ipp@pwg.org" still the right place for designated experts?

Experience has shown that "X-" or similar prefixes for protocol attributes is rarely helpful. The IETF has been deprecating that sort of thing in other places. Would it make sense to do so here for new extensions?

-8, 11th paragraph: "...it is not related to the set of natural languages that MUST be accepted ..."
The MUST is a statement of fact, not a 2119 keyword. Please don't capitalize it. (The caps were added since  2911.)

-9, 1st paragraph: The small business example seems less believable today than it might have 16 years ago -- especially with potentially unsecured wireless networks.
-- 4th paragraph: It seems like there should be some privacy considerations regarding client identities.

-9.1.1, last paragraph: "Although the identity of the
   user can be trusted in this environment,..."
Why would we assume that? It might be trusted, or it might not.

Editorial Comments and Nits:

- Abstract: Please mention the obsoleted RFCs in the abstract.
- Editor's Note: Should this stay in the RFC? If not, a note to the RFC editor to that effect would be helpful.

-2.3.11
"MUST support all REQUIRED attributes" is redundant. That's what "REQUIRED" means.

- 4.1.5, 7th paragraph: "The operation target attributes are REQUIRED operation attributes
   that MUST be included in every operation request."
REQUIRED and MUST are redundant 2119 keywords. (I think the MUST is more a statement of fact.)

-6.1, paragraph 4: "MUST support all REQUIRED" is redundant.

Results of the discussion between Gen-ART reviewer (Russ) and author (Michael) should find their way into the draft.

Thanks for your work on this draft.  I have some questions on the authentication text and would like to understand the reasons behind the current recommendations.

Section 2.6.7
Can you add text to explain why authentication is a SHOULD?  I see this says the recommendation is from the original document.  Why isn't it being updated to be more secure, is that not possible (server auth only maybe?)?  If I print anonymously, I'll want to know I am prating to the correct printer and that my print job is going off to multiple printers to steel my data, even at the library, etc.

It would be helpful to know if there is a good reason.  Is it just that this draft is just pulling together multiple existing RFCs and an update to this draft would take care of changes like increased security?

- Review based on diff [1] from RFC 2911. Which is still
gigantic:-(

- It may be too late but I wondered why you had not
considered opportunistic security for IPP - it seems to me
like it'd be a really nice match for this protocol to get
to where a bunch of stuff is encrypted when it can be.
Please consider applying the principles from RFC 7435 and
the opportunistic security for HTTP [2] draft here. It'd
not be hard to specify this, and fairly easy to implement
too and it'd be a fine improvement for little cost. 

   [1] https://tools.ietf.org/rfcdiff?url1=rfc2911&url2=draft-sweet-rfc2911bis-09.txt

   [2] https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-06