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 |