Hi Dave,
The common case for IPP-based spoolers (like CUPS) is that the IPP Printer
object supports (by some out-of-band configuration not in RFC 2911) two
or more target print devices. When a user submits a job (Create-Job,
Print-Job, or Print-URI), the IPP Printer object selects an available
target print device and displays the NAME (not the URL, sadly) of the
selected target print device in the read-only Job attribute:
"output-device-assigned".
I have proposed that we add an IPP Printer Description attribute:
"output-device-supported(1setOf text(127))"
Further, the future IPP Device object (strongly based on the Printer
MIB attributes) should have a "device-name" Description attribute
that MUST correspond to one of the published values of
"output-device-supported".
So, an IPP abstract Printer object actually ALWAYS represents a
'printer pool'. But sometimes it's a pool of one.
For PSI, we need to disambiguate the mapping from PSI Print Service
to IPP Printer object. I naively have always thought it was a
one-to-one mapping. If so, a PSI Print Service has the same
property that it always represents a 'pool', the value of an
attribute of REGISTERED (and not merely KNOWN by discovery)
available target devices.
Comments?
Cheers,
- Ira McDonald
High North Inc
-----Original Message-----
From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall@hp.com]
Sent: Wednesday, April 23, 2003 11:23 AM
To: 'ps@pwg.org'
Subject: PS> IPP and Printer Pooling
Hey All...
Some clarification discussion came up in the last meeting around the
CreateJob method, and what should happen if the client does not specify a
targetDeviceIdentifier, and the deliverToTargetDevice parameter.
So far, I have only been thinking about delayed association of a Target
Device, and not about the Print Service picking a Target Device based upon
the requirements of the Job.
Can someone describe the Use Cases around Printer Pooling? What are the
requirements?
Thanks!
Dave
This archive was generated by hypermail 2b29 : Wed Apr 23 2003 - 14:26:23 EDT