Greetings,
Some folks in HP were reading over the “IPP over HTTPS and ’ipps’ URI Scheme” document, and they had some questions about port numbers, which triggered my re-reading it. I wish to report the following issues:
Section 3 item (2), Page 7:
2) The IPP Client converts the ’ipps’ URI to an ’https’ URI
(replacing ’ipps’ with ’https’ and inserting port 631);
This overlooks the possibility that there may be an alternate port in the URI, as described more completely in section 4.2. To accommodate this, I think it is more appropriate for this clause to be phrased more along these lines:
2) The IPP Client converts the ’ipps’ URI to an ’https’ URI
(replacing ’ipps’ with ’https’ and inserting the port number
from the URI or port 631 if the URI doesn’t include a port
number);
Section 4.2, Page 9:
Note: IPP Printers ought to be cautious about depending on URI
lengths above 255 bytes, because some older IPP Client
implementations might not properly support these lengths.
Should “ought” really rather be “SHOULD”?
Section 4.2, Page 9: This should include a reference to section 4.3:
If the port is empty or not given, then port 631 MUST be used.
Section 4.3, Page 10: This should include a reference to section 4.3:
An ’ipps’ URI is transformed into an ’https’ URI by replacing "ipps:"
with "https:" and inserting port 631 (if the ’port’ is not present in
the original ’ipps’ URI).
Section 4.3, Page 10: Missing mention of RFC 6335 or similar references, that provide an explanation why the existing well-known port number (631) is being overloaded for the TLS variant may be appropriate. This should be included for the sake of those that aren’t familiar with this newer “port number allocation design pattern” being used by IANA and the IETF.
Section 4.6.1, Page 11: “The first and second ’ipps’ URI above MUST be resolved to port 631 (IANA assigned well-known port for IPP).” should refer to section 4.3.
Section 4.7, Page 12: This should include a reference to section 4.3:
- A port that is empty or not given MUST be treated as equivalent to
the well-known port for that ’ipps’ URI (port 631).
Section 5.1, Page 13: Grammatical error:
d) MUST the required TLS version(s) according to the corresponding
IPP versions as defined in section 7 of this specification;
Section 5.1, Page 13: Include a reference to section 4.3:
e) MUST only send IPP protocol connections to IANA assigned
well-known port 631 or to the explicit port specified in a given
’ipps’ URI;
Section 5.2, Page 14: Grammatical error
d) MUST the required TLS version(s) according to the corresponding
IPP versions as defined in section 7 of this specification;
Section 5.2, Page 14: This clause should also include either a reference to and/or a statement that port 631 is to be used for both conventional IPP over HTTP as well as IPP over HTTPS.
e) MUST only listen for incoming IPP protocol connections on
IANA-assigned well-known port 631 and MUST NOT listen for incoming
IPP protocol connections on any other port, unless explicitly
configured by system administrators or site policies;
Section 7.2.4, Page 18: Grammatical error - extra instance of “or”
Either service discovery or directory protocols SHOULD be used first
or or an IPP Client SHOULD first
Section 9: Add reference to RFC 6335 or similar references, that provide an explanation why the existing well-known port number (631) is being overloaded for the TLS variant may be appropriate. This should be included for the sake of those that aren’t familiar with this newer “port number allocation design pattern” being used by IANA and the IETF. There is a reference to [PORTREG] in section 9.2 but this seems inadequate to me.
I’ve marked up copy of the PDF draft, that I will send to Ira separately so I don’t spam everyone else. I don’t know if this feedback is “too late” but I thought I’d send it on anyway.
Cheers,
Smith
/**
Smith Kennedy
Hewlett-Packard Co.
*/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4956 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140228/cc1c6831/attachment.p7s>