1) Is it really necessary to keep the "Validate-Job" operation as a MUS=
T to
implement? The "Get-Printer-Attributes" operation seems to provide all =
the
functionality that is needed.
HRL> Validate job is intended to pertain to more than just printer attr=
ibutes.
It should also cover print job attributes (like n-up, for example). Isn=
't
Validate-Job akin to checking the "job ticket" whereas Get-Printer-Attr=
ibutes
is akin to determining the device configuration?
2) Can you implement the operations "Create-Job", "Send-Document" and
"Send-URI", without the need to support multiple documents? This could =
be
useful for environments where you have long jobs, but do not need suppo=
rt
for multiple documents.
HRL> The model document supports the notion of a Create-Job operation f=
ollowed
by only one Send-Document operation as semantically equivalent to a Pri=
nt-Job
operation. It cautions regarding performance, however. If you are askin=
g is it
ok to support Creat-Job, Send-Doc with only one document - Yes. If you =
are
asking is it ok to support Create-Job but LIMIT Send-Dco to only one
document... I'd say that would be a non-no!
3) What was the rationale for making the "printer-up-time" attribute a
REQUIRED attribute, considering that the other 3 attributes
"time-at-creation", "time-at-processing", and "time-at-completed", with=
which it is associated, are all OPTIONAL?
HRL> Don't know for sure but I suspect this attempts to make a running =
"time
marker" available for monitoring, tracking accounting etc... without ma=
ndating
all the possible time recording points on each IPP device. This si some=
what
analogous to the sysUpTime concept in MIB-II.
Harry Lewis - IBM Printing Systems
=