IPP Mail Archive: RE: IPP> OPS - Redirect-Job (a ka Move-Jo

IPP Mail Archive: RE: IPP> OPS - Redirect-Job (a ka Move-Jo

RE: IPP> OPS - Redirect-Job (a ka Move-Job) included in Job and Printer A dmin (Set2) spec

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Sat Jul 08 2000 - 13:40:30 EDT

  • Next message: Hastings, Tom N: "IPP> FW: UPD> UPDF and IPP Collaboration - Resource object for fonts"

    Hi Tom,

    Very nice clean formulation of Redirect-Job. I like it
    without any changes at all.

    Cheers,
    - Ira McDonald, consulting architect at Xerox and Sharp
      High North Inc

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Friday, July 07, 2000 4:51 AM
    To: ipp
    Subject: IPP> OPS - Redirect-Job (a ka Move-Job) included in Job and
    Printer A dmin (Set2) spec

    I added Move-Job (renamed to Redirect-Job since no job movement is required)
    to the Job and Printer Administrative Operations spec that I just posted.
    It is based on the requirements that we discussed by email last May. Please
    send any comments to the DL, since we will discuss this at next week's IPP
    WG meeting.
    12.5 Redirect-Job operation
    This OPTIONAL operation allows a client to redirect a not-completed job to
    another Printer on the same server. Redirect-Job is defined to be a Job
    Creation operation, along with the Print-Job, Print-URI, and Create-Job
    operations. Thus all semantics that apply to Job Creation operations also
    apply to this operation. For example, the new Printer validates the job
    using all of its "xxx-supported" attributes and either accepts or rejects
    the job. If the job is rejected, it remains in its original state before
    the Redirect-Job operation was attempted. As an other example, the Job
    inherits the defaults for the new Printer (since the defaults aren't copied
    onto the Job object when it is created, but are applied when the job is
    processed - see [ipp-mod]). Finally, this operation generates a
    'job-created' event as does any Job Creation Operation.
    In order to preserver the "ipp-attribute-fidelity" semantics that the
    original client supplied when the job was first created, each Job Creation
    Operation copies the "ipp-attributes-fidelity" (boolean) operation attribute
    o the job as a Job Description attribute, if the Redirect-Job operation is
    supported. Then the "ipp-attribute-fidelity" attribute is re-used by the
    new Printer during its job validation, unless the client performing the
    Redirect-Job operation supplies the "ipp-attribute-fidelity" operation
    attribute.
    This operation is limited to redirecting a job to another Printer on the
    same server. Thus the same copy of the job MAY be used, depending on
    implementation. Also, depending on implementation, the new Printer MAY
    generate a new job-id and job-uri, or use the same one. In either case the
    response contains the "job-id" and "job-uri" for the redirected job as for
    any Job Creation operation. If the new Printer does assign a new "job-id"
    and "job-uri", then it MUST automatically update an Per-Job Subscription
    objects that are associated with the job.
    The Printer MUST accept this operation whenever the job is in the 'pending'
    or 'pending-held' states. The Printer MUST reject this operation whenever
    the job is in the 'completed', 'aborted', or 'canceled' states and return
    the 'client-error-not-possible' status code. Whether the Printer accepts
    this operation when the job is in the 'processing' or 'processing-stopped'
    states depends on implementation.
    Access Rights: The authenticated user (see [ipp-mod] section 8.3) performing
    this operation must either be the job owner (as determined in the Job
    Creation operation) or an operator or administrator of the Printer object
    (see [ipp-mod] Sections 1 and 8.5).
    The Redirect-Job Request have the same attribute groups and attributes as
    the Create-Job operation (see [ipp-mod] section 3.2.4), plus the new
    "job-message-from-operator" operation attribute (see section 5). In
    addition, the following operation attributes are defined:
            Target:
                    Either (1) the "printer-uri" (uri) plus "job-id"
    (integer(1:MAX)) or (2) the "job-uri" (uri) operation attribute(s) which
    define the target for this operation as described in [ipp-mod] section
    3.1.5. The client MUST supply this attribute and the Printer MUST support
    it.

            new-printer-uri (uri):
                    The URI of another Printer on the same server. The client
    MUST supply this attribute and the Printer MUST support it.

            ipp-attribute-fidelity (boolean):
                    The client MAY supply this attribute, but the Printer MUST
    support it. It indicates whether or not the Job Template attributes on the
    Job object MUST be supported by the new Printer. If the client omits this
    attribute, the new Printer uses the value copied to the job as a Job
    Description attribute when the job was originally created. The Job
    Description attribute is not affected by the value supplied in this request,
    so that the original user's intent is preserved across multiple Redirect-Job
    operations.
    The Redirect-Job Response has the same attribute groups, attributes, and
    status codes as the Create-Job operation (see [ipp-mod] section 3.2.4). The
    following status codes have particular meaning for this operation:
            'client-error-not-possible' - the job was in the 'completed',
    'aborted', or 'canceled' states or the implementation does not support the
    Redirect-Job operation on a job when it is in the 'processing' or
    'processing-stopped' states.
            'client-error-not-found' - the target job was not found.
            'client-error-attributes-or-values-not-supported' - the specified
    Printer is not supported for redirection, i.e., the URI was not amongst the
    Printer's "redirection-printers-supported" (1setOf uri).

    Send any comments to the DL. We will review this at next week's IPP WG
    meeting.

    Tom



    This archive was generated by hypermail 2b29 : Sat Jul 08 2000 - 13:51:57 EDT