[IPP] A few points of feedback on "IPP over HTTPS and 'ipps' URI Scheme" draft 9

[IPP] A few points of feedback on "IPP over HTTPS and 'ipps' URI Scheme" draft 9

[IPP] A few points of feedback on "IPP over HTTPS and 'ipps' URI Scheme" draft 9

Ira McDonald blueroofmusic at gmail.com
Fri Feb 28 22:27:19 UTC 2014


Hi Smith,

I just found this interesting higher level summary of the functions and
methodology
of IANA written by Jari Arkko, Chair of the IETF:

  http://www.ietf.org/blog/2014/01/iana/

I'm still searching for an I-D or an ICANN/IANA policy that discusses
dual-use ports
(for UDP/DTLS or TCP/TLS) and IETF recommendations for supporting them.

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: blueroofmusic at gmail.com
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434



On Fri, Feb 28, 2014 at 1:31 PM, Kennedy, Smith (Wireless Architect) <
smith.kennedy at hp.com> wrote:

> Thanks Ira!
>
> 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.
>
> 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.
>
> Smith
>
>
>
> On 2014-02-28, at 9:19 AM, Ira McDonald <blueroofmusic at gmail.com> wrote:
>
> Hi Smith and HP folks,
>
> These excellent comments are all very timely!
>
> I'll issue a new draft soon that incorporates all of these improvements.
> We
> hope to convince the IETF Applications Area Directors to put that version
> into IETF Apps Last Call and assign a Document Shepherd to then take it
> to IETF Last Call.
>
> Related to approaches for using a single port for both a plain application
> protocol (over TCP) and equivalent secure version (over TLS over TCP):
>
> (1) The IESG (steering group that oversees the IETF) decided against any
> more dual-port registrations for application protocols over ten years ago
> (we were told we couldn't do it with IPP 1.1, RFC 2911).
>
> (2) I think there's an IAB (parent of IESG) policy somewhere (maybe an RFC)
> about port registration.
>
> (3) Note that the "System" range of port numbers (up to 1023), intended
> for OS kernel support and assigned by IESG to standards-track RFCs, has
> long since been exhausted.
>
> (4) In a standards-track RFC for "ipps:" we aren't allowed to put an annex
> with code fragments - but such guidance could be published by the PWG.
>
> (5) Since port 631 has been in use for years for secure IPP ("ipps:") in
> CUPS
> and supported by multiple printer vendors, we can't change the port number
> now (and the IESG would block the publication of "ipps:" entirely if we
> tried
> to do so).
>
> BTW - here's the link to the current IANA port and service names registry:
>
>
> http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml
>
>  Cheers,
> - Ira
>
>
>
> Ira McDonald (Musician / Software Architect)
> Co-Chair - TCG Trusted Mobility Solutions WG
> Chair - Linux Foundation Open Printing WG
> Secretary - IEEE-ISTO Printer Working Group
> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music / High North Inc
> http://sites.google.com/site/blueroofmusic
> http://sites.google.com/site/highnorthinc
> mailto: blueroofmusic at gmail.com
> Winter  579 Park Place  Saline, MI  48176  734-944-0094
> Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434
>
>
>
> On Fri, Feb 28, 2014 at 12:33 AM, Kennedy, Smith (Wireless Architect) <
> smith.kennedy at hp.com> wrote:
>
>> 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.
>> */
>>
>>
>>
>>
>> _______________________________________________
>> ipp mailing list
>> ipp at pwg.org
>> https://www.pwg.org/mailman/listinfo/ipp
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140228/bd3cbd53/attachment.html>


More information about the ipp mailing list