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 at hp.com]
Sent: Wednesday, April 23, 2003 11:23 AM
To: 'ps at 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