> >2. I strongly recommend *not* including in IPP a complete set of printer
> >management facilities. I think this should be a totally separate standard
> >(named IPMP or something). The reasons are:
> > 1. The protocols probably want to evolve independently, with
> > separate version numbers. It is likely that IPP will
> > want to evolve more slowly than IPMP, because implementations
> > will have to be spread more widely. Moreover, I think
> > the IPMP stuff is likely to be more complex than the
> > printer client stuff.
> > 2. IPMP has to interrelate to a whole different set of issues,
> > e.g., compatible with the Printer MIB stuff, perhaps with
> > other network- and system-management APIs and protocols.
> > 3. Most important, I think the widespread deployment of these
> > protocols should be handled separately. Keeping IPP simple
> > and getting it done promptly will be essential if it is
> > to succeed.
>> I think that the entire IPP group is in agreement here. We keep talking
> about IPP V2.0 for management facilities, so IPP V1.0 will NOT have
> any management facilities. Do you see any operations in what we have so
> far that make you think that we are including management facilities in
> IPP V1.0?
>Your comment about IPP V2.0 for management is *directly opposed* to what
I recommended above, which is to keep them separate for the reasons given
above. It is likely to require that all print driver clients who use 1.0
will have to upgrade, even if they don't need any management features.
My view is that these should be separate protocols that share some common
terminology (printer, print job, etc.) but are allowed to evolve separately.
I think the current IPP draft is fine with respect to print-client
vs. management issues.
Bob