And I tried to explain the problem with this before...
> The MUST requirement would be for the functionality to be in your
> IPP product.
>
> Your customer is however free to configure the IPP Printer to never
> issue any Basic or Digest challenges. Please note that this is also
> impacted by the solution we will come up with for Issue 2 on our
> list, but I don't think that the client should ever by allowed to
> DICTATE the server behavior in this respect.
> ...
The main problem with this is that a MUST requirement means that you
have to implement it in your product. Sure, a customer can configure
things differently, but that's not the point.
1. Most HTTP servers don't handle Digest according to the
current HTTP/1.1 draft. Specifically, they don't authenticate
the message body.
2. Supporting Digest requires a lot of account administration
tools (command-line, web, and/or GUI), which can take a
significant amount of time to design and develop.
Now, if either of these items apply to my product (they do), and I
want to ship an IPP/1.1 compliant product, then I have to implement
the needed pieces, right? I've done a rough estimate of the time
required for us to add Digest support to our product, and from design
to testing it'll be at least 4 person-months worth of effort.
So be it - we'll release our product as IPP/1.0 compliant, and have
an upgrade to IPP/1.1 when we finish Digest support...
That leads to the other question - if I give my customer the option
of using Basic authentication, and IPP/1.1 mandates Digest but not
Basic, then what guarantees do I have that IPP client X will be able
to talk to my server?
-- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com