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

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-sweet-rfc2911bis-10.txt. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are no new registrations that need to be made.

IANA has noted the extensive instruction for management of the Internet Printing Protocol registries contained in the IANA Considerations section of the current draft. Upon approval of this document, IANA will work with authors to ensure that the registries are properly documented and that the registration policies are adequately described.

IANA understands that this is the only actions required upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 

Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: alexey.melnikov@isode.com, "Barry Leiba" , barryleiba@computer.org, draft-sweet-rfc2911bis@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Internet Printing Protocol/1.1: Model and Semantics) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'Internet Printing Protocol/1.1: Model and Semantics'
  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 2016-09-06. 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.

This is the Second IETF LC to explicitly call out DownRefs (see below).

Abstract

  The Internet Printing Protocol (IPP) is an application level protocol
  for distributed printing using Internet tools and technologies.  This
  document describes a simplified model consisting of abstract objects,
  attributes, and operations that is independent of encoding and
  transport.  The model consists of several objects including Printers
  and Jobs.  Jobs optionally support multiple Documents.

  IPP semantics allow End Users and Operators to query Printer
  capabilities, submit print Jobs, inquire about the status of print
  Jobs and Printers, and cancel, hold, and release print Jobs.  IPP
  semantics also allow Operators to pause and resume Jobs and Printers.

  Security, internationalization, and directory issues are also
  addressed by the model and semantics.  The IPP message encoding and
  transport are described in IPP/1.1: Encoding and Transport
  [RFC2910bis].

  This document obsoletes RFCs 2911, 3381, and 3382.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-sweet-rfc2911bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-sweet-rfc2911bis/ballot/


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

The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc2818: HTTP Over TLS (Informational - IETF stream)
    rfc1977: PPP BSD Compression Protocol (Informational - IETF stream)
    rfc1952: GZIP file format specification version 4.3 (Informational - Legacy stream)
    rfc1951: DEFLATE Compressed Data Format Specification version 1.3 (Informational - Legacy stream)
    rfc3196: Internet Printing Protocol/1.1: Implementor's Guide (Informational)
    rfc7612: Lightweight Directory Access Protocol (LDAP): Schema for Printer Services (Informational)
    rfc2565: Internet Printing Protocol/1.0: Encoding and Transport (Experimental)
    rfc2566: Internet Printing Protocol/1.0: Model and Semantics (Experimental)

Note that some of these references may already be listed in the acceptable Downref Registry.

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

[Ballot comment]

- 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

[Ballot discuss]
I need to re-LC the document, calling out DownRefs to the following documents:

  ** Downref: Normative reference to an Informational RFC: RFC 1951

Already in the DownRef registry.

  ** Downref: Normative reference to an Informational RFC: RFC 1952

GZIP

  ** Downref: Normative reference to an Informational RFC: RFC 1977

PPP BSD Compression Protocol

  ** Downref: Normative reference to an Informational RFC: RFC 2818

Already in the DownRef registry

  ** Downref: Normative reference to an Informational RFC: RFC 3196

Internet Printing Protocol/1.1: Implementor's Guide

  ** Downref: Normative reference to an Informational RFC: RFC 7612

Lightweight Directory Access Protocol (LDAP): Schema for Printer Services

  -- Obsolete informational reference (is this intentional?): RFC 2565
    (Obsoleted by RFC 2910)

  -- Obsolete informational reference (is this intentional?): RFC 2566
    (Obsoleted by RFC 2911)

These 2 Experimental RFCs are intended references.

---
  ** Downref: Normative reference to an Informational RFC: RFC 3239

Internet Printing Protocol (IPP): Requirements for Job, Printer, and Device Administrative Operations

  This can be Informative


  ** Downref: Normative reference to an Informational RFC: RFC 3997

Internet Printing Protocol (IPP): Requirements for IPP Notifications

  This can be Informative

[Ballot discuss]
I think this should be easy to resolve, but I would like to see discussion before the document progresses. This is closely related to my second discuss point for 2910bis:

Section 4.1.8 says "IPP implementations SHOULD accept any
  request with the major version ’1’ or ’2’, or reject the request if
  the operation is not supported."

The SHOULD level requirement for "forward" compatibility seems unusual. How is that different than saying implementations SHOULD implement 2.X and be backwards compatible to 1.1? If it's the same thing, then should have text discouraging new implementations of 1.1?

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

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

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-sweet-rfc2911bis-09.txt. If any part of this review is inaccurate, please let us know.

