attachment
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Thanks Ira! <div><br></div><div>I did look at the IANA port registry page, at the top of which there are many references to RFC 6335. Unfortunately RFC 6335 doesn’t contain statements or references to documents that state the IESG’s position on this. </div><div><br></div><div>One could imagine an informative RFC that updates RFC 6335 and also includes a code example demonstrating how to support TLS and non-TLS variants using POSIX sockets and openssl or similar free software APIs.<div><br><div><div>
Smith<br><br><br>
</div>
<br><div><div>On 2014-02-28, at 9:19 AM, Ira McDonald <<a href="mailto:blueroofmusic@gmail.com">blueroofmusic@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"><div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div>Hi Smith and HP folks,<br><br></div>These excellent comments are all very timely!<br><br></div>I'll issue a new draft soon that incorporates all of these improvements. We<br>
</div><div>hope to convince the IETF Applications Area Directors to put that version<br></div><div>into IETF Apps Last Call and assign a Document Shepherd to then take it<br></div><div>to IETF Last Call.<br></div><br>Related to approaches for using a single port for both a plain application <br>
protocol (over TCP) and equivalent secure version (over TLS over TCP):<br></div><br></div>(1) The IESG (steering group that oversees the IETF) decided against any<br></div>more dual-port registrations for application protocols over ten years ago<br>
</div>(we were told we couldn't do it with IPP 1.1, RFC 2911). <br><br>(2) I think there's an IAB (parent of IESG) policy somewhere (maybe an RFC)<br></div><div>about port registration.<br><br>(3) Note that the "System" range of port numbers (up to 1023), intended <br>
for OS kernel support and assigned by IESG to standards-track RFCs, has <br>long since been exhausted.</div></div><div><br></div>(4) In a standards-track RFC for "ipps:" we aren't allowed to put an annex<br>
</div>with code fragments - but such guidance could be published by the PWG.<br><br></div>(5) Since port 631 has been in use for years for secure IPP ("ipps:") in CUPS<br></div>and supported by multiple printer vendors, we can't change the port number<br>
</div>now (and the IESG would block the publication of "ipps:" entirely if we tried<br>to do so).<br><div><div><br></div><div>BTW - here's the link to the current IANA port and service names registry:<br>
<br><a href="http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml">http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml</a><br><br></div><div>
<div><div>Cheers,<br></div><div>- Ira<br><br></div><div><br></div></div></div></div></div><div class="gmail_extra">
<br clear="all"><div><div dir="ltr">Ira McDonald (Musician / Software Architect)<br>Co-Chair - TCG Trusted Mobility Solutions WG<br>Chair - Linux Foundation Open Printing WG<br>Secretary - IEEE-ISTO Printer Working Group<br>
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG<br>IETF Designated Expert - IPP & Printer MIB<br>Blue Roof Music / High North Inc<br><a style="color:rgb(51,51,255)" href="http://sites.google.com/site/blueroofmusic" target="_blank">http://sites.google.com/site/blueroofmusic</a><br>
<a style="color:rgb(102,0,204)" href="http://sites.google.com/site/highnorthinc" target="_blank">http://sites.google.com/site/highnorthinc</a><br>mailto: <a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br>
Winter 579 Park Place Saline, MI 48176 734-944-0094<br>Summer PO Box 221 Grand Marais, MI 49839 906-494-2434<br><br><div style="display:inline"></div><div style="display:inline"></div><div style="display:inline"></div>
<div></div><div></div><div></div><div></div></div></div>
<br><br><div class="gmail_quote">On Fri, Feb 28, 2014 at 12:33 AM, Kennedy, Smith (Wireless Architect) <span dir="ltr"><<a href="mailto:smith.kennedy@hp.com" target="_blank">smith.kennedy@hp.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Greetings,<br>
<br>
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:<br>
<br>
<br>
Section 3 item (2), Page 7:<br>
<br>
2) The IPP Client converts the ’ipps’ URI to an ’https’ URI<br>
(replacing ’ipps’ with ’https’ and inserting port 631);<br>
<br>
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:<br>
<br>
2) The IPP Client converts the ’ipps’ URI to an ’https’ URI<br>
(replacing ’ipps’ with ’https’ and inserting the port number<br>
from the URI or port 631 if the URI doesn’t include a port<br>
number);<br>
<br>
<br>
Section 4.2, Page 9:<br>
<br>
Note: IPP Printers ought to be cautious about depending on URI<br>
lengths above 255 bytes, because some older IPP Client<br>
implementations might not properly support these lengths.<br>
<br>
Should “ought” really rather be “SHOULD”?<br>
<br>
<br>
Section 4.2, Page 9: This should include a reference to section 4.3:<br>
<br>
If the port is empty or not given, then port 631 MUST be used.<br>
<br>
<br>
Section 4.3, Page 10: This should include a reference to section 4.3:<br>
<br>
An ’ipps’ URI is transformed into an ’https’ URI by replacing "ipps:"<br>
with "https:" and inserting port 631 (if the ’port’ is not present in<br>
the original ’ipps’ URI).<br>
<br>
<br>
<br>
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.<br>
<br>
<br>
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.<br>
<br>
<br>
Section 4.7, Page 12: This should include a reference to section 4.3:<br>
<br>
- A port that is empty or not given MUST be treated as equivalent to<br>
the well-known port for that ’ipps’ URI (port 631).<br>
<br>
<br>
Section 5.1, Page 13: Grammatical error:<br>
<br>
d) MUST the required TLS version(s) according to the corresponding<br>
IPP versions as defined in section 7 of this specification;<br>
<br>
<br>
Section 5.1, Page 13: Include a reference to section 4.3:<br>
<br>
e) MUST only send IPP protocol connections to IANA assigned<br>
well-known port 631 or to the explicit port specified in a given<br>
’ipps’ URI;<br>
<br>
<br>
Section 5.2, Page 14: Grammatical error<br>
<br>
d) MUST the required TLS version(s) according to the corresponding<br>
IPP versions as defined in section 7 of this specification;<br>
<br>
<br>
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.<br>
<br>
e) MUST only listen for incoming IPP protocol connections on<br>
IANA-assigned well-known port 631 and MUST NOT listen for incoming<br>
IPP protocol connections on any other port, unless explicitly<br>
configured by system administrators or site policies;<br>
<br>
<br>
Section 7.2.4, Page 18: Grammatical error - extra instance of “or”<br>
<br>
Either service discovery or directory protocols SHOULD be used first<br>
or or an IPP Client SHOULD first<br>
<br>
<br>
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.<br>
<br>
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.<br>
<br>
Cheers,<br>
<br>
Smith<br>
<br>
/**<br>
Smith Kennedy<br>
Hewlett-Packard Co.<br>
*/<br>
<br>
<br>
<br>
<br>_______________________________________________<br>
ipp mailing list<br>
<a href="mailto:ipp@pwg.org">ipp@pwg.org</a><br>
<a href="https://www.pwg.org/mailman/listinfo/ipp" target="_blank">https://www.pwg.org/mailman/listinfo/ipp</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div></div></div></body></html>