Internet Printing Protocol (IPP) over HTTPS Transport Binding and the 'ipps' URI Scheme
draft-mcdonald-ipps-uri-scheme-18

[Ballot comment]
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.

[Ballot comment]
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

[Ballot comment]
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.

[Ballot comment]
""" - 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!

[Ballot comment]
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.

[Ballot comment]
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/

[Ballot discuss]
Updated after catching myself typing too fast...

Barry and Robert have been having a discussion about the text that says

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

This discussion has been progressing, but does not seem to be complete. Robert wrote:

> This RFC-to-be is updating an IEEE-ISTO PWG document, and that seems
> exceptional enough to warrant mention about how the organizations
> are coordinating that update.

Barry's response is:

> I'd think that's for PWG to address on their side, no?  If they accept
> that they can have an IETF RFC formally updating one of their
> documents, that's their process, not ours, no?

I would agree with that except that this document is making the bald statement that the IETF *is* updating the PWG document.

I would most like to read (in this document) that this is cooperative work and that the PWG (or its successor) agrees that we can make this update. But I would settle for a judicious application of a literate weasel maybe replacing "updates" with some words about "builds on and enhances" or "supplies additional relevant text".

[Ballot discuss]
Barry and Robert have been having a discussion about the text that says

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

This discussion has been progressing, but does not seem to be complete. Robert wrote:

> This RFC-to-be is updating an IEEE-ISTO PWG document, and that seems
> exceptional enough to warrant mention about how the organizations
> are coordinating that update.

Barry's response is:

> I'd think that's for PWG to address on their side, no?  If they accept
> that they can have an IETF RFC formally updating one of their
> documents, that's their process, not ours, no?

I would agree with that except that this document is making the bald statement that the IETF *is* updating the PWG document.

I would most like to hear that this is cooperative work and that the PWG (or its successor) agrees that we can make this update. But I would settle for a judicious application of a literate weasel maybe replacing "updates" with some words about "builds on and enhances" or "supplies additional relevant text".

IESG/Authors/WG Chairs:

IANA has reviewed draft-mcdonald-ipps-uri-scheme-15. Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments:

Upon approval of this document, IANA understands that there is a single action which needs to be completed.

In the Permanent URI Schemes subregistry of the Uniform Resource Identifier (URI) Schemes registry at

https://www.iana.org/assignments/uri-schemes/

a new URI scheme is to be registered as follows:

URI Scheme: ipps
Template:
Description: IPP over HTTPS
Reference: [ RFC-to-be ]

IANA Note: The designated expert for this registry agrees that this registration can be made upon IESG approval of the document.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (IPP over HTTPS Transport Binding and 'ipps' URI Scheme) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'IPP over HTTPS Transport Binding and 'ipps' URI Scheme'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-11-25. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document defines the Internet Printing Protocol (IPP) over HTTPS
  transport binding and the corresponding 'ipps' URI scheme, that is
  used to designate the access to the network location of a secure IPP
  print service or a network resource managed by such a service.

  This document defines an alternate IPP transport binding to that
  defined in the original IPP URL Scheme (RFC 3510), but this document
  does not update or obsolete RFC 3510.

  This document updates RFC 2910 and RFC 2911.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-mcdonald-ipps-uri-scheme/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-mcdonald-ipps-uri-scheme/ballot/


No IPR declarations have been submitted directly on this I-D.

1. Summary

Barry Leiba is the document shepherd and responsible AD.

This document defines the Internet Printing Protocol (IPP) over HTTPS
transport binding and the corresponding 'ipps' URI scheme, that is
used to designate the access to the network location of a secure IPP
print service or a network resource (for example, a print job)
managed by such a service.

The extensions to IPP amount to new protocol, and the document is
requested as Proposed Standard.

2. Review and Consensus

This document was submitted to the IETF, with AD sponsorship, by
the Internet Printing Protocol Working Group of the IEEE-ISTO Printer
Working Group, as part of their PWG IPP Everywhere (PWG 5100.14)
project for secure mobile printing with vendor-neutral Client software.
IPP work has resided in that group for some years, since the closing
of the IETF IPP working group.

The document was discussed on the apps-discuss and uri-review mailing
lists, and is ready for IETF last call.  Numerous minor issues were
raised and addressed, with none rising to the level of any controversy.

3. Intellectual Property

The authors have confirmed full compliance with BCPs 78 and 79.

4. Other Points

Nothing to note.