attachment

<div dir="ltr"><div><div><div><div><div><div>Hi Smith,<br><br></div>I just found this interesting higher level summary of the functions and methodology<br></div>of IANA written by Jari Arkko, Chair of the IETF:<br><br>&nbsp; <a href="http://www.ietf.org/blog/2014/01/iana/">http://www.ietf.org/blog/2014/01/iana/</a><br>

<br></div>I&#39;m still searching for an I-D or an ICANN/IANA policy that discusses dual-use ports<br></div>(for UDP/DTLS or TCP/TLS) and IETF recommendations for supporting them.<br><br></div>Cheers,<br></div>- Ira<br><br>

</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 &amp; 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&nbsp; 579 Park Place&nbsp; Saline, MI&nbsp; 48176&nbsp; 734-944-0094<br>Summer&nbsp; PO Box 221&nbsp; Grand Marais, MI 49839&nbsp; 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 1:31 PM, Kennedy, Smith (Wireless Architect) <span dir="ltr">&lt;<a href="mailto:smith.kennedy@hp.com" target="_blank">smith.kennedy@hp.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Thanks Ira! &nbsp;<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. &nbsp;Unfortunately RFC 6335 doesn&rsquo;t contain statements or references to documents that state the IESG&rsquo;s position on this. &nbsp;</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>

<span class="HOEnZb"><font color="#888888"><br></font></span><div><span class="HOEnZb"><font color="#888888"><div>
Smith<br><br><br>

</div></font></span><div><div class="h5">

<br><div><div>On 2014-02-28, at 9:19 AM, Ira McDonald &lt;<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>&gt; wrote:</div><br><blockquote type="cite"><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&#39;ll issue a new draft soon that incorporates all of these improvements.&nbsp; 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&#39;t do it with IPP 1.1, RFC 2911).&nbsp; <br><br>(2) I think there&#39;s an IAB (parent of IESG) policy somewhere (maybe an RFC)<br></div><div>about port registration.<br><br>(3) Note that the &quot;System&quot; 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 &quot;ipps:&quot; we aren&#39;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 (&quot;ipps:&quot;) in CUPS<br></div>and supported by multiple printer vendors, we can&#39;t change the port number<br>



