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
guidance.
Peter
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>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
<< 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.