Smith Kennedy Sep 16, 2016

Resolved / closed / will not change

Smith Kennedy Sep 16, 2016

Ira McDonald said this via the IPP WG reflector:

PWG 5100.14 doesn't say you MUST support Upgrade, BUT it does say
the rest about advertise and support ipps URIs. 

And PWG 5100.14 also says you MUST do IPP/2.0 (PWG 5100.12), which
says on page 33:

7.4 IPP over TLS Conformance Requirements
To claim conformance to this specification, an IPP Printer or IPP Client
that supports TLS MUST:

1. Support the HTTP Upgrade protocol as defined in [RFC2817]; and
2. Support the required minimum cipher suite for interoperability defined
in the claimed TLS specification.

I didn't need to but I confirmed that Ira's assertions were correct, so I think we can close this because it is  mandated by IPP/2.0.

Michael Sweet Sep 15, 2016

IETF RFCs use conformance terms less liberally than we do in PWG specifications (only for interop).

In this case the text is directive: HTTP Upgrade is the only way you negotiate a TLS session from an unencrypted HTTP connection associated with the "ipp" URI.

As for adding a normative reference to 2910, we can certainly do that but 2911 already does...

Smith Kennedy Sep 15, 2016

Reviewing https://tools.ietf.org/html/draft-sweet-rfc2910bis-10, I'm not seeing language that matches that. The only mention of "2817" or "Upgrade" is in section 8.2:

8.2.  Using IPP with TLS

   IPP uses the "Upgrading to TLS Within HTTP/1.1" mechanism [RFC2817]
   for 'ipp' URIs.  The Client requests a secure TLS connection by using
   the HTTP "Upgrade" header, while the server agrees in the HTTP
   response.  The switch to TLS occurs either because the server grants
   the Client's request to upgrade to TLS, or a server asks to switch to
   TLS in its response.  Secure communication begins with a server's
   response to switch to TLS.

   IPP uses the "HTTPS: HTTP over TLS" mechanism [RFC2818] for 'ipps'
   URIs.  The Client and server negotiate a secure TLS connection
   immediately and unconditionally.

In my reading of that section, nowhere does it say that HTTP Upgrade is conditionally required. This seems more "informative" than "normative".

Smith Kennedy Sep 15, 2016

OK, in that case, 5100.20 should include RFC 2910 in the Normative References section and add [RFC2910] to the end of that passage I quoted.

Smith Kennedy Sep 15, 2016

OK, in that case, 5100.20 should include RFC 2910 in the Normative References section and add [RFC2910] to the end of that passage I quoted.

Smith Kennedy Sep 15, 2016

OK, in that case, 5100.20 should include RFC 2910 in the Normative References section and add [RFC2910] to the end of that passage I quoted.

Michael Sweet Sep 15, 2016

RFC2910 requires support for HTTP Upgrade if TLS is supported.

Smith Kennedy Sep 15, 2016

In PWG 5100.20, page 16, it says this:

Printers that report support for TLS MUST also support HTTP Upgrade to TLS, correctly advertise themselves using the "_ipps._tcp,_print" sub-type, and support using an "ipps" URI.

This is not a conformance requirement from 5100.14, however. So B-5.1 really ought to be removed or at least be made into a SHOULD rather than a MUST.