Skip to main content

Internet Printing Protocol/1.1: Encoding and Transport
draft-sweet-rfc2910bis-10

Revision differences

Document history

Date Rev. By Action
2017-01-10
10 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2016-11-18
10 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2016-11-09
10 (System) RFC Editor state changed to RFC-EDITOR from REF
2016-10-26
10 (System) RFC Editor state changed to REF from EDIT
2016-09-12
10 (System) RFC Editor state changed to EDIT from MISSREF
2016-08-23
10 Michael Sweet New version available: draft-sweet-rfc2910bis-10.txt
2016-08-22
09 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2016-08-19
09 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2016-08-18
09 (System) IANA Action state changed to Waiting on Authors from In Progress
2016-08-18
09 (System) IANA Action state changed to In Progress from Waiting on Authors
2016-08-17
09 (System) IANA Action state changed to Waiting on Authors from In Progress
2016-08-15
09 (System) RFC Editor state changed to MISSREF from EDIT
2016-08-11
09 (System) IANA Action state changed to In Progress from Waiting on Authors
2016-08-11
09 Tero Kivinen Closed request for Last Call review by SECDIR with state 'No Response'
2016-08-10
09 (System) IANA Action state changed to Waiting on Authors
2016-08-09
09 Matthew Miller Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Matthew Miller.
2016-08-08
09 (System) RFC Editor state changed to EDIT
2016-08-08
09 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2016-08-08
09 (System) Announcement was received by RFC Editor
2016-08-08
09 Amy Vezza IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup
2016-08-08
09 Amy Vezza IESG has approved the document
2016-08-08
09 Amy Vezza Closed "Approve" ballot
2016-08-08
09 Amy Vezza Ballot approval text was generated
2016-08-05
09 Kathleen Moriarty [Ballot comment]
Thanks for addressing my prior discuss and comment.
2016-08-05
09 Kathleen Moriarty [Ballot Position Update] Position for Kathleen Moriarty has been changed to No Objection from Discuss
2016-08-05
09 (System) Sub state has been changed to AD Followup from Revised ID Needed
2016-08-05
09 Michael Sweet IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2016-08-05
09 Michael Sweet New version available: draft-sweet-rfc2910bis-09.txt
2016-08-04
08 Ben Campbell
[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: …
[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:

-5, numbered list item 2:
I’m confused—doesn’t this talk about creating a new HTTP/HTTPS URL from the IPP URL? How could this new URL already have an explicit port if you don’t put one in as part of that creation? Does this mean to add an explicit port to the HTTP URL if the IPP URL had one?

-6:
The media type has already been registered, hasn’t it? If so, it would be helpful to say that. I think a bis draft that obsoletes it’s predecessor does need to fully document anything registered by that predecessor, but also make it clear that it is not requesting a new registration. (It should describe any changes, though.)

Should the security considerations field in the media type registration refer to the security considerations in this document? That section seems to invalidate the idea that IPP adds no security considerations over those of underlying transport protocols.

-8: I'm surprised not to see a mention of integrity protection in this paragraph.

-8.2.1: "IPP Clients and Printers MAY support Basic Authentication [RFC7617] for User Authentication if the channel is secure, e.g., IPP over HTTPS [RFC7472]."
Is the intent to say you MUST NOT support Basic unless the channel is secure? if so, that's subtly different, since the current wording allows it for secure channels, but leaves the reader to infer that it is not allowed with insecure channels. (Also we are talking about "using" basic, not just "supporting" basic, aren't we?

Editorial Comments an Nits:

General: There's a fair amount redundancy with 2119 keywords (MUST, SHOULD, etc.). Much of that may be from the original text, but please try to avoid it when you can. When you have multiple bits of text that appear authoritative for the same requirement, it makes future updates more error prone. (I will call out a few specific instances, but probably missed a number of them.)

Abstract: Please mention the obsoleted drafts in the abstract. (I know the draft shepherd disagrees with me on that point, but I think that it's useful information for people who read the abstract, sometimes in isolation from the full document, to see if they need to read the rest of the doc.)

-4, first paragraph: Redundant with section 1, which provided quite a bit more detail.

- 4.1, 3rd paragraph: Please avoid 2119 keywords in examples. (This is also redundant to the 2119 keywords in the following list.)

-9.1, numbered list item 1: "SHOULD try supplying alternate version numbers"
Should that say "SHOULD try supplying lower version numbers"?
2016-08-04
08 Ben Campbell [Ballot Position Update] Position for Ben Campbell has been changed to No Objection from Discuss
2016-08-04
08 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2016-08-04
08 Stephen Farrell
[Ballot comment]

- Review based on diff from RFC 2910 [1]

- I see and like the reference to RFC7525, thanks.
However that generates …
[Ballot comment]

- Review based on diff from RFC 2910 [1]

- I see and like the reference to RFC7525, thanks.
However that generates a question about the response to
Kathleen's discuss: following RFC7525/BCP195 is the fine
and correct thing to do, but that strongly deprecates
TLS1.0 because as the BCP says "TLS 1.0 (published in
1999) does not support many modern, strong cipher
suites." Doesn't that mean that if I follow the SHOULD
and hence the BCP then I will not get interop with a
(shockingly!) unmodified RFC 2910 implementation? And if
that is true, then I don't see what still calls for you
to not make at least implementing what BCP195 calls for a
MUST. That shockingly non updated 16 year old stuff will
presumably never be updated so it doesn't really matter
that it doesn't adhere to this new document. (A similar
point could be made about Ben's discuss point on MD5.)
IOW, I think you can be much more aggressive in adding
new MUSTs - all you need to do is to note the places
where you do need to continue to interop with old and
crappily updated things. (Which I'm sure do exist in the
print world.)

- I didn't see any text here along the lines of "and we
changed this based on operational experience." That seems
like a missed opportunity - aren't there a bunch of
lessons learned from 16 years of implementation and
deployment some of which'd be worth documenting here?
(Apologies if I missed such text, or if its mostly in
the 2911bis draft.)

  [1] https://tools.ietf.org/rfcdiff?url1=rfc2910&url2=draft-sweet-rfc2910bis-08.txt
2016-08-04
08 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2016-08-04
08 Joel Jaeggli [Ballot comment]
Mahesh Jethanandani  performed the opsdir review
2016-08-04
08 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2016-08-04
08 Jari Arkko
[Ballot comment]
Stephen has already raised on issue about MD5, but I wanted to copy here Matt Miller's Gen-ART review, which also raised the same …
[Ballot comment]
Stephen has already raised on issue about MD5, but I wanted to copy here Matt Miller's Gen-ART review, which also raised the same issue and a smaller editorial issues.

I agree with Matt and Stephen that the document should have more explanation on the MD5 issue, although, of course, for an old protocol you may not be able to change. But at least the issue should be better described.

---

Almost ready.  My one major issue is with the digest authentication
requirements, and really needs to be addressed in a way that
accounts for current security best practices.

I admit that I did not read the RFCs this document obsoletes.

I did not validate the correctness of any of the examples in
Appendix A.

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?

  IPP Clients and Printers SHOULD support Digest Authentication
  [RFC7616].  For compatibility with existing implementations,
  Clients and Printers SHOULD implement and support MD5 and MD5-sess.
  However, MD5 and MD5-sess are NOT RECOMMNEDED for newer
  implementations.  Use of the Message Integrity feature
  (qop="auth-int") is OPTIONAL.


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.

* 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:

  delimiter-tag = begin-attribute-group-tag  / ; see section 3.5.1
            end-of-attributes-tag /
            future-delimiter-tag
  future-delimiter-tag = %x06-0F              ; see section 3.5.1
  begin-attribute-group-tag = %x00 / operation-attributes-tag /
    job-attributes-tag / printer-attributes-tag /
    unsupported-attributes-tag /  %x06-0F
  operation-attributes-tag =  %x01                ; tag of 1
  job-attributes-tag      =  %x02                ; tag of 2
  printer-attributes-tag =  %x04                  ; tag of 4
  unsupported-attributes-tag =  %x05              ; tag of 5

* 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".

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".

Non-nits comments:

* idnits is complaining about "weird spacing" in a number of places,
but they are clearly part of a table (which is the sole content of
the containing section/appendix), and I think can be safely
ignored.

* idnits is complaining about a downref to RFC2818, but it's
already on the Downref Registry.
2016-08-04
08 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2016-08-03
08 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2016-08-03
08 Alissa Cooper
[Ballot comment]
In 3.5.2 is "reserved for 'default' for definition in a future standards track document" really what you meant to say here? Does this …
[Ballot comment]
In 3.5.2 is "reserved for 'default' for definition in a future standards track document" really what you meant to say here? Does this mean 'default' is going to be defined in a future standards track document?
2016-08-03
08 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2016-08-02
08 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2016-08-02
08 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2016-08-02
08 Ben Campbell
[Ballot discuss]
I have a couple of items I would like to discuss before this progresses. I think these should be reasonably easy to resolve: …
[Ballot discuss]
I have a couple of items I would like to discuss before this progresses. I think these should be reasonably easy to resolve:

- 8.1.1:
The first paragraph requires support for MD5 and MD5-sess, and has no discussion of other algorithms.  But the reference has been updated to RFC 7616, which is not quite compatible with that guidance. 7616 deprecates MD5, but allows it for backwards compatibility. It also makes SHA2-256 MTI. I realize there may be backwards compatibility issues, but I think the text should at least discuss the issue and encourage people to move away from md5.

-9
If I read this section correctly, it requires (at SHOULD level) IPP/1.1 implementations to understand and correctly respond to IPP/2.X messages. How is this different from saying they SHOULD implement 2.X, but be backwards compatible with 1.1? ( I think this also applies to 2911bis).
2016-08-02
08 Ben Campbell
[Ballot comment]
Substantive Comments:

-5, numbered list item 2:
I’m confused—doesn’t this talk about creating a new HTTP/HTTPS URL from the IPP URL? How could …
[Ballot comment]
Substantive Comments:

-5, numbered list item 2:
I’m confused—doesn’t this talk about creating a new HTTP/HTTPS URL from the IPP URL? How could this new URL already have an explicit port if you don’t put one in as part of that creation? Does this mean to add an explicit port to the HTTP URL if the IPP URL had one?

-6:
The media type has already been registered, hasn’t it? If so, it would be helpful to say that. I think a bis draft that obsoletes it’s predecessor does need to fully document anything registered by that predecessor, but also make it clear that it is not requesting a new registration. (It should describe any changes, though.)

Should the security considerations field in the media type registration refer to the security considerations in this document? That section seems to invalidate the idea that IPP adds no security considerations over those of underlying transport protocols.

-8: I'm surprised not to see a mention of integrity protection in this paragraph.

-8.2.1: "IPP Clients and Printers MAY support Basic Authentication [RFC7617] for User Authentication if the channel is secure, e.g., IPP over HTTPS [RFC7472]."
Is the intent to say you MUST NOT support Basic unless the channel is secure? if so, that's subtly different, since the current wording allows it for secure channels, but leaves the reader to infer that it is not allowed with insecure channels. (Also we are talking about "using" basic, not just "supporting" basic, aren't we?

Editorial Comments an Nits:

General: There's a fair amount redundancy with 2119 keywords (MUST, SHOULD, etc.). Much of that may be from the original text, but please try to avoid it when you can. When you have multiple bits of text that appear authoritative for the same requirement, it makes future updates more error prone. (I will call out a few specific instances, but probably missed a number of them.)

Abstract: Please mention the obsoleted drafts in the abstract. (I know the draft shepherd disagrees with me on that point, but I think that it's useful information for people who read the abstract, sometimes in isolation from the full document, to see if they need to read the rest of the doc.)

-4, first paragraph: Redundant with section 1, which provided quite a bit more detail.

- 4.1, 3rd paragraph: Please avoid 2119 keywords in examples. (This is also redundant to the 2119 keywords in the following list.)

-9.1, numbered list item 1: "SHOULD try supplying alternate version numbers"
Should that say "SHOULD try supplying lower version numbers"?
2016-08-02
08 Ben Campbell [Ballot Position Update] New position, Discuss, has been recorded for Ben Campbell
2016-08-02
08 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2016-08-02
08 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2016-08-01
08 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2016-08-01
08 Kathleen Moriarty
[Ballot discuss]
Thanks for your work updating this draft.  I'd like to discuss the TLS recommendations to either see if we can change them or …
[Ballot discuss]
Thanks for your work updating this draft.  I'd like to discuss the TLS recommendations to either see if we can change them or to improve the text and warnings around why TLS is recommended.

Section 8.1.1 #2
  I'm not sure why this is a reason why TLS is just a SHOULD.  This seems to be a reason for it being a MUST.  Is this just a text formatting issue?  Should #2 be under a different heading?

Sections 8.1.1 & 8.1.2:

Preference:
Could the text be re-written to have TLS as a MUST unless restrictions of the device make it so it is not possible or feasible?  Not having TLS for authentication at least is a really bad idea.  If it is just a SHOULD, when it is possible, developers may opt to not use TLS when there is no reason. 

If TLS stays as a SHOULD, I'd like to see stronger language around why it is recommended for use as the security considerations section only really talks about why it is not a MUST.  It would be good to have sufficient motivation for developers and implementers to do the right thing.
2016-08-01
08 Kathleen Moriarty
[Ballot comment]

Nit:  It's not still new, is it?
Abstract: This document is one of a set of documents, which together describe
  all aspects …
[Ballot comment]

Nit:  It's not still new, is it?
Abstract: This document is one of a set of documents, which together describe
  all aspects of a new Internet Printing Protocol (IPP).
2016-08-01
08 Kathleen Moriarty [Ballot Position Update] New position, Discuss, has been recorded for Kathleen Moriarty
2016-07-26
08 Mirja Kühlewind
[Ballot comment]
One comment/question:

I got stuck a little with the following sentences:
  "HTTP/1.1 [RFC7230] is the REQUIRED transport layer for this …
[Ballot comment]
One comment/question:

I got stuck a little with the following sentences:
  "HTTP/1.1 [RFC7230] is the REQUIRED transport layer for this protocol.
  HTTP/2 [RFC7540] is an OPTIONAL transport layer for this protocol."
I know the first one was there already in the RFC, but I'm just wondering if it is intentional to not say anything about the transport protocol underneath HTTP or not. Because RFC7230 is specified for the use with TCP but does not prohibit the usage of other transport protocol (given we would have another one that could fulfill the needed requirements). Should this doc explicitly say that HTTP1.1 over TCP or TLS/TCP, or is this not important?
2016-07-26
08 Mirja Kühlewind Ballot comment text updated for Mirja Kühlewind
2016-07-26
08 Mirja Kühlewind
[Ballot comment]
One comment/question:

I got stuck a little with the following sentences:
  "HTTP/1.1 [RFC7230] is the REQUIRED transport layer for this …
[Ballot comment]
One comment/question:

I got stuck a little with the following sentences:
  "HTTP/1.1 [RFC7230] is the REQUIRED transport layer for this protocol.
  HTTP/2 [RFC7540] is an OPTIONAL transport layer for this protocol."
I know the first one was there already in the RFC, but I'm just wondering if it is intentional to not say anything about the transport protocol underneath HTTP or not. Because RFC7230 is specified for the use with TCP but does not prohibit the usage of other transport protocol (given we would have another one that could fulfill the needed requirements). Should this doc explicitly says that HTTP1.1 over TCP or TLS/TCP, or is this not important?
2016-07-26
08 Mirja Kühlewind Ballot comment text updated for Mirja Kühlewind
2016-07-26
08 Mirja Kühlewind
[Ballot comment]
One comment/question:

I got stuck a little with the following sentencses:
  "HTTP/1.1 [RFC7230] is the REQUIRED transport layer for this …
[Ballot comment]
One comment/question:

I got stuck a little with the following sentencses:
  "HTTP/1.1 [RFC7230] is the REQUIRED transport layer for this protocol.
  HTTP/2 [RFC7540] is an OPTIONAL transport layer for this protocol."
I know the first one was there already in the RFC, but I'm just wondering if it is intentional to not say anything about the transport protocol underneath HTTP or not. Because RFC7230 is specified for the use with TCP but does not prohibit the usage of other transport protocol (given we would have another one that could fullfil the needed requiremnets). Should this doc explictly says that HTTP1.1 over TCP or TLS/TCP, or is this not important?
2016-07-26
08 Mirja Kühlewind Ballot comment text updated for Mirja Kühlewind
2016-07-26
08 Mirja Kühlewind
[Ballot comment]
One comment/question:

I got stuck a little with the following sentencses:
"HTTP/1.1 [RFC7230] is the REQUIRED transport layer for this protocol. …
[Ballot comment]
One comment/question:

I got stuck a little with the following sentencses:
"HTTP/1.1 [RFC7230] is the REQUIRED transport layer for this protocol.
  HTTP/2 [RFC7540] is an OPTIONAL transport layer for this protocol."
I know the first one was there already in the RFC, but I'm just wondering if it is intentional to not say anything about the transport protocol underneath HTTP or not. Because RFC7230 is specified for the use with TCP but does not prohibit the usage of other transport protocol (given we would have another one that could fullfil the needed requiremnets). Should this doc explictly says that HTTP1.1 over TCP or TLS/TCP, or is this not important?
2016-07-26
08 Mirja Kühlewind Ballot comment text updated for Mirja Kühlewind
2016-07-26
08 Mirja Kühlewind
[Ballot comment]
One comment/question:

I got stuck a little with the following sentencses:
"HTTP/1.1 [RFC7230] is the REQUIRED transport layer for this protocol. …
[Ballot comment]
One comment/question:

I got stuck a little with the following sentencses:
"HTTP/1.1 [RFC7230] is the REQUIRED transport layer for this protocol.
  HTTP/2 [RFC7540] is an OPTIONAL transport layer for this protocol."
I know the first one was there already in the RFC, but I'm just wondering if it is intentional to not say anything about the transport protocol underneath HTTP or not. Because RFC7230 is specified for the use with TCP but does not prohibit the usage of other transport protocol (given we would have another one that could fullfil the needed requiremnets). Should this doc explictly says that HTTP1.1 over TCP or TLS/TCP, or is this not important?
2016-07-26
08 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2016-07-25
08 Gunter Van de Velde Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Mahesh Jethanandani.
2016-07-11
08 Alexey Melnikov Ballot has been issued
2016-07-11
08 Alexey Melnikov [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov
2016-07-11
08 Alexey Melnikov Created "Approve" ballot
2016-07-11
08 Alexey Melnikov Ballot writeup was changed
2016-07-11
08 Alexey Melnikov IESG state changed to IESG Evaluation from Waiting for Writeup
2016-07-11
08 (System) IESG state changed to Waiting for Writeup from In Last Call
2016-07-06
08 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2016-07-06
08 Sabrina Tanamal
(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

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

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

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

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the application subregistry of the Media Types registry located at:

https://www.iana.org/assignments/media-types/

the existing registration for ipp is to be amended. The information in Section 6 of the current draft is to be incorporated into the document located at:

https://www.iana.org/assignments/media-types/application/ipp

The reference for this registration is to be changed to [ RFC-to-be ].

IANA understands that this is the only action required to be completed 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
2016-06-29
08 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Mahesh Jethanandani
2016-06-29
08 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Mahesh Jethanandani
2016-06-27
08 Alexey Melnikov Placed on agenda for telechat - 2016-08-04
2016-06-21
08 Barry Leiba
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 …
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.
2016-06-20
08 Jouni Korhonen Assignment of request for Last Call review by OPSDIR to Jouni Korhonen was rejected
2016-06-20
08 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jouni Korhonen
2016-06-20
08 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jouni Korhonen
2016-06-17
08 Tero Kivinen Request for Last Call review by SECDIR is assigned to Tobias Gondrom
2016-06-17
08 Tero Kivinen Request for Last Call review by SECDIR is assigned to Tobias Gondrom
2016-06-16
08 Jean Mahoney Request for Last Call review by GENART is assigned to Matthew Miller
2016-06-16
08 Jean Mahoney Request for Last Call review by GENART is assigned to Matthew Miller
2016-06-13
08 Amy Vezza IANA Review state changed to IANA - Review Needed
2016-06-13
08 Amy Vezza
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-rfc2910bis@ietf.org
Reply-To: ietf@ietf.org
Sender: …
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-rfc2910bis@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Internet Printing Protocol/1.1: Encoding and Transport) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'Internet Printing Protocol/1.1: Encoding and Transport'
  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-11. 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 a new Internet Printing Protocol (IPP).  IPP is an
  application level protocol that can be used for distributed printing
  using Internet tools and technologies.  This document defines the
  rules for encoding IPP operations and IPP attributes into the
  Internet MIME media type called "application/ipp".  This document
  also defines the rules for transporting a message body whose Content-
  Type is "application/ipp" over HTTP.




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

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


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


2016-06-13
08 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2016-06-13
08 Alexey Melnikov Last call was requested
2016-06-13
08 Alexey Melnikov Ballot approval text was generated
2016-06-13
08 Alexey Melnikov Ballot writeup was generated
2016-06-13
08 Alexey Melnikov IESG state changed to Last Call Requested from AD Evaluation
2016-06-13
08 Alexey Melnikov Last call announcement was generated
2016-06-13
08 Alexey Melnikov
The latest text is an improvement, but this might still be worth clarifying:

In 8.1.2:

      IPP Clients and Printers MAY support Basic …
The latest text is an improvement, but this might still be worth clarifying:

In 8.1.2:

      IPP Clients and Printers MAY support Basic
      Authentication [RFC7617] for User Authentication if the channel is
      secure.

I think you need to expand on what "secure" means here. I think you meant that TLS was successfully negotiated and the TLS server identity was verified successfully by the client.
2016-06-13
08 Michael Sweet New version available: draft-sweet-rfc2910bis-08.txt
2016-06-10
07 Alexey Melnikov Notification list changed to "Barry Leiba" <barryleiba@computer.org>
2016-06-10
07 Alexey Melnikov Document shepherd changed to Barry Leiba
2016-06-07
07 Alexey Melnikov Changed consensus to Yes from Unknown
2016-06-07
07 Alexey Melnikov Some minor issues that need to be addressed before IESG review, but can issue IETF LC now.
2016-06-07
07 Alexey Melnikov IESG state changed to AD Evaluation from Publication Requested
2016-06-07
07 Alexey Melnikov
My AD review:

A small note about referencing "Model" (rfc2911bis). This is an issue with generated HTML, but text like:

  The first three fields …
My AD review:

A small note about referencing "Model" (rfc2911bis). This is an issue with generated HTML, but text like:

  The first three fields in the above diagram contain the value of
  attributes described in Section 3.1.1 of the Model.

produces a link that points to rfc2910bis and not rfc2911bis. Something like:

  ... Model [rfc2911bis].

would be better. This can probably be sorted out by the RFC Editor, but you might want to fix this yourself.


Issues found by ID-nits:

  == Unused Reference: 'IANA-CON' is defined on line 1508, but no explicit
    reference was found in the text

-- I suggest removing the reference.

  ** Obsolete normative reference: RFC 1903 (Obsoleted by RFC 2579)

-- It looks like updating to RFC 2579 is the right thing here.

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

    -- This is Ok, already in the DownRef registry. So just ignore this.

Other issues:

In Section 3:

The first reference to a charset needs a reference to RFC 2978.

In 3.2:

  begin-attribute-group-tag = %x00-02 / %x04-0F ; see section 3.5.1

s/%04/%x04

(you are missing "x", without it the ABNF is not syntactically valid).

3.8.  Value Length

  For any of the types represented by binary signed bytes, the sender
  MUST encode the value in exactly one octet.

Can you give me an example? Are you talking about booleans or something else?


In 8.1.2:

      IPP Clients and Printers MAY support Basic
      Authentication [RFC7617] for User Authentication if the channel is
      secure.

I think you need to expand on what "secure" means here. I think you meant that TLS was successfully negotiated and the TLS server identity was verified successfully by the client.

In Section 9:

When you mention IPP/2.0, 2.1 or 2.2, you should have a Normative reference to relevant specs, because you use them in a SHOULD-level requirement.


In Appendix B:

          This section is strictly informative.  The MIME media type listed in
          this section should not be re-registered by IANA when this document
          is published.

I think this is wrong. The IANA registration template is out of date. It is missing "Change Controller", etc. See RFC 6838, section 5.6.

So I think this needs to be updated and also mentioned in the IANA Considerations section.
2016-06-03
07 Alexey Melnikov Assigned to Applications and Real-Time Area
2016-06-03
07 Alexey Melnikov Intended Status changed to Proposed Standard
2016-06-03
07 Alexey Melnikov IESG process started in state Publication Requested
2016-06-03
07 Alexey Melnikov Stream changed to IETF from None
2015-12-15
07 Michael Sweet New version available: draft-sweet-rfc2910bis-07.txt
2015-12-02
06 Michael Sweet New version available: draft-sweet-rfc2910bis-06.txt
2015-07-21
05 Michael Sweet New version available: draft-sweet-rfc2910bis-05.txt
2015-06-10
04 Michael Sweet New version available: draft-sweet-rfc2910bis-04.txt
2015-05-27
03 Michael Sweet New version available: draft-sweet-rfc2910bis-03.txt
2015-05-08
02 Michael Sweet New version available: draft-sweet-rfc2910bis-02.txt
2015-04-29
01 Michael Sweet New version available: draft-sweet-rfc2910bis-01.txt
2015-04-25
00 Michael Sweet New version available: draft-sweet-rfc2910bis-00.txt