</div>now (and the IESG would block the publication of &quot;ipps:&quot; entirely if we tried<br>to do so).<br><div><div><br></div><div>BTW - here&#39;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" target="_blank">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 &amp; 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&nbsp; 579 Park Place&nbsp; Saline, MI&nbsp; 48176&nbsp; <a href="tel:734-944-0094" value="+17349440094" target="_blank">734-944-0094</a><br>Summer&nbsp; PO Box 221&nbsp; Grand Marais, MI 49839&nbsp; <a href="tel:906-494-2434" value="+19064942434" target="_blank">906-494-2434</a><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">&lt;<a href="mailto:smith.kennedy@hp.com" target="_blank">smith.kennedy@hp.com</a>&gt;</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 &ldquo;IPP over HTTPS and &rsquo;ipps&rsquo; URI Scheme&rdquo; document, and they had some questions about port numbers, which triggered my re-reading it. &nbsp;I wish to report the following issues:<br>
<br>
<br>
Section 3 item (2), Page 7:<br>
<br>
&nbsp; &nbsp; 2) The IPP Client converts the &rsquo;ipps&rsquo; URI to an &rsquo;https&rsquo; URI<br>
&nbsp; &nbsp; &nbsp; &nbsp;(replacing &rsquo;ipps&rsquo; with &rsquo;https&rsquo; 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. &nbsp;To accommodate this, I think it is more appropriate for this clause to be phrased more along these lines:<br>




<br>
&nbsp; &nbsp; 2) The IPP Client converts the &rsquo;ipps&rsquo; URI to an &rsquo;https&rsquo; URI<br>
&nbsp; &nbsp; &nbsp; &nbsp;(replacing &rsquo;ipps&rsquo; with &rsquo;https&rsquo; and inserting the port number<br>
&nbsp; &nbsp; &nbsp; &nbsp;from the URI or port 631 if the URI doesn&rsquo;t include a port<br>
&nbsp; &nbsp; &nbsp; &nbsp;number);<br>
<br>
<br>
Section 4.2, Page 9:<br>
<br>
&nbsp; &nbsp; Note: &nbsp;IPP Printers ought to be cautious about depending on URI<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;lengths above 255 bytes, because some older IPP Client<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;implementations might not properly support these lengths.<br>
<br>
Should &ldquo;ought&rdquo; really rather be &ldquo;SHOULD&rdquo;?<br>
<br>
<br>
Section 4.2, Page 9: This should include a reference to section 4.3:<br>
<br>
&nbsp; &nbsp; 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>
&nbsp; &nbsp; An &rsquo;ipps&rsquo; URI is transformed into an &rsquo;https&rsquo; URI by replacing &quot;ipps:&quot;<br>
&nbsp; &nbsp; with &quot;https:&quot; and inserting port 631 (if the &rsquo;port&rsquo; is not present in<br>
&nbsp; &nbsp; the original &rsquo;ipps&rsquo; 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. &nbsp;This should be included for the sake of those that aren&rsquo;t familiar with this newer &ldquo;port number allocation design pattern&rdquo; being used by IANA and the IETF.<br>




<br>
<br>
Section 4.6.1, Page 11: &ldquo;The first and second &rsquo;ipps&rsquo; URI above MUST be resolved to port 631 (IANA assigned well-known port for IPP).&rdquo; 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>
&nbsp; &nbsp; - A port that is empty or not given MUST be treated as equivalent to<br>
&nbsp; &nbsp; &nbsp; the well-known port for that &rsquo;ipps&rsquo; URI (port 631).<br>
<br>
<br>
Section 5.1, Page 13: Grammatical error:<br>
<br>
&nbsp; &nbsp; d) MUST the required TLS version(s) according to the corresponding<br>
&nbsp; &nbsp; &nbsp; &nbsp;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>
&nbsp; &nbsp; e) MUST only send IPP protocol connections to IANA assigned<br>
&nbsp; &nbsp; &nbsp; &nbsp;well-known port 631 or to the explicit port specified in a given<br>
&nbsp; &nbsp; &nbsp; &nbsp;&rsquo;ipps&rsquo; URI;<br>
<br>
<br>
Section 5.2, Page 14: Grammatical error<br>
<br>
&nbsp; &nbsp; d) MUST the required TLS version(s) according to the corresponding<br>
&nbsp; &nbsp; &nbsp; &nbsp;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>
&nbsp; &nbsp; e) MUST only listen for incoming IPP protocol connections on<br>
&nbsp; &nbsp; &nbsp; &nbsp;IANA-assigned well-known port 631 and MUST NOT listen for incoming<br>
&nbsp; &nbsp; &nbsp; &nbsp;IPP protocol connections on any other port, unless explicitly<br>
&nbsp; &nbsp; &nbsp; &nbsp;configured by system administrators or site policies;<br>
<br>
<br>
Section 7.2.4, Page 18: Grammatical error - extra instance of &ldquo;or&rdquo;<br>
<br>
&nbsp; &nbsp; Either service discovery or directory protocols SHOULD be used first<br>
&nbsp; &nbsp; 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. &nbsp;This should be included for the sake of those that aren&rsquo;t familiar with this newer &ldquo;port number allocation design pattern&rdquo; being used by IANA and the IETF. &nbsp;There is a reference to [PORTREG] in section 9.2 but this seems inadequate to me.<br>




<br>
I&rsquo;ve marked up copy of the PDF draft, that I will send to Ira separately so I don&rsquo;t spam everyone else. &nbsp;I don&rsquo;t know if this feedback is &ldquo;too late&rdquo; but I thought I&rsquo;d send it on anyway.<br>
<br>
Cheers,<br>
<br>
Smith<br>
<br>
/**<br>
&nbsp; &nbsp; Smith Kennedy<br>
&nbsp; &nbsp; Hewlett-Packard Co.<br>
*/<br>
<br>
<br>
<br>
<br>_______________________________________________<br>
ipp mailing list<br>
<a href="mailto:ipp@pwg.org" target="_blank">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></div></div></div></blockquote></div><br></div>