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

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

Hastings, Tom N hastings at cp10.es.xerox.com
Wed Feb 23 11:51:43 EST 2000


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.




More information about the Ipp mailing list