As a member of the security subgroup, here's a first cut at a revision of the "Security Considerations" section of the Protocol document.
/John
-------------------
Security Considerations
When utilizing HTTP 1.1 as a transport of IPP, the security considerations outlined in RFC 2068 apply. Specifically, IPP servers can generate a 401 "Unauthorized" response code to request client authentication and IPP clients should correctly respond with the proper "Authorization" header. Both Basic Authentication (RFC 2068) and Digest Authentication (RFC 2069) flavors of authentication should be supported. The server chooses which type(s) of authentication to accept. Digest Authentication is a more secure method, and is always preferred to Basic Authentication.
For secure communication (privacy in particular), IPP should be run using a secure communications channel. Both Transport Layer Security - TLS (draft-ietf-tls-protocol-03) and IPSec (RFC 1825) provide necessary features for security. It is possible to combine the two techniques, HTTP 1.1 client authentication (either basic or digest) with secure communications channel (either TLS or IPSec). Together the two are more secure than client authentication and they perform user authentication.
Complete discussion of IPP security considerations can be found in the IPP
Security document