UPDF Meeting Minutes
Anchorage, Alaska
August 20, 1999

Need to continue to break apart the PDL and job description commands. Nice goal is to get drivers to use IPP. Don't embellish IPP further so that the overlap between IPP and UPDF will become obsolete.

Extract out non-proprietary job descriptions and put in IPP. Examples include Copies, Orientation, Duplex. Proprietary things go into the PDL. Continues the goal of separating PDL from job commands.

Level of functionality for UPDF and bi-di. Could also be thought of as a technology roadmap for some devices.

1. Basic: identify printer device only. One query command. Driver is configured based on the printer device. Driver most likely has alot of detail knowledge of the device. Technically not a universal driver, but more of a monolithic driver.
2. Better: In addition to basic functionality, also be able to query device at install time or print time. Current drivers have this ability today but it is generally embedded in the PDL and not a general purpose solution. Driver has to understand the printer device before it can print to it. Even though one driver can support many printers, usually each printer vendor will ship a family driver that is monolithic.
3. Best: Complete separation of job and marking commands. A change in the printer configuration or addition of a paper handling device will automatically show up in the driver as a new capability without end user intervention. Driver doesn't have specific knowledge of device but can call plugins that do if needed to display vendor specific UI or execute vendor specific imaging code. Hopefully driver is universal and does not have to have detailed knowledge of the printer to print to it. Plugins understand the device they are printing to and contain the code to generate marking commands or contain the PDL already. May be proprietary or may be a well known language such as PostScript.

  What about IPP notification? Paper size versus out of paper message. The former fits into UPDF the latter does not necessarily. There should be an IPP notification to see if the UPDF file has changed. Use a date-time stamp in file.

Current file size is 25K. Do we or can we break apart the file into separate files. We should wait to see how big it is when the spec is more complete. Must have include file capability - may need to add to the DTD. Notifications should be thought about first. If 600 clients are connected to a printer, then there may be 600 notifications sent out for a change in the configuration. Not good. Don't make notification support a requirement. Make it optional if a printer vendor wants to implement, it's up to them.

What is the order of precedence for UPDF retrieval? Go to printer first then web page. Or go to web page first then printer. How do we handle incremental updates of a printer's UPDF file. One possibility is to get the OS UPDF from the CD and then get deltas from printer.

Configuration changes is what the printer is looking for. Input / Output devices. Finishers. Delta doc may be larger than UPDF file. Be able to download sections of the UPDF or Deltas from the UPDF. NOT a requirement 1.0.

We do need a file version tag. We have one already in DeviceCap.Header. <FileVersion> in line 16. We should break out and make a separate tag. Proposal to change the tag name to be <ConfigurationChangeID>. Type is an atomically increasing integer. If the number changes then a new UPDF file has to be retrieved. How the number is changed or the meaning of the number is Implementation specific. Should ConfigurationChangeID =  0 mean a reset condition? "Power on" can always force an increment on low end devices with limited memory. High end printers may choose to save off and not have an increment.

Summary:

1. Current view is to add a "GetUPDFFile" to IPP. Also add a date-time stamp attribute. Add event to subscription for notification.
2. Do not embed IPP in UPDF. We want it to remain protocol independent.
3. Accept there is some overlap between IPP and UPDF in the device characteristics specification.

Proposed Schedule (Goal)

Requirement Doc for Bi-di: ??

Model doc: ??

Mapping Document and DTD: Los Angeles meeting Dec. 13-17

Implementor's Guide: New Orleans meeting Feb. 7, 2000

User Interface 

XML Links

Links and info

Mailing Lists

General Discussion: upd@pwg.org

To Subscribe:

• Send mail to majordomo@pwg.org with the following in the body of the message:
  subscribe upd