IPP Team,
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
at ftp://ftp.pwg.org/pub/pwg/ipp/
contributions-for-discussion/ipp-directory....pdf or .doc (the files
dated 12/20) for the current Directory Schema definition.
Enjoy,
Keith
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
don’t 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
today’s objective values that equate to “high” are tomorrow’s 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, I’m 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
directory entry.
4. Is information that is as variable as media-ready stored in the Name
Service?
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 don’t 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
implementation.
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
the directory.
Proposal: TBD.
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
service.
---------------------------- End of Directory Issues
---------------------------