Greetings,
I came across a scenario that I think needs characterization in the implementor’s guide. The scenario is this: a Printer has IPPS enabled but conventional IPP disabled, and it receives a “conventional” HTTP connection from a client. How should the printer respond?
I am thinking that, if the Client sends an HTTP/1.1 Expect header, then that is covered in the guide already (wd-ippig20-20140108.pdf section 8.1): the Printer responds with an HTTP 426 Upgrade to upgrade the connection. But if the Client does not use the HTTP/1.1 Expect header, I’m not sure what we should recommend the printer to do.
I’m also not sure whether this is really a legitimate scenario. If there are some operations that should never require TLS or any form of authentication (the two are related but not the same) then perhaps the Client will not be upgraded right away, and then will not be expecting a later upgrade, and may leak information “accidentally”. For instance, if the Client does a Get-Printer-Attributes operation request that includes the HTTP/1.1 Expect header, it may get back a HTTP 100 Continue. If it switches to a different operation, like Validate-Job or Create-Job, I think it should once again include the HTTP/1.1 Expect header. This specific recommendation detail is currently not covered in wd-ippig20-20140108.pdf section 8.
Am I off in the weeds? This seems to me like a legitimate concern. If I was a new Client implementor, I’d want to know at what points in the algorithms we cover in section 4 I should be sending an HTTP/1.1 Expect, what points I should be expecting a redirect before sending potentially sensitive information on the wire, etc.
Thanks for any thoughts and feedback! I’ll update section 8.1 to try to cover this in my next revision (hopefully posted tomorrow).
Smith
/**
Smith Kennedy
Hewlett-Packard Co.
*/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3319 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140124/99fcf7c1/attachment.p7s>