attachment
Hi Smith,<br><br>Ahem...the reference from RFC 2817 (HTTP Upgrade) to IPP is an *informative*<br>reference to the *obsolete* RFC 2565 (IPP/1.0 Model), which itself contains the<br>IESG "poison pill" that says (partially):<br><br> "This document defines an Experimental protocol for the Internet<br> community. The IESG expects that a revised version of this protocol<br> will be published as Proposed Standard protocol. The Proposed<br> Standard, when published, is expected to change from the protocol<br> defined in this memo. In particular, it is expected that the<br> standards-track version of the protocol will incorporate strong<br> authentication and privacy features, and that an "ipp:" URL type will<br> be defined which supports those security measures."<br><br>The IESG really disliked IPP/1.0 (for valid security flaw reasons).<br><br>IPP/1.0 was marked obsolete when RFC 2911 (IPP/1.1) was published<br>15 years ago, so the discussions in RFC 2817 are not a good source<br>for guidance on port usage (dual or overloaded single).<br><br>Cheers,<br>- Ira<br><br clear="all"><div><div class="gmail_signature"><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></div>
<br><div class="gmail_quote">On Wed, Dec 10, 2014 at 2:53 PM, 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"><div style="word-wrap:break-word">Hi Ira,<div><br></div><div>I know this is a long-stale thread, but I was just re-reading RFC 2817, and Section 1 “Motivation” says this, which is germane to this subject (and even references IPP!):</div><div><br></div><div>
<div title="Page 2">
<div>
<div>
<pre><span style="font-family:Courier;font-size:10pt">1. Motivation</span></pre><pre><span style="font-size:10.000000pt;font-family:'Courier'"> The historical practice of deploying HTTP over SSL3 [3] has
distinguished the combination from HTTP alone by a unique URI scheme
and the TCP port number. The scheme ’http’ meant the HTTP protocol
alone on port 80, while ’https’ meant the HTTP protocol over SSL on
port 443. Parallel well-known port numbers have similarly been
requested -- and in some cases, granted -- to distinguish between
secured and unsecured use of other application protocols (e.g.
snews, ftps). This approach effectively halves the number of
available well known ports.
</span></pre>
<pre><span style="font-size:10.000000pt;font-family:'Courier'"> At the Washington DC IETF meeting in December 1997, the Applications
Area Directors and the IESG reaffirmed that the practice of issuing
parallel "secure" port numbers should be deprecated. The HTTP/1.1
Upgrade mechanism can apply Transport Layer Security [6] to an open
HTTP connection.
</span></pre>
</div>
</div>
</div></div><div>Just wanted to share this with the group, for whatever reason.</div><div><br><div>
<div style="text-align:start;text-indent:0px;word-wrap:break-word"><div style="text-align:start;text-indent:0px;word-wrap:break-word"><div style="text-align:-webkit-auto;text-indent:0px;word-wrap:break-word"><div style="text-align:-webkit-auto;text-indent:0px;word-wrap:break-word">Smith<br><br>/**<br> Smith Kennedy<br> Wireless Architect - Client Software - IPG-PPS<br> Hewlett-Packard Co.<br>*/<br><br><br></div></div></div></div>
</div><div><div class="h5">
<br><div><blockquote type="cite"><div>On 2014-04-07, at 2:50 PM, Ira McDonald <<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><div><div><div><div><div><div><div>Hi,<br><br></div>Found this afternoon by browsing of I-Ds from the active IETF WGs<br></div>top-level list:<br><br><a href="https://datatracker.ietf.org/doc/draft-ietf-tsvwg-port-use/" target="_blank">https://datatracker.ietf.org/doc/draft-ietf-tsvwg-port-use/</a><br>
</div><br>NOTE: This document does consider reuse of the same port for both<br></div>ordinary and secure implementations of the same service. It doesn't<br>take a position, except that the whole document is about conservation<br>
</div>of the IANA-assigned port space.<br><br></div>Certainly our port 631 reuse in 'ipp:' and 'ipps:' URI is allowed (and <br>apparently encouraged) by this I-D.<br><br></div><div>Cheers,<br></div><div>- Ira<br>
<br clear="all"></div><div><div><div><div><div><div><div><div><div><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 <a href="tel:734-944-0094" value="+17349440094" target="_blank">734-944-0094</a><br>Summer PO Box 221 Grand Marais, MI 49839 <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>
</div></div></div></div></div></div></div></div></div></div>
</div></blockquote></div><br></div></div></div></div></blockquote></div><br>