IPP Mail Archive: RE: IPP> Question concerning job-hold-until

RE: IPP> Question concerning job-hold-until

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Tue Jul 18 2000 - 18:19:01 EDT

  • Next message: Hastings, Tom N: "RE: IPP> Question concerning job-hold-until"

    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@i-data.com [mailto:christopher.pott@i-data.com]
    Sent: Wednesday, June 28, 2000 08:27
    To: Michael Sweet
    Cc: ipp@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@easysw.com>@pwg.org on 28-06-2000 16:17:09

    Sent by: owner-ipp@pwg.org

    To: IPP Mailing List <ipp@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@easysw.com
    Printing Software for UNIX                       http://www.easysw.com
    



    This archive was generated by hypermail 2b29 : Tue Jul 18 2000 - 18:27:22 EDT