Then of what use is an IETF-endorsed IPP standard?
Over the years I've worked with a LOT of devices, products, and
software packages that "conform" to standard XYZ, but in reality
don't conform exactly to the spec. Many vendors will fix problems
in their implementations, but when the problem can't be fixed short
of re-engineering the entire product it usually doesn't happen.
If you impose mandatory requirements that 1) can't be met by most
vendors, or 2) are cost-prohibitive to implement, then vendors will
be forced to release non-compliant IPP products (or not release IPP
support at all!) What good is IPP then?
I think the current authentication proposal is good for clients. For
servers I think we need to be more lenient in the authentication
requirements, at least for IPP/1.1. The new Digest message body
authentication in the latest drafts for HTTP/1.1 will be a fairly
easy and cost-effective authentication solution for many vendors, but
since it *IS* new we have to give all vendors involved a chance to
update their HTTP server implementations to support it.
This may be a moot point given that IPP/1.0 is still sitting in the
RFC editor's in-box, so even if the IPP/1.1 drafts go out for
approval next month they probably won't see the light of day for
another year at least (by which time the HTTP servers should be
caught up.)
-- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com