IPP> DIR - Comments from an X.500/LDAP specialist

IPP> DIR - Comments from an X.500/LDAP specialist

Carl-Uno Manros cmanros at cp10.es.xerox.com
Thu May 22 18:48:41 EDT 1997


IPPers,


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
Schema.  
I think you will find a number of useful and constructive comments in his
text.


Thanks Frode.


Regards,


Carl-Uno



---


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
comments.


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://
etc. 
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.


3. Enumerations.


I have mixed emotions towards using string-enumerations like "two-sided" or
"four colors". 
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.


Specific attributes:


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
LabeledURL)


Location: Most of the suggested information already exists as possible
attributes in PilotPerson (room, floor, locality...) I would suggest
individual attributes.


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
Portrait/Landscape ?


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.


Good luck!


Frode
- - - - - - - - - - - - -
Frode Hernes
MaXware


   12614 Builders Road
   Herndon, VA 20170
   Tel:(703) 435 2587
   Mobile:(703) 919 5166
   Fax:1 (800) 355 2071
   X.400:g=Frode;s=Hernes;o=MaXware;a=Telemax;c=No
   Mailto:frode.hernes at maxware.telemax.no


MaXware A.S:
   mailto:maxware at maxware.no
   http://www.maxware.no



---


Carl-Uno Manros
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




More information about the Ipp mailing list