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>