People should review it and it should be on the agenda for the
meeting.
Here it is in plain text.
Tom
15. APPENDIX E: Processing IPP Attributes
When submitting a print job to an IPP Printer, the IPP model allows a client
to supply operation and Job Template attributes along with the print data.
These Job Template attributes in the create request affect the rendering,
production and finishing of the documents in the job. Similar types of
instructions may also be contained in the document to be printed, that is,
embedded within the print data itself. In addition, the Printer has a set
of attributes that describe what rendering and finishing options which are
supported by that Printer. This model, which allows for flexibility and
power, also introduces the potential that at job submission time, these
client-supplied attributes may conflict with either:
- what the implementation is capable of realizing (i.e., what the Printer
supports), as well as
- the instructions embedded within the print data itself.
The following sections describe how these two types of conflicts are handled
in the IPP model.
15.1 Fidelity
If there is a conflict between what the client requests and what a Printer
supports, the client may request one of two possible conflict handling
mechanisms:
1) either reject the job since the job can not be processed exactly as
specified, or
2) allow the Printer to make any changes necessary to proceed with
processing the Job the best it can.
In the first case the client is indicating to the Printer: "Print the job
exactly as specified with no exceptions, and if that can't be done, don't
even bother printing the job at all." In the second case, the client is
indicating to the Printer: "It is more important to make sure the job is
printed rather than be processed exactly as specified; just make sure the
job is printed even if client supplied attributes need to be changed or
ignored."
The IPP model accounts for this situation by introducing an
"ipp-attribute-fidelity" attribute.
In a create request, "ipp-attribute-fidelity" is a boolean attribute that is
OPTIONALLY supplied by the client. The value 'true' indicates that total
fidelity to client supplied attributes and values is required. The client
is requesting that the Job be printed exactly as specified, and if that is
not possible then the job must be rejected rather than processed
incorrectly. The value 'false' indicates that a reasonable attempt to print
the Job is acceptable. If a Printer does not support some of the client
supplied Job Template attributes or values, the Printer may ignore them or
substitute any supported value for unsupported values. The Printer may
choose to substitute the default value associated with that attribute, or
use some other supported value that is similar to the unsupported requested
value. For example, if a client supplies a "media" value of 'na-letter',
the Printer may choose to substitute 'iso-a4' rather than a default value of
'envelope'. Since this is an OPTIONAL attribute, if the client does not
supply a value, the Printer assumes a value of 'false'.
Each Printer implementation MUST support both types of "fidelty" printing
(that is whether the client supplies a value of 'true' or 'false'). This is
possible across all types of implementations, since there is a broad range
of acceptable actions when substituting or ignoring unsupported attributes
and values. Also, even if the client supplies a value of 'false', a Printer
might still reject the Job for any reason including an unsupported
attributes and/or values. In the other case, where the client requests a
value of 'true', it is expected that the Printer support this type of
printing since the Printer is already indicating functional support
corresponding to all advertised supported attributes and values.
Since a client can always query a Printer to find out exactly what is and is
not supported, "ipp-attribute-fidelity" set to 'false' is useful when:
1) The End-User uses a command line interface to request attributes that
might not be supported.
2) In a GUI context, if the End User expects the job might be moved to
another printer and prefers a sub-optimal result to nothing at all.
3) The End User just wants something reasonable in lieu of nothing at all.
15.2 Page Description Language (PDL) Override
If there is a conflict between the value of an IPP Job Template attribute
and a corresponding instruction in the print data, it is desirable that the
value of the IPP attribute take precedence over the document instruction.
Consider the case where a previously formatted file of print data is sent to
an IPP Printer. In this case, if the client supplies any attributes at job
submission time, the client desires that those attributes override the
embedded instructions. Consider the case were a previously formatted
document has embedded in it commands to load 'iso-a4' media. However, the
document is passed to an end user that only has access to a printer with
'na-letter' media loaded. That end user most likely wants to submit that
document to an that IPP Printer with the "media" Job Template attribute set
to 'na-letter'. The job submission attribute should take precedence over
the embedded PDL instruction. However, until companies that supply
interpreters for print data allow a way for external IPP attributes to take
precedence over embedded job production instructions, a Printer might not be
able to support the semantics that IPP attributes override the embedded
instructions.
The IPP model accounts for this situation by introducing a
"pdl-override-supported" attribute.
This attribute takes on the following values:
- 'attempted': This value indicates that the Printer attempts to make sure
that IPP attribute values take precedence over embedded instructions in the
Print data, however there is no guarantee.
- 'not-attempted': This value indicates that the Printer makes not attempt
to ensure that IPP attribute values take precedence over embedded
instructions in the print data.
This is a MANDATORY Printer attribute.
At job processing time, an implementation that supports the value of
'attempted' might try to do one of several different actions:
1) generate an output device specific command sequence to realize the
feature represented by the IPP attribute value
2) parse the print data itself and replace the conflicting embedded
instruction with a new embedded instruction that matches the intent of the
IPP attribute value
3) indicate to the Printer that external supplied attributes take precedence
over embedded instructions and then pass the external IPP attribute values
to the print data interpreter
4) anything else that allows for the semantics that IPP attributes override
embedded print data instructions.
Since 'attempted' does not offer any type of guarantee, even though a given
implementation might not do a very "good" job of attempting to ensure that
IPP attributes take a higher precedence over instructions embedded in the
print data, it would still be a conforming implementation.
Note: The "ipp-attribute-fidelity" attribute applies to the Printer's
ability to either accept or reject other unsupported attributes. In other
words, if "ipp-attribute-fidelity" is set to 'true', a Job is accepted if
and only if the client supplied attributes and values are supported by the
Printer. Whether these attributes actually affect the processing of the Job
depends on the ability of the Printer to override the instructions embedded
in the print data with the semantics of the IPP attributes. If the print
data attributes can be overridden ("pdl-override-supported" set to
'attempted'), the Printer makes an attempt to use the IPP attributes when
processing the Job. If the print data attributes can not be overridden
("pdl-override-supported" set to 'not-attempted'), the Printer makes no
attempt to use the IPP attributes when processing the Job, and hence, the
IPP attributes may fail to affect the Job processing and output in any
manner whatsoever.
15.3 Suggested Attribute Processing Algorithm
When a Printer receives a create request, the Printer either accepts or
rejects the request. The Printer accepts the create request and creates a
Job object if it is able to accept all Job Template and Document attributes
in the request. The Printer rejects the request and does not create a Job
object if the Printer rejects any Job Template or Document attribute in the
request. In order to determine whether or not to accept or reject the
request, the Printer SHOULD use the following algorithm:
1. The implementation checks to see if the operation is supported. If not,
the Printer rejects the request and sets the appropriate status code in the
response.
2. The implementation checks to see if the requested version is supported.
If not, the Printer rejects the request and sets the appropriate status code
in the response.
3. The implementation checks to see if the client supplied an
"ipp-attribute-fidelity" attribute. If the attribute is missing (not
supplied by the client), the Printer assumes that the value is 'false'.
4. The Printer loops through all other attributes, checking to see if the
requested values are supported (e.g., the value of "foo" in the request is
one of the values in the Printer's "foo-supported" attribute). If the
attribute or its value is unsupported, the Printer flags it as unsupported.
5. Once all attributes have been checked individually, the Printer checks
for any inconsistent values among all the supported values. For example a
Printer might be able to staple and to print on transparencies, however due
to physical stapling limitations, the Printer might not be able to staple
transparencies. Any inconsistent values are flagged as unsupported.
6. Once all attributes have been checked and validated, if
"ipp-attribute-fidelity" is set to true and there are any attributes flagged
as unsupported, the Printer rejects the request and returns all unsupported
attributes and values in the response and sets the appropriate status code.
7. If "ipp-attribute-fidelity" is set to 'false' (nor it was not supplied by
the client) and there are any attributes that are flagged as unsupported,
the Printer, chooses to either ignore the unsupported attributes or change
the requested value to some supported value. If, for some reason, it is not
possible for the implementation to ignore or substitute values and is unable
to "just print the job", the Printer is still able to reject the request and
return all unsupported attributes and values in the response. In doing so,
the Printer sets the appropriate status code.
8. If the Printer is able to accept the request (either as is or by making
changes and the "ipp-attribute-fidelity" attribute is set to 'false'), the
Printer creates a new Job object with the remaining valid Job Template
attributes. Initially it sets the Job's state to 'pending'. These Job
Template attributes are associated with the Job object. All attributes
which are associated with the Job object are intended to be override values
that take precedence over whatever other embedded instructions might be in
the print data itself. That is, IPP allows for submission time attributes
to take precedence over static instructions embedded in the print data.
These submission time attributes are persistently stored with the Job.
However, it is not possible for all implementations to realize the semantics
of "override". End users may query the Printer's "pdl-override" attribute
to determine if the Printer either attempts or does not attempt to override
print data instructions with IPP attributes.
9. There are some cases, where a Printer supports a Job Template attribute
and has an associated default value set for that attribute. In the case
where a client does not supply the corresponding attribute, the Printer does
not use its default values to populate Job attributes when creating the new
Job object. The Printer's default values are used at Job processing time
where no other IPP attribute or instruction embedded in the print data is
present. Suppose the Printer were to associate the Printer's default value
with the Job at creation time for an attribute not supplied by the client.
This would change it from a default value to an override value. A later
query of the Job object would return a set of attributes. Neither the
Printer nor the end user would be able to tell the difference between an
attribute that is an "override PDL" attribute supplied by the client or a
"default value" attribute supplied by the printer.
10. If the client does not supply a value for some Job Template attribute,
and the Printer does not support that attribute, as far as IPP is concerned,
the result of processing that Job (with respect to the missing attribute) is
undefined.
11. Once the Job object has been created, the Printer responds back to the
client with a successful response including Job status attributes that
indicate the initial state of the Job ('pending', 'processing', etc.). The
Printer uses its own configuration and implementation specific algorithms
for scheduling the Job in the correct processing order. Once the Printer
begins processing the Job, the Printer changes the Job's state to
'processing'. The Printer monitors all Jobs and notifies the intended
recipients for each event by processing the all of the "notify-events" and
"notify-addresses" Job attributes. If the Printer supports PDL override
(the "pdl-override" attribute set to 'attempted'), the implementation does
its best to see that IPP attributes take precedence over embedded
instructions in the print data.
12. The implementation of the Printer object continues to process the Job
until it can move the Job into the 'completed' state. If an Cancel-Job
operation is received, the implementation eventually moves the Job into the
'cancelled' state. If the system encounters errors during processing that
do not allow it to progress the Job into a completed state, the
implementation halts all processing, cleans up any resources, and moves the
Job into the 'aborted' state.
13. Once the Job moves to the 'completed', 'aborted', or 'cancelled' state,
it is an implementation decision as to when to destroy the Job object and
release all associated resources. Once the Job has been destroyed, the
Printer would return either the "not-found" or "gone" status codes for
operations directed at that Job.
Some Printer implementations may support "ipp-attribute-fidelity" set to
'true' and "pdl-override" set to 'attempted' and yet still not be able to
realize exactly what the client specifies in the create request. This is
due to legacy decisions and assumptions that have been made about the role
of job instructions embedded within the print data and external job
instructions that accompany the print data and how to handle conflicts
between such instructions. The inability to be 100% precise about how a
given implementation will behave is also compounded by the fact that the two
special attributes, "ipp-attribute-fidelity" and "pdl-override", apply to
the whole job rather than specific values for each attribute. For example,
some implementations may be able to override almost all Job Template
attributes except for "number-up". It would only make the IPP model more
complex (with relatively little added value) to allow for additional special
attributes that apply uniquely to each Job Template attribute or even
specific values of each attribute.