This note contains a compilation of issues for the Directory Subgroup
based on email and previous interactions. I have included a proposed
solution whenever possible based on email and my experience. Please
consider each proposal in the context of IMHO. Reference the document
contributions-for-discussion/ipp-directory....pdf or .doc (the files
dated 12/20) for the current Directory Schema definition.
P.S. I'm sending this email from home thus my funky email address.
--------------------- Directory Subgroup: Issues
1. Should LDAP be included in the Directory Schema?
Proposal: Remove section 2.3 Directory Entries Using LDAP to decouple
the schema from a specific directory protocol.
2. The use of objective attributes vs. subjective attributes still
needs to be resolved. For example, for Maximum Print Quality is it
better to have values like high, medium, low or to have explicit,
quantified, measurable values? Some considerations are: end-users
dont often know what explicit objective values are or what they really
mean and they want to depend on an administrator to define what is
high quality printing and what is low quality, especially since
todays objective values that equate to high are tomorrows objective
values that equate to medium. On the other hand, some end-users
demand the control and power explicit values can give them when they do
filtered searching. For example, they know and appreciate the
difference between 20ppm and 23 ppm printers.
Proposal: We need to focus on the primary customer of the Directory
Schema who is the end-user selecting printer objects. Based on my
interaction with customers, most end-users want to search for printer
objects using standard values low, medium and high for quality,
cost and speed. I realize there are power end-users who want to make a
selection based on explicit values, but these end-users can always query
for a list of printer objects using the basic 3 values of the directory
attribute of interest and then query each printer object in the list for
its specific value. However, I expect most of the time the power
end-users will know the explicit capabilities of printer objects. So,
we should stick with high, medium and low for these attributes.
Another option is to provide a mechanism to specify explicit values for
these attributes if that is really necessary. I invite Jim Walker of
DAZEL and Scott Isaacson of Novell to share their real world
experience since I understand both DAZEL and Netware 4.x/NDPS also allow
end-users to search for printer objects based on attributes.
3. Is the cost per page tied to the media it is printed on? Do we need
to define some standard for determining the cost per page?
Proposal: Please read the proposal for issue 2 which basically states
not to put this level of granularity in the cost attribute of a printer
object entry in the directory. If this is required for accounting
applications, then an explicit value on cost should be stored in the
printer object. Furthermore, based on the series of email responses on
this issue, Im convinced that it will be complex to define values for
the cost attribute more granular than high, medium and low.
Finally, a URL reference for more information on the cost of a printer
seems like a printer object attribute since this does not allow a user
to select a printer object based solely on the attributes in its
4. Is information that is as variable as media-ready stored in the Name
Proposal: No. This requires an implementation to synch up the physical
attributes of a printer object with its printer object entry in the
directory which I dont believe we should require of an implementation.
If there is a tidal wave of support for media-ready, then we could make
this attribute optional and indicate that an administrator may specify
the values so as not to require implementations to synchronize printer
objects and their entries in the directory. Scott Isaacson and Jim
Walker, what does your experience tell you about putting such attributes
in printer object entries in the directory?
5. How is near my hotel done? Is there a required format for printer
location in the schema?
Proposal: The Directory Schema has an attribute called Location. Per
the current definition in the Directory Schema document, this field is a
free form string that can contain site-specific location information.
This seems sufficient and keeps things straightforward for an
6. The client should be able to ask either the printer or the Name
Service for the location of the driver/driver installer.
Proposal: Put the location of the driver/driver installer in the
printer object - not in the directory. This location could change based
on the printer(s) assigned to a printer object so putting this in the
directory opens the door to synchronization issues in keeping a printer
object entry in the directory current with its printer object.
Furthermore, I do not believe that this attribute is required by an
end-user to select a printer object.
7. Should Device Id be in the Directory Schema? If so, is this the
IEEE 1284 device id, the Object Identifier as used in the Host Resource
MIB hrDeviceId object, or some other identifier?
Proposal: Remove Device Id from the Directory Schema. Make and Model
should be sufficient in terms of locating printer object entry(ies) that
use a specific device. Once an end-user selects a printer object, an
IPP application can query the printer object to get its device id so the
application can select the printer driver for the printer object.
8. We must specify which attributes are mandatory and which are
optional. LDAP uses the terms must and may to identify attributes
that must appear and attributes that may appear in a given entry in
9. What should be stated about security?
Proposal: Replace section 3. Security Considerations with a statement
like the following:
This document does not identify specific security mechanisms used by a
directory service to control access to printer object entries in the
directory. Security is left to the implementation of the directory
---------------------------- End of Directory Issues