[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 16:19:44 UTC 2014


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/53f91742/attachment.html>


More information about the ipp mailing list