I am forwarding the following message from Frode Hernes, an old friend and
almost fellow countryman, who has looked at our current I-D for Directory
I think you will find a number of useful and constructive comments in his
I have just browsed through the IPP Directory draft, and as an author of
one general DAP browser (http://www.maxware.com/downloads/demo) I have some
First, the URL:
Using Windows, I trust that applications register the URIs they can handle,
Netscap register ftp:// and http://, our Directory Browser register LDAP://
I would like my Internet Printing application to register IPP:// so that
Windows can hand it all print jobs.
Then, the directory part:
1. Some of the attributes are 'structured' e.g the Location attribute
specifies a sub-syntax for various pieces of information within a string
attribute. This has several problems:
- It looks ugly in a general browser
- It is almost impossible to translate the lead-ins for other languages
(unless the lead-ins are well defined, and in that case, why not use
separate attributes ?)
- It is hard to update and keep track of.
So, I would reccoment separate attributes for separate pieces of information.
2. Single valus / Multi value.
This is not explicitly said (or I did not see it), but I would recommend
that a printer object contains multi-value capability attributes, so that
the color attribute contains all the color schemes the printer support etc.
This makes it fairly easy to search based on capabilities.
I have mixed emotions towards using string-enumerations like "two-sided" or
On one hand, they are easy to read in english, but on the other hand:
- They must be translated for most of the people in the world
- They are easy to mis-spell, making it hard for an application to trust them
If instead, numeric codes are defined, it will look more cryptic to an end
user (the DUA or application will need a table), but they will always be
correctly spelled, and the need for translation is obvious.
Many of the attributes references the attributes to the Job object, but I
cannot find this object defined. Also, if a Job contains actual parameters,
following the same syntax / semantics as an attribute (multi-value) of a
Printer, the same attribute name and OID should be used (but single-valued
on the Job (?))
Name: The name in the directory should be a CommonName
The attribute LabeledURL can be used to hold the printers URL, or a
separate attribute PrinterURL can be defined (with the URL syntax from
Location: Most of the suggested information already exists as possible
attributes in PilotPerson (room, floor, locality...) I would suggest
Color supported: multi-value, enumeration ?
DeviceID: If this can be used for PlugAndPlay IDs why not make an attribute
we can trust to contain a PlugAndPlay ID if it exists ?
Make/model: I would prefer two attributes: Vendor and Model, maybe also
'revision' or 'sub-model' ?
Sides-supported: again, split in 1 / 2 and a new attribute
And yes, you need to define a STRUCTURAL object Class printer with a new
OID. It should probably be a subclass of device.
Then BNF for the attributes, and assigned OIDs are more important than the
API used to initialize the object.
As for security, the IETF-ASID group is just now specifying to how to use
TLS with LDAP (a one port solution), this may be suited for IPP.
- - - - - - - - - - - - -
12614 Builders Road
Herndon, VA 20170
Tel:(703) 435 2587
Mobile:(703) 919 5166
Fax:1 (800) 355 2071
Mailto:frode.hernes at maxware.telemax.no
mailto:maxware at maxware.nohttp://www.maxware.no
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros at cp10.es.xerox.com