IANA has questions about the requests made in the IANA Considerations section of this document.

IANA understands that IPP/1.1 will support at least the following registries:

1. keyword attribute values
2. enum attribute values
3. attributes
4. attribute syntaxes
5. operations
6. attribute groups
7. status codes
8. out-of-band attribute values

IANA Question --> IANA believes that the authors intend Appendix A to contain templates for registration in each of the eight registries above. Is this correct?

Section 7.1 of the document discusses keyword and enum registrations. It appears that Expert Review, as defined in RFC 5226, is the intended mechanism for maintenance of these registries.

IANA Question --> are these new registries? If so, are they defined by this document or another, companion, document? If not, what registries are being maintained in this section?

Section 7.2 describes attribute names.

IANA Question --> do the authors intend to create a new registry for attribute names? If so, are they defined by this document or another, companion, document? If not, what registries are being maintained in this section?

Section 7.3 describes attribute syntaxes. It appears that the registry for attribute syntaxes is to be set up by another document that will use a Designated Expert for maintenance as defined by RFC 5226.

IANA Question --> Is this understanding correct?

Section 7.4 describes operations. It appears that the authors intend a registry for IPP/1.1 operations. It appears that Expert Review, as defined in RFC 5226, is the intended mechanism for maintenance of these registries.

IANA Question --> is this a new registry? If so, is it defined by this document or another, companion, document? If not, what registry are being maintained in this section?

Section 7.5 describes attribute groups. It appears that the authors intend a registry for IPP/1.1 attribute groups. It appears that Expert Review, as defined in RFC 5226, is the intended mechanism for maintenance of these registries.

IANA Question --> is this a new registry? If so, is it defined by this document or another, companion, document? If not, what registry are being maintained in this section?

Section 7.6 describes operation status codes. Appendix B appears to provide ranges for the values in an operation status code registry. It appears that the authors intend a registry for IPP/1.1 operation status codes. It appears that Expert Review, as defined in RFC 5226, is the intended mechanism for maintenance of these registries.

IANA Question --> is this a new registry? If so, is it defined by this document or another, companion, document? If not, what registry are being maintained in this section?

Section 7.7 describes out of band attribute values. It appears that the authors intend a registry for IPP/1.1 out of band attribute values. It appears that Expert Review, as defined in RFC 5226, is the intended mechanism for maintenance of these registries.

IANA Question --> is this a new registry? If so, is it defined by this document or another, companion, document? If not, what registry are being maintained in this section?

IANA has examined sections 7.8 and 7.9 of this document and discovered no new IANA actions that are required. In each case, the attributes being discussed all are based on registrations in existing IANA protocol registries.

IANA Question --> Is this understanding correct?

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 


Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

My AD review:

This is a well written document, but I have a few minor issues or nits that I would like to discuss with you.

In 4.1.4.1:

"charset" needs a reference to the RFC 2278, which establishes the corresponding IANA registry.

Last para on page 33: discussion about ISO-8859-1 seems incorrect. What do you mean by "filtering out" characters? Replacing them with a predefined character such as "?"?
The document can point out that us-ascii is a proper subset of utf-8 (each valid character in us-ascii is also a valid character in utf-8 and has the same on the wire encoding).

On page 34: I think you need a reference to language-tag RFC 5646 here.

On page 36: "SHOULD NOT ... supply incompatible combination of charset and natural language" - what is the purpose of this requirement? Nothing seem to break if it is violated. How can this requirement be enforced?


On page 37: the 2nd para talking about charset conversion looks a bit handwaivy to me. Is this detailed enough to be implementable?

  However, some information loss MAY occur during the charset conversion depending on the charsets involved.

This is not an implementation choice, it is a fact. So using "MAY" here is incorrect, just use "can".


In 4.1.5: on page 39: do you mean ipp/ipps URIs or http/https URIs? I think the former, but I want to double check.

In 4.1.6.2: "SHOULD examine ... the message" - is this really desirable?

In 4.1.8, page 45: why changing attributes from OPTIONAL to REQUIRED doesn't affect major version? How is it different from adding a REQUIRED attribute?


In 5.1.3.3:

