Some interesting fine points regarding "job-priority" and "job-hold-until"
Job Template attributes...
The [ipp-mod] (IPP/1.0 and IPP/1.1) does NOT say that when a client omits an
"xxx" Job Template attribute, that the Printer populates the Job object with
the default value. So if a client queries such a job, it will not get the
"xxx" (or "xxx-default) attribute at all in the response. To see this, see
section 4.2 step 2 two paragraphs:
2. "xxx" is OPTIONALLY supplied by the client in a create request. If "xxx"
is supplied, the client is indicating a desired job processing behavior for
this Job. When "xxx" is not supplied, the client is indicating that the
Printer object apply its default job processing behavior at job processing
time if the document content does not contain an embedded instruction
indicating an xxx-related behavior.
Since an administrator MAY change the default value attribute after a Job
object has been submitted but before it has been processed, the default
value used by the Printer object at job processing time may be different
that the default value in effect at job submission time.
However, the first two Job Template attributes: "job-priority" and
"job-hold-until" are different from the other Job Template attributes, in
that their effect takes place when the job is submitted, not later when the
job is processed.
Both have the following statements about what happens if the client doesn't
supply the attribute:
[job-priority]:
If the client does not supply this attribute and this attribute is supported
by the Printer object, the Printer object MUST use the value of the Printer
object's "job-priority-default" at job submission time (unlike most Job
Template attributes that are used if necessary at job processing time).
[job-hold-until]:
If the client does not supply this attribute and this attribute is supported
by the Printer object, the Printer object MUST use the value of the Printer
object's "job-hold-until-default" at job submission time (unlike most Job
Template attributes that are used if necessary at job processing time).
The attached mail asks what does a client get back from a Get-Job-Attributes
operation for a Job for which these two special Job Template attributes were
omitted by the client, but the Printer had an "xxx-default" value?
For "job-hold-until", the client can query the Job's "job-state-reasons"
attribute and the 'job-hold-until-specified' value SHOULD be present and the
job MUST be in the 'pending-held' state, unless the time period has already
started.
However, for "job-priority" there isn't a way for a client to determine what
the job's priority is by querying the job, since the "job-priority"
attribute isn't present on the job, even though the Printer had a value for
its "job-priority-default" attribute.
It would certainly seem a reasonable extension for an implementation to
populate the Job object with a "job-priority" attribute (or perhaps a
"job-priority-default" attribute would be better to indicate that it came
from the Printer and has lower priority than the PDL) when the job is
submitted using the value from the Printer's "job-priority-default" value
when the client omits the "job-priority" attribute. Then any client
performing a Get-Job-Attributes operation would get the job's priority.
Note that this would be early binding, so that if the administrator changed
the value of the "job-priority-default", then existing jobs would not be
affected, whereas their priority would be affected for an implementation
that doesn't populate the Job object.
Comments?
Tom
Also see comments below preceded by TH>
-----Original Message-----
From: christopher.pott at i-data.com [mailto:christopher.pott at i-data.com]
Sent: Wednesday, June 28, 2000 08:27
To: Michael Sweet
Cc: ipp at pwg.org
Subject: Re: IPP> Question concerning job-hold-until
I think the idea is that if you support a Job Template attribute (such as
job-hold-until) then you will return it when requested by a client. It
doesn't
matter if the attribute wasn't specified at job creation, as the default
(job-hold-until-default) value will be used instead to set the attribute at
job
submission time.
TH> I agree that this is a reasonable extension for "job-hold-until" and
"job-priority" and fulfills the semantics stated in [ipp-mod] that the
Printer "uses the default value at print job submission time, not at job
processing time".
TH> Some may argue that it is a reasonable extension for all Job Template
attributes. As such an extension for all attributes, the Printer MUST
populate the Job with "xxx-default", not "xxx", so that the semantics that
the precedence is lower than the PDL is maintained. ("job-hold-until" and
"job-priority" are unlikely instructions to be embedded in a PDL, but most
of the other Job Template attributes can be embedded in the PDL, so that the
precedence question becomes important).
Michael Sweet <mike at easysw.com>@pwg.org on 28-06-2000 16:17:09
Sent by: owner-ipp at pwg.org
To: IPP Mailing List <ipp at pwg.org>
cc:
Subject: IPP> Question concerning job-hold-until
Hello, all!
I have a quick implementation question concerning the job-hold-until
attribute, which doesn't seem to be addressed in the final model
document for IPP/1.1.
TH> I agree that it isn't completely and clearly addressed.
Without going into too much detail, we have a customer that wants
to know if the job-hold-until attribute should always be returned
by a get-jobs or get-job-attributes request, or if it should only
be returned if the job-hold-until attribute was specified for the
job (at job creation or later with a hold-job request)
TH> Strict reading of the model document would suggest that the Printer does
NOT populate the Job object with "job-hold-until" or
"job-hold-until-default" if the client omits the "job-hold-until" attribute,
but does behave as if the client supplied the "job-hold-until" with value
specified by the Printer's "job-hold-until-default". See above quoted
material from the Model document.
If the latter, what happens when the hold condition expires (e.g.
the job starts printing)? Do we change the value to "no-hold"?
TH> No, just remove the 'job-hold-until-specified' value from the Job's
"job-state-reasons" attribute.
Similarly, if we always should send job-hold-until, do we send a
value of "no-hold" or an "unknown" value tag?
TH> According to the Model you don't return anything if the client didn't
supply anything (unless you are doing the extension suggested above).
Thanks!
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw.com
Printing Software for UNIX http://www.easysw.com