Ira,
On Feb 28, 2014, at 11:19 AM, Ira McDonald <blueroofmusic at gmail.com> wrote:
> ...
> (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.
I think we could get away with a short mention of CUPS with an informative reference to the CUPS web site (https://www.cups.org/); include it in the security considerations - since IPP and IPPS use the same port, the IPP Server/Printer needs to determine whether the initial request data is a TLS ClientHello or a HTTP request, strategies for doing so, and a pointer to an existing implementation (CUPS).
(FWIW, all CUPS does is check whether the initial bytes look like a DELETE, GET, HEAD, OPTIONS, POST, PUT, or TRACE request. If not, we let the TLS library validate the ClientHello)
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140228/5013f301/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4881 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140228/5013f301/attachment.p7s>