IPP Model and Semantics Telecon
1/21/97
2:00 - 4:00 MST
Participants:
Randy Turner
Bob Herriot
Scott Isaacson
Jim Walker
Keith Carter
Jeff Copland
Tom Hastings
1. There has been much discussion over whether the model for IPP
should include multiple layers of Printer objects. This feels like the same
discussion that has come up many times in the JMP. In the current Model
there is the notion of a Printer object that represents either a logical or
physical output device (printer). There are no attributes in the Printer
object indicate to someone that queries the printer which indicate how it
is configured. If the Printer object is representing a single device, then all
seems well. If the Printer object is representing a server component
which is in front of a "farm of devices" then the Printer State attribute
seems a little bit more confusing! We talked about and decided on the
following:
- We will introduce a new attribute called "associated-devices". This
will be a multi-valued attribute that can take on the "names" of associated
devices that may or may not speak IPP or associated server components
which may or may not speak IPP. The "names" of these associated
devices/printers/Printers can be from almost any name space. If they
speak IPP then they will be Printer object URLs which could then be used
as the target for IPP operations (such as getting the state of that Printer).
For other names, the values in this attribute are basically just string that
can be used (hopefully) using some other access protocol or service to
query that device directly. We will not get into the rat hole of trying to
define the access protocol for the name along with that name. An
example might be a server providing service behind a Printer object.
However, behind it (from the end user's point of view) are some network
attached printers. Then names in the "associated-devices" could be
enough information to use SNMP Printer MIB queries to get the device
state.
It is expected that this new attribute ("associated-devices") will almost
never be used by the end-user, but is there for the few times that it may
be used and for an operator/manager trying to bridge between IPP and
other managment protocols.
- We will add some new state values that allow for the front end Printer
object to not lie about its real state if it doesn't want to
- We will add a new attribute called "printer-current-capacity" whose
syntax is "integer percentage". If all is well, even if the printer is busy
processing, then it could be set to 100 (100%). If all is not well could be
set to 0 (0%). If there are 5 devices behind the Printer, and 3 are down
and only two are left, then it could be set to 40 (40%). It will be up to the
implementation to determine how to set these. It is only a hint. Probably
most implmenations will either be constantly set to 100 or move between
100 and 0.
2. There are some issues with the new
"same-attribute-for-both-Printer-objects-and-Job-objects-with-defualts"
attribute scheme that we are working:
- job-print-after needs both relative and absolute time (defaults can only
be relative)
- job-retention-time needs both relative and absolute time (defaults can
only be relative)
- page-select is a range, can there be a default??
- text processing (is there an issue here, I got lost in the discussion)
3. What do we do with xxx-used attributes? These are attributes which
get fillled in by any system component that can truthfully and accurately
determin what is in the data stream and pull it out. There can't be
defaults for these, however there can still be maximums or minimums.
Some thought was to change the name from "xxx-used" to
"xxx-required" or "xxx-needed". We still need closure on this.
4. The document will be informally checked-out by placing a file in the
directory called "<doc name>.<initials>" Once the edited file is replaced,
then removed the "initials" file. This way we will all know if the file is
being modified or not.
************************************************************
Scott A. Isaacson
Print Services Consulting Engineer
Novell Inc., 122 E 1700 S, Provo, UT 84606
V: (801) 861-7366, (800) 453-1267 x17366
F: (801) 861-4025, E: scott_isaacson at novell.com
W: http://www.novell.com
************************************************************