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@maxware.telemax.no
MaXware A.S: mailto:maxware@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@cp10.es.xerox.com