In 2a: is case insensitive only applies to ASCII range? Unicode version is more complicated and would require more text.

In 2b: when matching language tags, it might be better if you point to section 2.1 of RFC 5646. Also, language tags are case-insensitive, so saying that they are matches "byte by byte" is not correct.


In 5.1.7 - different URI schemes require informative pointers to document defining relevant URI schemes.

In 5.4.2: certificate. The name is CN? Why not a subjectAltName value? Subject Name is an optional field in certificates and is deprecated in favour of subjectAltName values.

In 5.4.3: shall recommended ciphers be listed here? The document assumes that TLS is always secure, irrespective of the cipher used. You might want to point to RFC 7525 which contains the best current recommendations about good ciphers.

In 5.4.5: are there any privacy implications in publishing this information?


IANA Registration procedures are not clear: Expert Review? Or Specification Required?
I am looking at  and different subregistries have different registration procedures. The document should be updated to match what is on IANA website. Please also clarify if you intending to make any changes to registration procedures for subregistries.

In 7.1 (page 165): bullet point b: do you mean domain name? If yes, just say so.

7.8: You need to replace RFC 2045 with RFC 6838 here, as the latter contains updated syntax for MIME types, as well as the updated registration procedure?

In 9.1.1: it would be worth adding that TLS provides protection against threats identified in the last sentence.

In 9.1.2: how can protection against spamming be realized?

In 9.1.3: can print-by-reference create denial of service on third part websites?

Nit: "Adminstrator" typo in multiple place (at least in subsections of section 9)


In A.1: is "name of proposer" the same as "Change Controller"? I.e., is it the person who can modify the value/description, if needed? See  which will soon be approved as an RFC.

As "Address of Proposer" needed? This should be left to IANA to decide.

Same issues in other subsections of A.

Nit: On page 201, at the bottom: substitute supported attributes for unsupported: maybe the other way around ;-)?

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: alexey.melnikov@isode.com, "Barry Leiba" , barryleiba@computer.org, draft-sweet-rfc2911bis@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Internet Printing Protocol/1.1: Model and Semantics) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'Internet Printing Protocol/1.1: Model and Semantics'
  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 2016-07-29. 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 is one of a set of documents, which together describe
  all aspects of the Internet Printing Protocol (IPP).  IPP is an
  application level protocol that can be used for distributed printing
  using Internet tools and technologies.  This document describes a
  simplified model consisting of abstract objects, their attributes,
  and their operations that is independent of encoding and transport.
  The model consists of several objects including Printers and Jobs.
  Jobs optionally support multiple Documents.  IPP 1.1 semantics allow
  End Users and Operators to query Printer capabilities, submit print
  jobs, inquire about the status of print Jobs and printers, and
  cancel, hold, and release print Jobs.  IPP 1.1 semantics allow
  Operators to pause and resume (Jobs from) Printer objects.  This
  document also addresses security, internationalization, and directory
  issues.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-sweet-rfc2911bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-sweet-rfc2911bis/ballot/


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

1. Summary

Barry Leiba is the document shepherd.  Alexey Melnikov is the responsible Area Director.

The 2910bis and 2911bis documents are making necessary updates to the Internet Printing
Protocol that was produced by the IPP working group and published as RFCs 2910 and 2911
in 2000.  The updates bring the protocol up to what is currently deployed.

2. Review and Consensus

After the IPP working group was closed down in 2000, further work on Internet printing moved
out of the IETF and into the IEEE-ISTO's Printer Working Group (IPP WG).  These documents
represent the work of that group, which is where all the operators/implementors of IPP do
their work (they are, basically, the ones who worked in the IETF IPP working group when it
was active).  The documents have consensus of that group, and the consensus and implementation
are solid and broad.

The documents are being brought back into the IETF for last call and publication because
they are updating (replacing) IETF Standards Track documents.  There is no active work in the
IETF on Internet printing now.

3. Intellectual Property

The authors are in full compliance with BCPs 78 and 79, and they are not aware of any IPR
claims on these documents.

4. Other Points

2910bis updates the definition of the application/ipp media type; the updating template is
current and correct.  The IANA Considerations for 2911bis reviews the existing registries
that allow for extending IPP.  ISSUE: The preamble to that section should explicitly say
that the only new action for IANA is to change the reference document for those registries
to point to the 2911bis document.