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