IPP> Re:Goals behind IPP 1.1 printer mgmt

IPP> Re:Goals behind IPP 1.1 printer mgmt

IPP> Re:Goals behind IPP 1.1 printer mgmt

PETER_E_MELLQUIST at hp-roseville-om3.om.hp.com PETER_E_MELLQUIST at hp-roseville-om3.om.hp.com
Thu Jun 24 15:30:03 EDT 1999

Thanks for the reference to the "design goals" behind the effort. This helps to 
clarify to what degree printer mgmt should be included. If the intent is to 
include a full mgmt protocol within IPP, then perhaps it might be good to point 
this out since it remains somewhat ambiguous. If the intent is to provide a 
distinct subset then, what is the criteria for selecting that sub-set? 
Certainly job related mgmt is desired, but as for printer management its not 
clear what the intent is.

Assuming the intent is for IPP to be an IETF blessed protocol....Protocols 
developed within the IETF address mgmt in the form of SNMP MIBS. If the use 
cases behind the protocol require mgmt within the protocol which cannot be 
addressed by SNMP then so be it. If the intent is develop a brand new mgmt 
infrastructure just for some type of device, then historically the IETF has 
frowned on this. Instead the philosophy has been to encourage a single mgmt 
framework enabling interoperable mgmt applications. Having every protocol do 
there own thing would clearly not be in the interest of the IETF. I would not 
like to see the IESG/IETF hold up IPP due to this type of issue. 

In the interest of moving IPP ahead now, this does not seem to be a major issue 
at this point. The number of mgmt attributes seem minimal. It would be 
interesting to consult with the area director to get his perspective and 


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).



   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
   - 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

 << File: RE_ RE_ IPP_ MOD - comments on Carl's Set and Admin operations 
registration pr.TXT >> 


Item Subject: WINMAIL.DAT
Couldn't convert Microsoft Mail Message Data item to text at a gateway.

More information about the Ipp mailing list