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

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?

(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"?

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.

Mahesh Jethanandani <mjethanandani@gmail.com> performed the opsdir review

Thanks for addressing my prior discuss and 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?

- 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