John,
IPP doesn't use STARTTLS - that's a SMTP thing. "ipp:" and "ipps:" URIs map to "http:" and "https:" URIs, per RFCs 3510 ("ipp" URI scheme), 7472 ("ipps" URI scheme), and 8010 (IPP/1.1: Encoding and Transport),
Connections for "ipp:" URIs start out unencrypted. If the Client wants to force TLS encryption, it can send an OPTIONS request with an "Upgrade: TLS" header. If a Printer (server) wants to force TLS encryption, it can respond with status 426 (Upgrade Required) with an "Upgrade: TLS" header. The TLS negotiation follows, much like STARTTLS for SMTP. See RFC 2817 for more details.
Connections for "ipps:" URIs start with a TLS negotiation, just like "https:" URIs. This was originally documented in RFC 2818 and is now part of RFC 9110.
> On Jul 2, 2025, at 7:49 PM, John Madden <jpmsparks at yahoo.com> wrote:
>> Michael,
>> Smith Kennedy asked me to check with you as you are the subject matter expert on IPPS connection on port 631 and how they are established. Based
>> on his feedback and tests I ran at work, I have altered an explanation I had in the book. When checked in WireShark, my former paragraph
>> I had assuming STARTTLS on ipps on port 631 proved - as Smith Kennedy said - to be incorrect. I have included a Word doc with my new observations and
>> I was hoping you could check this over for clarity. The ClientHello, ServerHello, ClientKeyExchange, and final printer messages can clearly be seen on the
>> traces of a printer installed in windows with a URL of ipps://<printer name>/ipp/print.
>>> Thanks
> <Information on IPPS connection establishment.docx><TLS_Can_Begin.png>
________________________
Michael Sweet