Hi folks, Wednesday (16 July 2003)
Proposal for a simple Device extension to the PWG Semantic Model:
(1) Add a "PrinterRole" element to the Printer object, with legal values
'logical' (PSI Print Service, IPP Printer, etc.), 'physical' (PSI
Target Device, SNMP Device, etc.), or 'logical-and-physical' (for
consistency with ISO 10175 DPA's "printer-realization" attribute
and a number of shipping vendor implementations of DPA).
(2) Any 'logical' Printer object MAY support (e.g., via PSI's
GetTargetDeviceElements) returning its 'best effort knowledge'
of the elements of local surrogate 'physical' Printers (Devices).
The URI of each local surrogate 'physical' Printer is formed by
concatenating:
(a) Any URI value of the "PrinterUriSupported" element (e.g., a
'pwg-psips:' value), and
(b) a single dot '.', and
(c) any value of the "OuputDeviceSupported" element.
(3) A 'physical' Printer supports all standard Printer elements and MAY
also support the "PrtXXX" elements extracted from the IESG-approved
final draft of Printer MIB v2 (for the WBMM effort).
Comments?
Cheers,
- Ira McDonald
High North Inc
PS - Mapping this PWG Semantic Model extension back to IPP is trivial.
The latest IPP Job Extensions spec defines "output-device" (a client
supplied Job Creation operation attribute) and "output-device-supported"
(a Printer attribute that bounds the values of "output-device" and the
existing "output-device-assigned", a Job Description attribute).
An 'ipp:' value of "printer-uri-supported" on an IPP 'logical' Printer
MAY be suffixed with a dot and a value of "output-device-supported" to
form the URI of an IPP 'physical' Printer with "prt-xxx" attributes.
Existing Get-Printer-Attributes and Set-Printer-Attributes operations
MAY be used to manage and configure an IPP 'physical' Printer. No new
IPP operations are required to add Device support to IPP.