IPP Mail Archive: IPP> OPS - Minor issues for the Set Job an

IPP> OPS - Minor issues for the Set Job and Printer operations spec

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Wed Feb 23 2000 - 11:51:43 EST

  • Next message: Michael Sweet: "Re: IPP> OPS - Minor issues for the Set Job and Printer operations spec"

    For the IPP telecon today and email discussion:

    Here are minor Set-Job-Attributes issues raised by the agreements to change
    the 'default' out-of-band value to 'delete-attribute' out-of-band value:

    ISSUE 01 - Ok for the Printer to ignore the 'delete-attribute' out-of-band
    value, if the supplied attribute is not present on the Job object, rather
    than returning it in the Unsupported Attributes Group and returning some
    kind of status to indicate this?

    ISSUE 02 - Should we change the 'any-name out-of-band value to a general
    'any' out-of-band value that can be used with any attribute syntax type in
    principle, rather than inventing a new 'any-xxx' out-of-band value for each
    attribute syntax that we need to provide the 'any' mechanism?
    Alternatively, we could add a new attribute syntax whose value can be any
    attribute syntax? With either approach, each attribute definition would be
    required to indicate explicitly that it is defined to be able to use the
    'any' (attribute syntax or out-of-band value). With each approach, how
    would the new 'collection' attribute syntax use it, since the 'collection'
    attribute syntax has a "begin" and "end" encoding? So far we have seen a
    need for 'any-name' and 'any-mime-media-type' (Carl Kugler), but there could
    be more.

    ISSUE 03 - Any other comments on the updated Set-Job-Attributes operation
    update below (included here to give the context for ISSUE 01):

    4.2 Set-Job-Attributes Operation
    This OPTIONAL operation allows a client to set the values of the attributes
    of a Job object. In the request, the client supplies the set of Job
    attribute name keywords and values that are to be set. In the response, the
    IPP object returns success or rejects the entire request with indications of
    which attribute or attributes could not be set.
    This operation is almost identical to the Set-Printer-Attributes operation
    (see section 4.1). The only differences are that the Set-Job-Attributes
    operation is directed at a Job object rather than a Printer object, there is
    no "document-format" operation attribute used when setting a Job object, the
    operation can add an attribute to the (Job) object, the 'delete-attributes'
    out-of-band value is permitted to remove an attribute, and the validation is
    the same as the Job Creation operations (Print-Job, Print-URI, and
    Create-Job), i.e., depends on the "xxx-supported" Printer Description
    attributes (see [ipp-mod] section 3.1).
    If a client supplies a job attribute in a Set-Job-Attributes request that
    the Printer supports, and the job was originally submitted without supplying
    that attribute, the Printer adds the attribute to the Job object.
    If the client supplies a job attribute with the "out-of-band" value
    'delete-attribute' (see section 8.2), then the Printer MUST remove the
    attribute and all of its values from the Job object, if present. The
    semantic effect of the client supplying the 'delete-attribute' value in a
    Set-Job-Attributes operation MUST be the same as if the attribute had not
    been supplied with the Job object in the Job Creation operation, i.e., the
    Printer applies its default attribute or behavior with lower precedence that
    the PDL (see the beginning of [ipp-mod] section 4.2 and [ipp-mod] 3.2.1.1).
    Any subsequent query of the Job object using Get-Job-Attributes or Get-Jobs
    MUST NOT return any attribute that has been deleted using the
    'delete-attribute' out-of-band value. However, a client can re-establish
    such a deleted Job attribute with any supported value(s) using a subsequent
    Set-Job-Attributes operation.
    If the client supplies an attribute in a Set-Job-Attributes request with the
    'delete-attribute' value and that attribute is not present on the Job
    object, the Printer ignores that supplied attribute in the request, does not
    return the attribute in the Unsupported Attributes group, and returns the
    'successful-ok' status code, if there are no other problems with the
    request..
    ISSUE 01 - Ok for the Printer to ignore the 'delete-attribute' out-of-band
    value, if the supplied attribute is not present on the Job object, rather
    than returning it in the Unsupported Attributes Group and returning some
    kind of status to indicate this?
    The validation of the Set-Job-Attributes request is performed by the Printer
    as if the job had been submitted originally with the new attribute values
    (and the deleted attributes removed) and with "ipp-attribute-fidelity" set
    to 'true', i.e., all modified attributes Job attributes and values MUST be
    supported in combination with the Job attributes not modified. If such a
    Job Creation operation would have been accepted, then the Set-Job-Attributes
    MUST be accepted. If such a Job Creation operation would have been
    rejected, then the Set-Job-Attributes MUST be rejected and the Job MUST be
    unchanged. In addition, if any of the supplied attributes are not
    supported, are not settable, or the values are not supported, the Printer
    object MUST reject the entire operation; the Printer object MUST NOT
    partially set some of the supplied attributes. In other words, after the
    operation, all the supplied attributes MUST be set or none of them MUST be
    set, thus making the Set-Job-Attributes an atomic operation.



    This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 11:57:32 EST