IPP Mail Archive: RE: RE: IPP> MOD - comments on Carl's Set and Admin operations re

RE: RE: IPP> MOD - comments on Carl's Set and Admin operations re

Manros, Carl-Uno B (cmanros@cp10.es.xerox.com)
Thu, 24 Jun 1999 12:26:05 -0700

All,

I have observed some of the comments on whether administrative functions
should be part of IPP or not.

Here is my take on it:

1) We have already introduced a couple of optional operations for admin
functions in version IPP/1.1.

2) We have indicated in our Goals document that we want to do admin
functions later. Considering that the WG now considers IPP/1.1 done, we are
starting to gradually enter the "do later" stage, although some of that does
go beyond the current charter in the IETF IPP WG.

3) I don't think anybody has suggested that any additional admin functions
would be mandatory to implement.

4) A lot of the work on IPP/1.0 and 1.1 has been centered around the
features needed at the lower end of the printer spectrum (smallest common
denominator, solving 80% of the problem etc.). I think it is fair to now
also start considering the needs for optional functionality needed for the
middle to high end printers, and print servers.

5) We need to discuss with the IETF Application Area Directors, to what
extent they would like to see a new IPP WG charter for an extended set of
functions for IPP, or if they would prefer to leave further extensions to
groups like the PWG, using the pre-defined extension mechanisms already
defined for IPP/1.0 and 1.1. I will make sure to bring this subject up with
them during the upcoming IETF meeting in Oslo.

6) What still remains to be done by the current IPP WG is to work out the
solutions for IPP Notifications, something that is explicitly in the current
charter.

Carl-Uno

> -----Original Message-----
> From: kjo@ess.mc.xerox.com [mailto:kjo@ess.mc.xerox.com]
> Sent: Thursday, June 24, 1999 11:33 AM
> To: hastings@cp10.es.xerox.com; HPARRA@novell.com; ipp@pwg.org;
> kugler@us.ibm.com; PETER_E_MELLQUIST@hp-roseville-om3.om.hp.com
> Subject: RE: RE: IPP> MOD - comments on Carl's Set and Admin
> operations
> registration pr
>
>
>
> > From ipp-owner@pwg.org Thu Jun 24 12:56 EDT 1999
> > From: PETER_E_MELLQUIST@hp-roseville-om3.om.hp.com
> > X-Openmail-Hops: 1
> > Date: Wed, 23 Jun 1999 19:19:23 -0700
> > Subject: RE: RE: IPP> MOD - comments on Carl's Set and
> Admin operations registration pr
> > Mime-Version: 1.0
> > To: hastings@cp10.es.xerox.com, HPARRA@novell.com, ipp@pwg.org,
> > kugler@us.ibm.com
> >
> > IPP is not a management / Administrative Protocol. If you
> want management,
> > then use a management protocol. Just because you can do
> something within
> > IPP does not mean you should.
> >
> > "Before we drop this issue, I'm with Tom in that from time to time
> > administrators find it very useful to be able to rename a printer."
> >
> > Peter Mellquist
> > Hewlett-Packard Company
> >
>
> RFC 2567, "Design Goals for IPP," states that version 1.0 does not
> address printer management; the role of the Administrator.
> However, it
> does not say that printer management is deprecated for all time. As a
> matter of fact, someone reading RFC 2567 is defintely left with the
> sense that printer management is in the domain of IPP, but was set
> aside in order to get the first versin done (which is sensible).
>
> So while there may be arguments on the merits of including printer
> management in IPP, saying that it violates the initial premises of
> what the protocol is, is incorrect. Either that or the PWG allowed
> an inaccurate RFC to be published.
>
>
> specifically, RFC 2567 says:
>
> Section 4 Objective of the Protocol
>
> The protocol to be defined by an Internet printing working
> group will
> address the wants and needs of the end-user (V1.0). It
> will not, at
> least initially, address the operator or administrator wants and
> needs (V2.0).
>
> Section 3.3. ADMINISTRATOR (NOT REQUIRED FOR V1.0)
>
> ...
>
> The wants and needs of the administrator include all those of the
> end-user and, in some environments, some or all of those of the
> operator. Minimally, the administrator must also have the tools,
> programs, utilities and supporting protocols available to
> be able to:
>
> - create an instance of a printer
> - create, edit and maintain the list of authorized end-users
> - create, edit and maintain the list of authorized operators
> - create, edit and maintain the list of authorized
> administrators
> - create, customize, change or otherwise alter the manner in
> which the status capabilities and other information
> about printers
> and jobs are presented
> - create, customize, or change other printer or job features
> - administrate billing or other charge-back mechanisms
> - create sets of defaults
> - create sets of capabilities
>