Internet Printing Protocol (IPP) over HTTPS Transport Binding and the 'ipps' URI Scheme
RFC 7472

Note: This ballot was opened for revision 17 and is now closed.

Barry Leiba Yes

(Jari Arkko) No Objection

Comment (2014-12-04 for -17)
No email
send info
Resolutions of the Gen-ART review issues still need to be done. I expect the AD in charge will handle this.

(Alia Atlas) No Objection

Comment (2014-12-03 for -17)
No email
send info
Adrian's and Pete's point is worth supporting.

(Richard Barnes) No Objection

Comment (2014-12-03 for -17)
No email
send info
""" - basically the IPP Client can send its whole Print-Job request before the IPP Printer has a chance to respond and say,  "Wait!  You need to encrypt first!" """

My favorite sentence of all the docs this telechat :)  Thanks!

(Benoît Claise) No Objection

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

Comment (2014-12-03 for -17)
No email
send info
I agree with Adrian and Pete about the wording on updating IEEE specifications. I'd support the text Pete suggested. 

I had one comment on this otherwise lovely draft:

In this text:

   2) Some existing IPP Client and IPP Printer implementations of HTTP
      Upgrade [RFC2817] do not perform upgrade at the beginning of every
      HTTP [RFC7230] connection, but instead only shift to secure IPP
      for selected IPP operations (inherently dangerous behavior on the
      same underlying TCP [STD7] connection).
      
STD7 isn't TCP in any meaningful way, because the vast majority of TCP functionality hasn't advanced to full Internet Standard status, and we can't add Proposed Standards to an STD number until they advance to Internet Standards. STD7 doesn't even include Slow Start.

The best reference I can offer is https://tools.ietf.org/html/draft-ietf-tcpm-tcp-rfc4614bis-08, currently in the RFC Editor's queue. You have STD7 as a normative reference, but I'd expect the TCPM doc to pop out first.

STD7 also appears in 6.1.2 and in a couple of other places, but it looks like the other places are in sections slated for removal.

(Adrian Farrel) (was Discuss) No Objection

Comment (2014-12-04 for -17)
No email
send info
Moving to a No Objection ballot.

The authors and responsible AD say they will remove the text:

   c) IEEE-ISTO PWG IPP Version 2.0 Second Edition [PWG5100.12], by
      extending section 4 'IPP Standards' and section 10 'Security
      Considerations'.

I trust them to do this.

(Stephen Farrell) No Objection

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Comment (2014-12-04 for -17)
No email
send info
comments from the opsdir reviewer.

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These comments
were written primarily for the benefit of the operational area directors.
Document editors and WG chairs should treat these comments just like any other
last call comments.

Summary: Ready

Reviewer's Notes: It took me a while to perform this review because I first had to read-up on IPP, which is a fair amount of text... But I found this draft and the related IPP documents to be well written.

Cheers,
-Benson

(Ted Lemon) No Objection

(Kathleen Moriarty) No Objection

Comment (2014-12-03 for -17)
No email
send info
Thanks for your work on this draft.  The Security considerations look good, I just have a few comments that I'd like you to consider as updates, although this is non-blocking.

Section 6.1.1, bullet d, theft of the data is more of a concern, so listing both of these within this bullet should satisfy that request.  How about the following:
      d) The print document content itself (for example, theft of the data 
         or to corrupt the documents being transferred).   

This would be to the print spooler for theft before it is sent in an encrypted stream, which seems to fit in with the description for this section.

Section 6.3
Implementers will likely find it helpful to have a reference to the BCP on TLS best practices that is in WG last call now.  An informal reference would not hold up this draft.
https://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/

(Pete Resnick) No Objection

Comment (2014-12-03 for -17)
No email
send info
Adrain's DISCUSS saves me from having to put one on. As discussed in email, choice (c) in the list of documents that this document updates is not appropriate. If the PWG wants to say in one of their documents that PWG5100.12 is updated by this IETF document, that's their business. But *we* can't say in *our* document that we're updating their document. If you need a note, it could say:

      Note: IEEE-ISTO PWG has indicated that they intend to use this
      document as an update to their IPP Version 2.0 Second Edition
      [PWG5100.12], by extending section 4 'IPP Standards' and section
      10 'Security Considerations'.

But either way, (c) should go.

1.2: Does this document intend to deprecate use of 2817? Should we be moving 2817 to Historic?

4.3:

   Per PWG IPP Everywhere [PWG5100.14], for compatibility with existing
   IPP implementations, IPP Clients and IPP Printers MUST accept
   explicit port 443 (assigned in the 'https' URI scheme [RFC7230]) in
   'ipps' URI values.  

An IPP Client MUST accept 443, but can reject other port numbers? That seems bogus. Are you really simply saying that IPP Printers MUST listen on port 443 in addition to any other ports it might want to use? I don't understand this instruction.