This work in progress on Section 15.3 and the new 15.4 sections.
The specific comments to the rest of the document as a result are included
first.
I've put the ipp-section-15-3-rev.pdf and ipp-section-15-3.pdf
and ipp-section-15-3.txt (same as embedded here) in
ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-section-15-3.pdf
We'll have a final version next Monday or Tuesday.
Tom
Subj: Comments on the document that relate to the processing algorithm
From: Roger deBry, Tom Hastings, Bob Herriot, Scott Isaacson,
Date: 12/25/97
File: ipp-section-15-3.doc
Revisions made after telecon, Monday, 11/24/97 with Roger and Scott.
The new revision marks are in one color, and the older ones are in
another.
Here are some comments on the current draft of the Model document:
1. Section 3, Operations
The validation of all Operation attributes is independent of the "ipp-
attribute-fidelity" attribute. The "ipp-attribute-fidelity" only
applies to Job Template attributes in create and Validate-Job
requests.
2. Section 3, Operations
The Model document should indicate for each request and response group
whether the Operation attributes are MANDATORY for the IPP object to
support and whether they are required for the client to supply and/or
the IPP object to return or not, just as for attributes.
3. Section 3.1.6, Version
Should be able to add OPTIONAL (for an IPP object to support)
Operation attributes as a minor version change, not a major version
change. Adding MANDATORY Operation attributes requires a major
version change.
4. Section 3.2.1.2, Print-Job response
Third to last paragraph: only return the attributes in conflict that
are ignored or substituted, not the ones that are ok. For example, if
the Printer object resolves the conflict: "media" = 'transparencies'
and "finishings" = staple by ignoring "finishings", then only
"finishing"='staple' should be returned in the Unsupported Attributes
Group.
5. Section 3.2.5, Get Attributes (for Printer objects)
As agreed on the 11/19 IPP telecon, the name space for Operation
attributes and Job Template attributes is the same, so we can't use
the same name for both an Operation attribute and a Job Template
attribute, though we can use the same name for an Operation attribute
whose purpose is to initialize a Job Description attribute, such as
"job-name", "attributes-charset", or "attribute-natural-language".
Therefore, we suggest that the "document-format" Operation attribute
in the Get-Attributes (for Printer object) be changed to "which-
document-format" to give a different name, and to align with the
"which-jobs" Operation attribute.
6. Section 3.2.5.1, Get-Attributes Request
Change the "which-document-format" to MANDATORY (for a Printer object
to support and change to reject the operation and return the 'client-
error-document-format-not-supported' status code if the document
format is not supported, but change the definition of support so that
it aligns with the validation that the Printer does for create
operations. See separate e-mail on 11/14/97.
7. Section 3.2.6.1 Get-Jobs Request
Make "which-jobs" and "my-jobs" MANDATORY for an IPP object to support
and require support of both values for each. Clarify that support of
'completed' for a system that doesn't keep jobs after they complete,
is to always return no jobs.
8. Section 3.3.1.2, Send-Document Response
Writing the table on attribute groups, we found that the Send-Document
(and Send-URI) operation needs to return the Unsupported Attributes
group as group 3 if the client supplies unsupported attributes.
Section 3.3.4, Get-Attributes Operation (for Job objects)
Needs to return the Job Object Attributes, not the Printer Object
Attributes group in the response. So add a phrase to the last
sentence indicating this difference from the Get-Attributes Operation
(for Printer objects): "and the returned attribute group is Job
Object Attributes, instead of Printer Object Attributes."
9. Section 4.2, Job Template Attributes
The following four Job Template attributes should move to become
create Operation attributes and Job Description attributes:
"compression", "job-k-octets", "job-impressions", and "job-media-
sheets". These attributes are describing the job, not requesting some
type of processing. The corresponding "compression-supported", "job-k-
octets-supported", "job-impressions-supported", and "job-media-sheets-
supported" become Printer Description attributes. Also none of these
four attributes had "xxx-default" attributes, further indicating that
they are different from Job Template attributes.
These four Operation attributes are OPTIONAL for Printers to support,
so some Operation attributes are OPTIONAL for a Printer to support and
some are MANDATORY. Clients NEED NOT supply these Operation
attributes, just as when they were Job Template attributes.
10. Section 4.2 Job Template Attributes table
Change the attribute syntax of "copies-supported" and "copies-collated-
supported" to rangeOfInteger, so like all other integer attributes
which simplifies validation and so an administrator can specify a
lower bound.
11. Section 4.2, Job Template Attributes table and Section 4.2.5
copies
Do we need "copies-collated-supported" and "copies-collated-default?
It make the Job Template validation more ad hoc for "copies". Also,
the limit on uncollated copies is not for uncollated sheets in a copy,
but uncollated documents in a multi-document job, so that neither are
addressing a multi-output-bin collator which might have a different
(lower) maximum copies supported than when the device makes multiple
passes over the PDL (or interpreted bit maps) and uses a single output
bin.
12. Section 4.4, Printer Description attributes table and Sections
4.4.17 document-format and 4.4.18 document-format-supported
The "document-format" and "document-format-supported" Printer
attributes need to be MANDATORY. A client has to be able to query
them.
13. Section 13.1.4.12, client-error-attribute-not-supported (0x040B)
and Section 13.2
Change the name to include values and make plural: client-error-
attributes-or-values-not-supported (0x040B), since there is a
distinction between an attribute not supported and an attribute value
not supported, but both are returned on this error.
14. Section 15.3, Suggested Operation Processing Algorithm for Create
and Validate-Job operations
Make this section apply to all operations. Add a subsequent section
that has the additional processing steps for create and Validate-Job
operations.
15. Section 15.3, Suggested Operation Processing Algorithm for Create
and Validate-Job operations
Add the semantics for all of the Operation attributes.
The following revised version of Section 15.3 is offered to meet the
above comments.
15.3 Suggested Operation Processing Algorithm for all operations
When an IPP object receives a request, the IPP object either accepts
or rejects the request. In order to determine whether or not to accept
or reject the request, the IPP object SHOULD use the following
algorithm or an equivalent one that produces the same results. The
order of the steps may be rearranged and/or combined, including making
one or multiple passes over the request. Therefore, the error status
codes returned may differ between implementations when there is more
than one error in a request. The next section contains the additional
steps for the Print-Job, Validate-Job, Print-URI, Create-Job, Send-
Document, and Send-URI operations that create jobs, adds documents,
and validates jobs.
The table below contains abbreviations for operations used in the
other tables in this section:
Abbr Operation Abb Operation Abbr Operation
r
pj Print-Job sd Send-Document gap Get-Attribute
(Printer)
cj Create- su Send-URI gaj Get-Attribute
Job (Job)
vj Validate- caj Cancel-Job gj Get-Jobs
Job
pu Print-URI
In the following algorithm, processing continues step by step until a
"RETURNS the xxx status code ..." statement is encountered. Error
returns are indicated by the verb: "REJECTS". Each error return to
the client SHOULD be made before the entire Document Content data
stream is accepted, so that the client need not send all of the data
for a request that is being rejected.
It is assumed that security authentication and authorization has
already taken place at a lower layer.
15.3.1 Validate version number
The Printer object checks to see if the requested major and minor
version number is supported. If not, the Printer object REJECTS the
request and RETURNS the 'server-error-version-not-supported' status
code in the response. The checking of the minor version number is
implementation dependent. Some implementations MAY accept all minor
version numbers, while others MAY only accept ones that are equal to
or lower than the highest one that they support.
ISSUE: Do we need a "version-supported" attribute? If yes, it should
be multi-valued. How indicate support of future minor versions? Or
just make it "major-version-supported" (but multi-valued).
15.3.2 Validate operation code
The Printer object checks to see if the operation is supported as
indicated in the Printer object's "printer-operations-supported"
attribute. If not, the Printer REJECTS the request and returns the
'server-error-operation-not-supported' status code in the response.
15.3.3 Validate attribute group presence and order
Client requests and IPP object responses contain attribute groups in
the order in Section 4. An IPP object verifies that the attribute
groups are present and in the correct order. If an IPP object receives
a request with required attribute groups missing or the attributes
groups are out of order, the IPP object REJECTS the request and
returns the 'client-error-bad-request' status code. For example, it
is an error for the Job Template Attributes group to occur before the
Operation Attributes group, for the Operation Attributes group to be
omitted, or for an attribute group to occur more than once, except the
Get-Jobs request.
The numbers indicate the required order for the groups in a request or
a response.
Note: The Document Content group is supplied and is empty for the
Create-Job, Validate-Job, Print-URI, and Send-URI requests.
Operation Attribute Group Client: IPP object:
Printer
operations:
Print-Job 1. Operation SHALL SHALL
Create-Job Attributes supply support
Print-URI
request:
2. Job Template MAY supply SHALL
Attributes support
3. future groups SHALL ignore
4. Document SHALL SHALL
Content supply support
response: 1. Operation SHALL supply
Attributes
2. Job Object SHALL supply
Attributes
3. Unsupported SHALL supply
Attributes if the
client
supplied
unsupported
Operation or
Job Template
attributes
Validate-Job 1. Operation SHALL SHALL
Attributes supply support
2. Job Template MAY supply SHALL
Attributes support
3. future groups SHALL ignore
response: 1. Operation SHALL supply
Attributes
2. Job Object SHALL supply
Attributes
3. Unsupported SHALL supply
Attributes if the
client
supplied
unsupported
Operation or
Job Template
attributes
Get- 1. Operation SHALL SHALL
Attributes Attributes supply support
request (for
a Printer
object):
2. future groups SHALL ignore
response: 1. Operation SHALL supply
Attributes
2. Requested SHALL
Printer Object supply, if
Attributes there are
any Printer
attributes
to return
3. future SHALL ignore
additional groups
Get-Jobs 1. Operation SHALL SHALL
request: Attributes supply support
response: 1. Operation SHALL supply
Attributes
2. future SHALL ignore
additional groups
3 to n. Requested SHALL supply
Job Object 0 to n
Attributes groups
Job
operations:
Send- 1. Operation SHALL SHALL
Document, Attributes supply support
Send-URI
2. future groups SHALL ignore
3. Document SHALL SHALL
Content supply support
response: 1. Operation SHALL supply
Attributes
2. Job Object SHALL supply
Attributes
3. Unsupported SHALL supply
Attributes if the
client
supplied any
unsupported
attributes
Cancel-Job 1. Operation SHALL SHALL
request: Attributes supply support
response: 1. Operation SHALL supply
Attributes
Get- 1. Operation SHALL SHALL
Attributes Attributes supply support
request (for
a Job
object):
2. future groups SHALL ignore
response: 1. Operation SHALL supply
Attributes
2. Requested Job SHALL
Object Attributes supply, if
there are
any Job
attributes
to return
All unknown group in SHALL ignore
operations indicated position
requests:
Unknown group in SHALL REJECT
another position
response: unknown group SHALL
ignore
Since this kind of error is most likely to be an error detected by a
client developer rather than by a customer, the IPP object NEED NOT
return an indication of which attribute group was out of order in
either the Unsupported Attributes group or the Status Message. Also,
the IPP object NEED NOT find all attribute group errors before
returning this error.
15.3.4 Validate presence of required Operation attributes
If the client fails to supply an Operation attribute that clients MUST
supply, the IPP object returns the 'client-error-bad-request' status
code.
Operation Attribute Operations
attributes-charset all
attributes-natural- all
language
document-uri pu, su
job-id (when to sd, su, caj,
Printer URI) gaj
last-document sd, su
Since this kind of error is most likely to be an error detected by a
client developer rather than by a customer, the IPP object NEED NOT
return an indication of which attributes are missing in either the
Unsupported Attributes group or the Status Message. Also, the IPP
object NEED NOT find all missing Operation attributes before returning
this error.
15.3.5 Ignore unsupported Operation attributes
An IPP object ignores all unsupported Operation attributes in all
operations. For the create operation, this rule is independent of the
value of the "ipp-attribute-fidelity" attribute. In order to inform
the client of an unsupported Operation attribute, an IPP object copies
such an Operation attribute to the Unsupported Attributes group in the
response [renamed 'unsupported-attributes' delimiter tag in the
Protocol document and change the value to the out-of-band
'unsupported' value].
When the operation is otherwise successful, the IPP object returns the
'successful-ok-ignored-or-substituted-attributes' status code. This
treatment of unsupported Operation attributes in all operations is
analogous to the handling of unsupported Job Template attributes in
the create and Validate-Job operations when the client supplies the
"ipp-attribute-fidelity" Operation attribute with the 'false' value.
Rationale: This rule is so that we can add OPTIONAL Operation
attributes to future versions of IPP so that older clients can inter-
work with new IPP objects and newer clients can inter-work with older
IPP objects.
15.3.6 Validate the values of the MANDATORY Operation attributes
An IPP object validates the values of the MANDATORY Operation
attribute supplied by the client that the IPP object MUST support.
The next section specifies the validation of the values of the
OPTIONAL Operation attributes that IPP objects MAY support. The IPP
object performs the validation action indicated in the following table
Each xxx attribute is checked against the following:
a) that the length of each value is correct for the attribute syntax
tag supplied by the client according to Section 4.1.
b) that the attribute syntax tag is correct for the attribute in
Sections 4.2 to 4.6,
c) that the value is in the range specified for that attribute in
Sections 4.2 to 4.6,
d) the multiple values are not supplied for attributes that are
single-valued, i.e., that are not 1setOf X) as specified in Sections
4.2 to 4.6
If any of these checks fail, the IPP object REJECTS the request and
RETURNS the 'client-error-bad-request'. Since such an error is most
likely to be an error detected by a client developer, rather than by
an end-user, the IPP object NEED NOT return an indication of which
attribute had the error in either the Unsupported Attributes Group or
the Status Message.
In addition, the IPP object checks the value against some Printer
attribute or some hard-coded value if there is no "xxx-supported"
Printer attribute defined. The check fails if its value is not among
those supported and the IPP object RETURNS in error status code
indicated in the table.
Operation Operation Validation check
Attributes s
xxx
attributes- all Any single non-empty 'charset' value
charset less than 63 octets AND in the
(charset) Printer's "charset-supported"
attribute;
else REJECT with "client-error-charset-
not-supported"
attributes- all Any single non-empty 'naturalLanguage'
natural- value less than 63 octets, even if not
language a member of the set in the Printer's
(naturalLangu "natural-language-supported" attribute.
age)
"requesting- all Any single non-empty 'name' value less
user-name" than 255, but if the IPP object can
obtain a better authenticated name, use
it instead.
job-name pj, vj, Any single non-empty 'name' value less
(name) pu, cj than 255.
document-name pj, vj, Any single non-empty 'name' value less
(name) pu, sd, than 255.
su
ipp-attribute- pj, vj, Either a single 'true' or 'false'
fidelity pu, cj, 'boolean' value.
(boolean) sd, su
document- pj, vj, Any single non-empty 'mimeMediaType'
format pu, cj, value less than 63 octets AND in the
(mimeMediaTyp sd, su Printer's "document-format-supported"
e) attribute
else REJECT with 'client-error-document-
format-not-supported'
document-uri pu, su Any single non-empty 'uri' value less
(uri) than 1023 octets AND whose scheme is in
the Printer object's "reference-uri-
schemes-supported" attribute
else REJECT with 'client-error'-uri-
scheme-not-supported'
last-document sd, su Either a single 'true' or 'false'
(boolean) 'boolean' value.
job-id sd, su, Any single integer value in the range 1
(integer(1:MA caj, gaj to MAX AND a job-id of an existing Job
X)) object
else REJECT with the 'client-error-not-
found' or 'client-error-gone' status
code, if keep track or recently deleted
jobs
which- gap Any single non-empty 'mimeMediaType'
document- value less than 63 octets
format else REJECT with "client-error-document-
(type2 format-not-supported"
mimeMediaType
) If not supplied by the client, the
Printer assumes the value of the
Printer's "document-format" attribute.
requested- gap, gaj, Any number of 'keyword' values less
attributes gj than 255 octets
(1setOf Ignore unsupported values which are the
keyword) keyword names of unsupported
attributes. Don't bother to copy such
requested (unsupported) attributes to
the Unsupported Attribute response
group.
which-jobs gj Either a single 'not-completed' or
(type2 'completed' keyword value
keyword)
Note: a Printer still supports the
'completed' value even if it keeps no
completed/canceled/aborted jobs: by
returning no jobs when so queried.
my-jobs gj Either a single 'true' or 'false'
(boolean) 'boolean' value.
limit gj Any single integer value in the range 1
(integer(1:MA to MAX
X))
ISSUE: We propose to make "which-jobs" and "my-jobs" MANDATORY for an
IPP object to support.
15.3.7 Validate the values of OPTIONAL Operation attributes
supported
OPTIONAL Operation attributes are those that an IPP object MAY or MAY
NOT support. An IPP object validates the OPTIONAL attribute supplied
by the client that IPP object supports. The IPP object performs the
validation action indicated in the following table. Each xxx
attribute that the Printer recognizes is validated as in Section
15.3.6.
If the Printer object doesn't recognize/support an attribute (whether
it is in this table or not), the Printer treats the attribute as an
unknown attribute (see the unknown row in the table below). For
example, if a printer doesn't support "job-k-octets" (because of the
implementation or because of some administrator's choice), the Printer
treats "job-k-octets" as an unknown attribute.
Operation Operatio Validation check
Attributes ns
xxx
document- pj, pu, Any single non-empty 'naturalLanguage'
natural- sd, su value less than 63 octets that the
language Printer supports, (no standard Printer
(naturalLangu "xxx-supported" attribute)
age) else REJECT with 'client-error-natural-
language-not-supported'
compression pj, vj, Any single 'keyword' values less than
(type3 cj, pu 255 octets AND in the Printer's
keyword) "compression-supported"
else REJECT with 'client-error-attribute-
or-value-not-supported'.
job-k-octets pj, vj, Any single integer value in the range 0
(integer(0:MA pu , cj to MAX AND in the range of the Printer's
X)) "job-k-octets-supported"
else REJECT with the 'client-error-
attribute-or-value-not-supported'
job- pj, vj, Any single integer value in the range 0
impressions pu , cj to MAX AND in the range of the Printer's
(integer(0:MA "job-impressions-supported"
X)) else REJECT with the 'client-error-
attribute-or-value-not-supported'
job-media- pj, vj, Any single integer value in the range 0
sheets pu , cj to MAX AND in the range of the Printer's
(integer(0:MA "job-media-supported"
X)) else REJECT with the 'client-error-
attribute-or-value-not-supported'
message caj Any single non-empty 'text' value less
(text) than 1023 octets.
unknown all not applicable
attribute
ISSUE: the "document-format" Operation attribute is proposed to be
changed to "which-document-format" in the Get Attributes (from
Printer) operation, so that it isn't confused with the "document-
format" Operation attribute that is used in pj, cj, vj, pu, sd, and su
to identify the document format of the document being submitted.
15.4 Suggested Additional Processing for Operations that create jobs
This section is combination with the previous section recommends the
processing algorithm, or equivalent, for the Print-Job, Validate-Job,
Print-URI, Create-Job, Send-Document, and Send-URI operations that
create jobs the IPP objects SHOULD use.
15.4.1 Default "ipp-attribute-fidelity" if not supplied
The Printer object checks to see if the client supplied an "ipp-
attribute-fidelity" Operation attribute. If the attribute is missing
(not supplied by the client), the Printer assumes that the value is
'false'.
15.4.2 Validation of Job Template attributes and values
All Job Template attributes are OPTIONAL for a Printer object to
support. An IPP object validates all Job Template attribute supplied
by the client that IPP object supports. The IPP object performs the
action indicated in the following table when the value is not a
supported value (bad syntax has already been checked above).
The Printer object loops through all the client-supplied Job Template
attributes, checking to see if the supplied attribute and values are
supported, e.g., the value of the "xxx" attribute in the request is
one of the values in the Printer's "xxx-supported" attribute. If an
attribute is not supported, i.e., there is no corresponding Printer
object "xxx-supported" attribute, the Printer object copies the
attribute to the Unsupported Attribute response group and sets its
value to the out-of-band 'unsupported' value.. If an attribute value
is not supported, i.e., there is no corresponding value in the Printer
object's "xxx-supported" attribute, the Printer object copies the
attribute to the Unsupported Attributes response group with its value.
If the attribute contains more than one value, each value is checked
and each unsupported value is separately copied, while supported
values are not.
If some Job Template attributes are supported for some document
formats and not for others or the values are different for different
document formats, the IPP object SHOULD take that into account in this
validation.
The table below lists the Job Template attributes and shows what the
Printer does if a value is unsupported. All are OPTIONAL for a Printer
to support. Each "xxx" attribute that the Printer recognizes is
checked against a printer attribute with the name "xxx-supported"
(after "copies-collated-supported" gets removed) to determine if the
value is supported. If the Printer doesn't recognize/support an
attribute, the Printer treats the attribute as an unknown attribute
(see the unknown rows in the table below).
Note: whether the request is accepted or rejected is determined by the
value of the "ipp-attributes-fidelity" attribute in a subsequent step,
so that all Job Template attribute supplied are examined.
Job Template Attribute IPP object action when the attribute is
xxx supported, but the value is not
job-priority Map the value, which has already been
(integer(1:100)) checked to be between 1 and 100 to the
nearest supported value in the range
1:100 as specified by the Printer's "job-
priority-supported" attribute.
job-hold-until Copy the attribute and value to the
(type4 keyword | name) Unsupported Attribute response group, if
not a member of the set in Printer's "job-
hold-until-supported" attribute.
job-sheets Copy the attribute and value to the
(type4 keyword | name) Unsupported Attribute response group, if
not a member of the set in Printer's "job-
sheets-supported" attribute.
multiple-document- Copy the attribute and value to the
handling Unsupported Attribute response group, if
(type2 keyword) not a member of the set in Printer's
"multiple-document-handling-supported"
attribute.
copies Copy the attribute and value to the
(integer(1:MAX)) Unsupported Attribute response group, if
not a member of the rangeOfInteger in
Printer's "copies-supported" attribute or
"copies-collated-supported" attribute,
depending on the value of the "multiple-
document-handling" attribute.
finishings Copy the attribute and value to the
(1setOf type2 enum) Unsupported Attribute response group, if
not a member of the set in Printer's
"finishings-supported" attribute.
page-ranges Copy the attribute and value to the
(1setOf Unsupported Attribute response group, if
rangeOfInteger(1:MAX)) the Printer's "page-ranges-supported"
attribute is 'false'.
sides Copy the attribute and value to the
(type2 keyword) Unsupported Attribute response group, if
not a member of the set in Printer's
"sides-supported" attribute.
number-up Copy the attribute and value to the
(integer(0:MAX)) Unsupported Attribute response group, if
not a member of the set of integer or
rangeOfInteger in Printer's "number-up-
supported" attribute.
orientation Copy the attribute and value to the
(type2 enum) Unsupported Attribute response group, if
not a member of the set in Printer's
"orientation-supported" attribute.
media Copy the attribute and value to the
(type4 keyword | name) Unsupported Attribute response group, if
not a member of the set in Printer's
"media-supported" attribute.
printer-resolution Copy the attribute and value to the
(resolution) Unsupported Attribute response group, if
not a member of the set in Printer's
"printer-resolution-supported" attribute.
print-quality Copy the attribute and value to the
(type2 enum) Unsupported Attribute response group, if
not a member of the set in Printer's
"print-quality-supported" attribute.
unknown attribute Copy the attribute to the Unsupported
Attribute response group and set the
value to the out-of-band 'unsupported'
value.
ISSUE: We propose to change "copies-supported" a rangeOfInteger, so
like all the others and so can have a lower bound.
15.4.3 Check for conflicting Job Template attributes
Once all the Operation and Job Template attributes have been checked
individually, the Printer object SHOULD check for any conflicting
values among all the supported values supplied by the client. For
example, a Printer object might be able to staple and to print on
transparencies, however due to physical stapling constraints, the
Printer object might not be able to staple transparencies. The IPP
object copies the supported attributes and their conflicting attribute
values to the Unsupported Attributes response group. The Printer
object only copies over those attributes that the Printer object
either ignores or substitutes in order to resolve the conflict, and it
returns the original values which were supplied by the client. For
example suppose the client supplies "finishings" equals 'staple' and
"media" equals 'transparency', but the Printer object does not support
stapling transparencies. If the Printer chooses to ignore the stapling
request in order to resolve the conflict, the Printer objects returns
"finishings" equal to 'staple' in the Unsupported Attributes response
group. If any attributes are multi-valued, only the conflicting
values of the attributes are copied.
15.4.4 Decide whether to REJECT the request
If there were any unsupported attributes or unsupported/conflicting
attribute values and the client supplied the "ipp-attribute-fidelity"
attribute with the 'true' value, the Printer object REJECTS the
request and return the status code:
(1) 'client-error-conflicting-attributes' status code, if there were
any conflicts
(2) 'client-error-attribute-not-supported' status code, otherwise.
15.4.5 Return one of the success status codes, if the Validate-Job
operation
If the requested operation is the Validate-Job operation, the Printer
object returns:
(1) the "successful-ok" status code, if there are no unsupported or
conflicting attributes or values.
(2) the "successful-ok-conflicting-attributes, if there are any
conflicting attribute or values.
(3) the "successful-ok-ignored-or-substituted-attributes, if there are
only unsupported attributes or values.
15.4.6 Create Job object with attributes to support
If "ipp-attribute-fidelity" is set to 'false' (or it was not supplied
by the client), the Printer object:
(1) removes all unsupported attributes from the Job object.
(2) for each unsupported value, removes either the unsupported value
or substitutes the unsupported attribute value with some supported
value. If an attribute has no values after removing unsupported
values from it, the attribute is removed from the Job object (so that
the normal default behavior at job processing time will take place for
that attribute).
(3) for each conflicting value, removes either the conflicting value
or substitutes the conflicting attribute value with some other
supported value. If an attribute has no values after removing
conflicting values from it, the attribute is removed from the Job
object (so that the normal default behavior at job processing time
will take place for that attribute).
If there were no attributes or values flagged as unsupported, or the
value of 'ipp-attribute-fidelity" was 'false', the Printer object is
able to accept the create request and create a new Job object. If the
"ipp-attribute-fidelity" attribute is set to 'true', the Job Template
attributes that populate the new Job object are necessarily all the
Job Template attributes supplied in the create request. If the "ipp-
attribute-fidelity" attribute is set to 'false', the Job Template
attributes that populate the new Job object are all the client
supplied Job Template attributes that are supported or that have value
substitution. Thus, some of the requested Job Template attributes may
not appear in the Job object because the Printer object did not
support those attributes. The attributes that populate the Job object
are persistently stored with the Job object for that Job. A Get-
Attributes operation on that Job object will return only those
attributes that are persistently stored with the Job object.
Note: All Job Template attributes that are persistently stored with
the Job object are intended to be "override values"; that is, they
that take precedence over whatever other embedded instructions might
be in the document data itself. However, it is not possible for all
Printer objects 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 document data
instructions with IPP attributes.
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; only Job Template
attributes actually in the create request are used to populate the Job
object. The Printer's default values are only used at Job processing
time if no other IPP attribute or instruction embedded in the document
data is present.
Note: If the default values associated with Job Template attributes
that the client did not supply were to be used to populate the Job
object, then these values would become "override values" rather than
defaults. If the Printer supports the 'attempted' value of the "pdl-
override" attribute, then these override values could replace values
specified within the document data. This is not the intent of the
default value mechanism. A default value for an attribute is used only
if the create request did not specify that attribute (or it was
ignored when allowed by "ipp-attribute-fidelity" being 'false') and no
value was provided within the content of the document data.
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.
15.4.7 Return one of the success status codes
Once the Job object has been created, the Printer object accepts the
request and returns to the client:
(1) the 'successful-ok' status code, if there are no unsupported or
conflicting attributes or values.
(2) the 'successful-ok-conflicting-attributes' status code, if there
are any conflicting attribute or values.
(3) the 'successful-ok-ignored-or-substituted-attributes' status code,
if there are only unsupported attributes or values.
The Printer object also returns Job status attributes that indicate
the initial state of the Job ('pending', 'pending-held', 'processing',
etc.), etc. See Print-Job Response, section Error! Reference source
not found..
15.4.8 Accept appended Document Content
The Printer object accepts the appended Document Content data and
either starts it printing, or spools it for later processing.
15.4.9 Scheduling and Starting to Process the Job
The Printer object uses its own configuration and implementation
specific algorithms for scheduling the Job in the correct processing
order. Once the Printer object begins processing the Job, the Printer
changes the Job's state to 'processing'. If the Printer object
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 document
data.
15.4.10 Completing the Job
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
'canceled' 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.
15.4.11 Destroying the Job after completion
Once the Job moves to the 'completed', 'aborted', or 'canceled' 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 "client-error-not-
found" or "client-error-gone" status codes for operations directed at
that Job.
15.4.12 Interaction with "ipp-attribute-fidelity"
Some Printer object 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
document data and external job instructions that accompany the
document 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".