Michael,
I don't agree that the security solution proposed in our New Orleans meeting
is either:
1) can't be met by most vendors
or:
2) are cost-prohibitive to implement.
As you observe yourself, it might take vendors a bit of time to implement
IPP/1.1, but in the meantime it looks like most people are rolling out
IPP/1.0 versions. That doesn't mean that we shouldn't finish up the IPP/1.1
version NOW, otherwise it will just take even longer for the IESG favored
IPP solution to reach the market. I want to reemphazise that the IPP WG was
set up with task of creating in IETF standard. We haven't delivered on that
yet, but I hope that we will soon. A couple of people are just now trying to
write up the details about the New Orleans solution (see the minutes just
distributed) and I would welcome your input on that text as soon as we have
it ready.
Carl-Uno
> -----Original Message-----
> From: owner-ipp at pwg.org [mailto:owner-ipp at pwg.org]On Behalf Of Michael
> Sweet
> Sent: Friday, April 23, 1999 5:34 AM
> To: Manros, Carl-Uno B
> Cc: Paul Moore; 'Keith Moore'; IETF-IPP
> Subject: Re: IPP> Re: PRO - Issue 32: Use of Basic & Digest
> Authentication
>>> "Manros, Carl-Uno B" wrote:
> > ...
> > So why does every little $200-300 IPP LAN print server box have to
> > be fully compatible with the "full" IPP standard, as long as you
> > declare that it not?
> > ...
>> 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 at easysw.com> Printing Software for UNIX http://www.easysw.com>