INTERNET-DRAFT
draft-ietf-ipp-implementers-guide-00.txt
T. Hastings
Xerox Corporation
C. Manros
Xerox Corporation
November 16, 1998
Internet Printing Protocol/1.0: Implementer's Guide
Copyright (C) The Internet Society (date). All Rights Reserved.
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress".
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This document is one of a set of documents, which together describe all
aspects of a new Internet Printing Protocol (IPP). IPP is an
application level protocol that can be used for distributed printing
using Internet tools and technologies. This document contains
information that supplements the IPP Model and Semantics [IPP-MOD] and
the IPP Transport and Encoding [IPP-PRO] documents. It is intended to
help implementers understand IPP/1.0 and some of the considerations that
may assist them in the design of their client and/or IPP object
implementations. For example, a typical order of processing requests is
given, including error checking. Motivation for some of the
specification decisions is also included.
Hastings, Manros [page 1]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol [IPP-REQ]
Rationale for the Structure and Model and Protocol for the Internet
Printing Protocol [IPP-RAT]
Internet Printing Protocol/1.0: Model and Semantics [IPP-MOD]
Internet Printing Protocol/1.0: Encoding and Transport [IPP-PRO]
Mapping between LPD and IPP Protocols [IPP LPD]
The document, "Design Goals for an Internet Printing Protocol", takes a
broad look at distributed printing functionality, and it enumerates
real-life scenarios that help to clarify the features that need to be
included in a printing protocol for the Internet. It identifies
requirements for three types of users: end users, operators, and
administrators. The design goals document calls out a subset of end
user requirements that are satisfied in IPP/1.0. Operator and
administrator requirements are out of scope for version 1.0.
The document, "Rationale for the Structure and Model and Protocol for
the Internet Printing Protocol", describes IPP from a high level view,
defines a roadmap for the various documents that form the suite of IPP
specifications, and gives background and rationale for the IETF working
group's major decisions.
The document, "Internet Printing Protocol/1.0: Model and Semantics",
describes a simplified model with abstract objects, their attributes,
and their operations. The model introduces a Printer and a Job. The
Job supports multiple documents per Job. The model document also
addresses how security, internationalization, and directory issues are
addressed.
The document, "Internet Printing Protocol/1.0: Encoding and Transport",
is a formal mapping of the abstract operations and attributes defined in
the model document onto HTTP/1.1. It also defines the encoding rules
for a new Internet media type called "application/ipp".
The document, "Mapping between LPD and IPP Protocols", gives some advice
to implementers of gateways between IPP and LPD (Line Printer Daemon)
implementations.
Hastings, Manros [page 2]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
TABLE OF CONTENTS
1 Introduction......................................................5
1.1 Conformance language...........................................5
1.2 Other terminology..............................................6
2 Model and Semantics...............................................6
2.1 Suggested Operation Processing Steps for IPP Objects...........6
2.1.1 Suggested Operation Processing Steps for all Operations.....7
2.1.1.1 Validate version number.................................7
2.1.1.2 Validate operation identifier...........................7
2.1.1.3 Validate the request identifier.........................7
2.1.1.4 Validate attribute group and attribute presence and order8
2.1.1.5 Validate the values of the REQUIRED Operation attributes15
2.1.1.6 Validate the values of the OPTIONAL Operation attributes18
2.1.2 Suggested Additional Processing Steps for Operations that
Create/Validate Jobs and Add Documents...........................20
2.1.2.1 Default "ipp-attribute-fidelity" if not supplied.......20
2.1.2.2 Check that the Printer object is accepting jobs........20
2.1.2.3 Validate the values of the Job Template attributes.....20
2.1.2.4 Check for conflicting Job Template attributes values...25
2.1.2.5 Decide whether to REJECT the request...................25
2.1.2.6 For the Validate-Job operation, RETURN one of the success
status codes....................................................26
2.1.2.7 Create the Job object with attributes to support.......26
2.1.2.8 Return one of the success status codes.................28
2.1.2.9 Accept appended Document Content.......................28
2.1.2.10Scheduling and Starting to Process the Job.............28
2.1.2.11Completing the Job.....................................28
2.1.2.12Destroying the Job after completion....................29
Hastings, Manros [page 3]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
2.1.2.13Interaction with "ipp-attribute-fidelity"..............29
2.2 Status codes returned by operation............................29
2.2.1 Printer Operations.........................................29
2.2.1.1 Print-Job..............................................29
2.2.1.2 Print-URI..............................................31
2.2.1.3 Validate-Job...........................................31
2.2.1.4 Create-Job.............................................31
2.2.1.5 Get-Printer-Attributes.................................32
2.2.1.6 Get-Jobs...............................................32
2.2.2 Job Operations.............................................33
2.2.2.1 Send-Document..........................................33
2.2.2.2 Send-URI...............................................34
2.2.2.3 Cancel-Job.............................................34
2.2.2.4 Get-Job-Attributes.....................................35
2.3 Validate-Job..................................................36
2.4 Case Sensitivity in URIs......................................36
2.5 Natural Language Override (NLO)...............................36
2.6 The "queued-job-count" Printer Description attribute..........38
2.6.1 Why is "queued-job-count" RECOMMENDED?.....................38
2.6.2 Is "queued-job-count" a good measure of how busy a printer is?
38
2.7 Sending empty attribute groups................................38
2.8 Returning unsupported attributes in Get-Xxxx responses........38
2.9 Returning job-state in Print-Job response.....................38
2.10 Multi-valued attributes.....................................39
3 Encoding and Transport...........................................40
3.1 General Headers...............................................41
3.2 Request Headers..............................................41
Hastings, Manros [page 4]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
3.3 Response Headers..............................................42
3.4 Entity Headers...............................................43
3.5 Optional support for HTTP/1.0.................................44
3.6 HTTP/1.1 Chunking.............................................44
4 References.......................................................45
4.1 Authors' Address..............................................45
5 Appendix C: Full Copyright Statement.............................46
1 Introduction
This document contains information that supplements the IPP Model and
Semantics [IPP-MOD] and the IPP Transport and Encoding [IPP-PRO]
documents. As such this information is not part of the formal
specifications. Instead information is presented to help implementers
understand the specification, including some of the motivation for
decisions taken by the committee in developing the specification. Some
of the implementation considerations are intended to help implementers
design their client and/or IPP object implementations. If there are any
contradictions between this document and [IPP-MOD] or [IPP-PRO], those
documents take precedence over this document.
1.1 Conformance language
Usually, this document does not contain the terminology MUST, MUST NOT,
MAY, NEED NOT, SHOULD, SHOULD NOT, REQUIRED, and OPTIONAL. However,
when those terms do appear in this document, their intent is to repeat
what the [IPP-MOD] and [IPP-PRO] documents require and allow, rather
than specifying additional conformance requirements. These terms are
defined in section 13 on conformance terminology in [IPP-MOD], most of
which is taken from RFC 2119 [RFC2119].
Implementers should read section 13 in [IPP-MOD] in order to understand
these capitalized words. The words MUST, MUST NOT, and REQUIRED
indicate what implementations are required to support in a client or IPP
object in order to be conformant to [IPP-MOD] and [IPP-PRO]. MAY, NEED
NOT, and OPTIONAL indicate was is merely allowed as an implementer
option. The verbs SHOULD and SHOULD NOT indicate suggested behavior,
but which is not required or disallowed, respectively, in order to
conform to the specification.
Hastings, Manros [page 5]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
1.2 Other terminology
The term "sender" refers to the client that sends a request or an IPP
object that returns a response. The term "receiver" refers to the IPP
object that receives a request and to a client that receives a response.
2 Model and Semantics
This section discusses various aspects of IPP/1.0 Model and Semantics
[IPP-MOD].
2.1 Suggested Operation Processing Steps for IPP Objects
This section suggests the steps and error checks that an IPP object MAY
perform when processing requests and returning responses. An IPP object
MAY perform some or all of the error checks. However, some
implementations MAY choose to be more forgiving than the error checks
shown here, in order to be able to accept requests from non-conforming
clients. Not performing all of these error checks is a so-called
"forgiving" implementation. On the other hand, clients that
successfully submit requests to IPP objects that do perform all the
error checks will be more likely to be able to interoperate with other
IPP object implementations. Thus an implementer of an IPP object needs
to decide whether to be a "forgiving" or a "strict" implementation.
Therefore, the error status codes returned may differ between
implementations. Consequentially, client SHOULD NOT expect exactly the
error code processing described in this section.
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 execute the following steps.
The order of the steps may be rearranged and/or combined, including
making one or multiple passes over the request.
A client MUST supply requests that would pass all of the error checks
indicated here in order to be a conforming client. Therefore, a client
SHOULD supply requests that are conforming, in order to avoid being
rejected by some IPP object implementations.
In the following, processing continues step by step until a "RETURNS the
xxx status code ." statement is encountered. Error returns are
indicated by the verb: "REJECTS". Since clients have difficulty getting
the status code before sending all of the document data in a Print-Job
request, clients SHOULD use the Validate-Job operation before sending
large documents to be printed, in order to validate whether the IPP
Printer will accept the job or not.
It is assumed that security authentication and authorization has already
taken place at a lower layer.
Hastings, Manros [page 6]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
2.1.1Suggested Operation Processing Steps for all Operations
This section is intended to apply to all operations. 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.
2.1.1.1 Validate version number
Every request and every response contains the "version-number"
attribute. The value of this attribute is the major and minor version
number of the syntax and semantics that the client and IPP object is
using, respectively. The "version-number" attribute remains in a fixed
position across all future versions so that all clients and IPP object
that support future versions can determine which version is being used.
The IPP object checks to see if the major version number supplied in the
request is supported. If not, the Printer object REJECTS the request
and RETURNS the 'server-error-version-not-supported' status code in the
response. The IPP object returns in the "version-number" response
attribute the major and minor version for the error response. Thus the
client can learn at least one major and minor version that the IPP
object supports. The IPP object is encouraged to return the closest
version number to the one supplied by the client.
The checking of the minor version number is implementation dependent,
however if the client supplied minor version is explicitly supported,
the IPP object MUST respond using that identical minor version number.
If the requested minor version is not supported (the requested minor
version is either higher or lower) than a supported minor version, the
IPP object SHOULD return the closest supported minor version.
2.1.1.2 Validate operation identifier
The Printer object checks to see if the "operation-id" attribute
supplied by the client 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.
2.1.1.3 Validate the request identifier
The Printer object SHOULD NOT check to see if the "request-id" attribute
supplied by the client is in range: between 1 and 2**31 - 1 (inclusive),
but copies all 32 bits.
Note: The "version-number", "operation-id", and the "request-id"
parameters are in fixed octet positions in the IPP/1.0 encoding. The
"version-number" parameter will be the same fixed octet position in all
versions of the protocol. These fields are validated before proceeding
with the rest of the validation.
Hastings, Manros [page 7]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
2.1.1.4 Validate attribute group and attribute presence and order
The order of the following validation steps depends on implementation.
2.1.1.4.1 Validate the presence and order of attribute groups
Client requests and IPP object responses contain attribute groups that
Section 3 requires to be present and in a specified order. An IPP
object verifies that the attribute groups are present and in the correct
order in requests supplied by clients (attribute groups without an * in
the following tables).
If an IPP object receives a request with (1) required attribute groups
missing, or (2) the attributes groups are out of order, or (3) the
groups are repeated, 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 in the Get-Jobs
response.
Since this kind of attribute group 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 in error 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.
2.1.1.4.2 Ignore unknown attribute groups in the expected position
Future attribute groups may be added to the specification at the end of
requests just before the Document Content and at the end of response,
except for the Get-Jobs response, where it maybe there or before the
first job attributes returned. If an IPP object receives an unknown
attribute group in these positions, it ignores the entire group, rather
than returning an error, since that group may be a new group in a later
minor version of the protocol that can be ignored. (If the new
attribute group cannot be ignored without confusing the client, the
major version number would have been increased in the protocol document
and in the request). If the unknown group occurs in a different
position, the IPP object REJECTS the request and RETURNS the 'client-
error-bad-request' status code.
Clients also ignore unknown attribute groups returned in a response.
Note: By validating that requests are in the proper form, IPP objects
force clients to use the proper form which, in turn, increases the
chances that customers will be able to use such clients from multiple
vendors with IPP objects from other vendors.
Hastings, Manros [page 8]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
2.1.1.4.3 Validate the presence of a single occurrence of required
Operation attributes
Client requests and IPP object responses contain Operation attributes
that [IPP-MOD] Section 3 requires to be present. Attributes within a
group may be in any order, except for the ordering of target, charset,
and natural languages attributes. These attributes MUST be first, and
MUST be supplied in the following order: charset, natural language, and
then target. An IPP object verifies that the attributes that Section 4
requires to be supplied by the client have been supplied in the request
(attributes without an * in the following tables). An asterisk (*)
indicates groups and Operation attributes that the client may omit in a
request or an IPP object may omit in a response.
If an IPP object receives a request with required attributes missing or
repeated from a group, the IPP object REJECTS the request and RETURNS
the 'client-error-bad-request' status code. For example, it is an error
for the "attributes-charset" or "attributes-natural-language" attribute
to be omitted in any operation request, or for an Operation attribute to
be supplied in a Job Template group or a Job Template attribute to be
supplied in an Operation Attribute group in a create request. It is
also an error to supply the "attributes-charset" attribute twice.
Since these kinds of attribute errors are most likely to be detected by
a client developer rather than by a customer, the IPP object NEED NOT
return an indication of which attribute was in error in either the
Unsupported Attributes group or the Status Message. Also, the IPP
object NEED NOT find all attribute errors before returning this error.
The following tables list all the attributes for all the operations by
attribute group in each request and each response. The order of the
groups is the order that the client supplies the groups as specified in
[IPP-MOD] Section 3. The order of the attributes within a group is
arbitrary, except as noted for some of the special operation attributes
(charset, natural language, and target). The tables below use the
following notation:
R indicates a REQUIRED attribute that an IPP object MUST support
O indicates an OPTIONAL attribute that an IPP object NEED NOT
support
* indicates that a client MAY omit the attribute in a request
and that an IPP object MAY omit the attribute in a
response. The absence of an * means that a client MUST
supply the attribute in a request and an IPP object MUST
supply the attribute in a response.
Operation Requests
The tables below show the attributes in their proper attribute groups
for operation requests:
Note: All operation requests contain "version-number", "operation-id",
and "request-id" parameters.
Hastings, Manros [page 9]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
Hastings, Manros [page 10]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
Print-Job Request:
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
printer-uri (R)
requesting-user-name (R*)
job-name (R*)
ipp-attribute-fidelity (R*)
document-name (R*)
document-format (R*)
document-natural-language (O*)
compression (O*)
job-k-octets (O*)
job-impressions (O*)
job-media-sheets (O*)
Group 2: Job Template Attributes (R*)
<Job Template attributes> (O*)
(see [IPP-MOD] Section 4.2)
Group 3: Document Content (R)
<document content>
Validate-Job Request:
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
printer-uri (R)
requesting-user-name (R*)
job-name (R*)
ipp-attribute-fidelity (R*)
document-name (R*)
document-format (R*)
document-natural-language (O*)
compression (O*)
job-k-octets (O*)
job-impressions (O*)
job-media-sheets (O*)
Group 2: Job Template Attributes (R*)
<Job Template attributes> (O*)
(see [IPP-MOD] Section 4.2)
Create-Job Request:
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
printer-uri (R)
requesting-user-name (R*)
job-name (R*)
ipp-attribute-fidelity (R*)
job-k-octets (O*)
job-impressions (O*)
job-media-sheets (O*)
Group 2: Job Template Attributes (R*)
<Job Template attributes> (O*) (see
(see [IPP-MOD] Section 4.2)
Hastings, Manros [page 11]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
Print-URI Request:
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
printer-uri (R)
document-uri (R)
requesting-user-name (R*)
job-name (R*)
ipp-attribute-fidelity (R*)
document-name (R*)
document-format (R*)
document-natural-language (O*)
compression (O*)
job-k-octets (O*)
job-impressions (O*)
job-media-sheets (O*)
Group 2: Job Template Attributes (R*)
<Job Template attributes> (O*) (see
(see [IPP-MOD] Section 4.2)
Send-Document Request:
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
(printer-uri & job-id) | job-uri (R)
last-document (R)
requesting-user-name (R*)
document-name (R*)
document-format (R*)
document-natural-language (O*)
compression (O*)
Group 2: Document Content (R*)
<document content>
Send-URI Request:
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
(printer-uri & job-id) | job-uri (R)
last-document (R)
document-uri (R)
requesting-user-name (R*)
document-name (R*)
document-format (R*)
document-natural-language (O*)
compression (O*)
Cancel-Job Request:
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
(printer-uri & job-id) | job-uri (R)
requesting-user-name (R*)
Hastings, Manros [page 12]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
message (O*)
Get-Printer-Attributes Request:
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
printer-uri (R)
requesting-user-name (R*)
requested-attributes (R*)
document-format (R*)
Get-Job-Attributes Request:
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
(printer-uri & job-id) | job-uri (R)
requesting-user-name (R*)
requested-attributes (R*)
Get-Jobs Request:
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
printer-uri (R)
requesting-user-name (R*)
limit (R*)
requested-attributes (R*)
which-jobs (R*)
my-jobs (R*)
Operation Responses
The tables below show the response attributes in their proper attribute
groups for responses.
Note: All operation responses contain "version-number", "status-code",
and "request-id" parameters.
Hastings, Manros [page 13]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
Print-Job Response:
Print-URI Response:
Create-Job Response:
Send-Document Response:
Send-URI Response:
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
status-message (O*)
Group 2: Unsupported Attributes (R*) (see Note 3)
<unsupported attributes> (R*)
Group 3: Job Object Attributes(R*) (see Note 2)
job-uri (R)
job-id (R)
job-state (R)
job-state-reasons (O*)
job-state-message (O*)
number-of-intervening-jobs (O*)
Validate-Job Response:
Cancel-Job Response:
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
status-message (O*)
Group 2: Unsupported Attributes (R*) (see Note 3)
<unsupported attributes> (R*)
Note 2 - the Job Object Attributes and Printer Object Attributes are
returned only if the IPP object returns one of the success status codes.
Note 3 - the Unsupported Attributes Group is present only if the client
included some Operation and/or Job Template attributes or values that
the Printer doesn't support whether a success or an error return.
Get-Printer-Attributes Response:
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
status-message (O*)
Group 2: Unsupported Attributes (R*) (see Note 4)
<unsupported attributes> (R*)
Group 3: Printer Object Attributes(R*) (see Note 2)
<requested attributes> (R*)
Note 4 - the Unsupported Attributes Group is present only if the client
included some Operation attributes that the Printer doesn't support
whether a success or an error return.
Hastings, Manros [page 14]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
Get-Job-Attributes Response:
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
status-message (O*)
Group 2: Unsupported Attributes (R*) (see Note 4)
<unsupported attributes> (R*)
Group 3: Job Object Attributes(R*) (see Note 2)
<requested attributes> (R*)
Get-Jobs Response:
Group 1: Operation Attributes (R)
attributes-charset (R)
attributes-natural-language (R)
status-message (O*)
Group 2: Unsupported Attributes (R*) (see Note 4)
<unsupported attributes> (R*)
Group 3: Job Object Attributes(R*) (see Note 2, 5)
<requested attributes> (R*)
Note 5: for the Get-Jobs operation the response contains a separate Job
Object Attributes group 3 to N containing requested-attributes for each
job object in the response.
2.1.1.5 Validate the values of the REQUIRED Operation attributes
An IPP object validates the values supplied by the client of the
REQUIRED Operation attribute 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 following syntactic validation checks of
each Operation attribute value:
a)that the length of each Operation attribute value is correct for
the attribute syntax tag supplied by the client according to
[IPP-MOD] Section 4.1,
b)that the attribute syntax tag is correct for that Operation
attribute according to [IPP-MOD] Section 3,
c)that the value is in the range specified for that Operation
attribute according to [IPP-MOD] Section 3,
d)that multiple values are supplied by the client only for
operation attributes that are multi-valued, i.e., that are
1setOf X according to [IPP-MOD] Section 3.
If any of these checks fail, the IPP object REJECTS the request and
RETURNS the 'client-error-bad-request' or the 'client-error-request-
value-too-long' status code. Since such an error is most likely to be
an error detected by a client developer, rather than by an end-user, the
Hastings, Manros [page 15]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
IPP object NEED NOT return an indication of which attribute had the
error in either the Unsupported Attributes Group or the Status Message.
The description for each of these syntactic checks is explicitly
expressed in the first IF statement in the following table.
In addition, the IPP object checks each Operation attribute value
against some Printer object attribute or some hard-coded value if there
is no "xxx-supported" Printer object attribute defined. If its value is
not among those supported or is not in the range supported, then the IPP
object REJECTS the request and RETURNS the error status code indicated
in the table by the second IF statement. If the value of the Printer
object's "xxx-supported" attribute is 'no-value' (because the system
administrator hasn't configured a value), the check always fails.
-----------------------------------------------
attributes-charset (charset)
IF NOT any single non-empty 'charset' value less than or equal to 63
octets, REJECT/RETURN 'client-error-request-value-too-long'.
IF NOT in the Printer object's "charset-supported" attribute,
REJECT/RETURN "client-error-charset-not-supported".
attributes-natural-language(naturalLanguage)
IF NOT any single non-empty 'naturalLanguage' value less than or
equal to 63 octets, REJECT/RETURN 'client-error-request-value-too-
long'.
ACCEPT the request even if not a member of the set in the Printer
object's "generated-natural-language-supported" attribute.
requesting-user-name
IF NOT any single 'name' value less than or equal to 255 octets,
REJECT/RETURN 'client-error-request-value-too-long'.
IF the IPP object can obtain a better authenticated name, use it
instead.
job-name(name)
IF NOT any single 'name' value less than or equal to 255 octets,
REJECT/RETURN 'client-error-request-value-too-long'.
IF NOT supplied by the client, the Printer object creates a name from
the document-name or document-uri.
document-name (name)
IF NOT any single 'name' value less than or equal to 255 octets,
REJECT/RETURN 'client-error-request-value-too-long'.
ipp-attribute-fidelity (boolean)
IF NOT either a single 'true' or 'false' 'boolean' value equal to 1
octet, REJECT/RETURN 'client-error-bad-request'.
Hastings, Manros [page 16]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
IF NOT supplied by the client, the IPP object assumes the value
'false'.
document-format (mimeMediaType)
IF NOT any single non-empty 'mimeMediaType' value less than or equal
to 255 octets, REJECT/RETURN 'client-error-request-value-too-long'.
IF NOT in the Printer object's "document-format-supported" attribute,
REJECT/RETURN 'client-error-document-format-not-supported'
IF NOT supplied by the client, the IPP object assumes the value of
the Printer object's "document-format-default" attribute.
document-uri (uri)
IF NOT any single non-empty 'uri' value less than or equal to 1023
octets, REJECT/RETURN 'client-error-request-value-too-long'.
IF the URI syntax is not valid, REJECT/RETURN 'client-error-bad-
request'.
IF scheme is NOT in the Printer object's "reference-uri-schemes-
supported" attribute, REJECT/RETURN 'client-error'-uri-scheme-not-
supported'.
last-document (boolean)
IF NOT either a single 'true' or 'false' 'boolean' value equal to 1
octet, REJECT/RETURN 'client-error-bad-request'.
job-id (integer(1:MAX))
IF NOT any single 'integer' value equal to 4 octets AND in the range
1 to MAX, REJECT/RETURN 'client-error-bad-request'.
IF NOT a job-id of an existing Job object, REJECT/RETURN 'client-
error-not-found' or 'client-error-gone' status code, if keep track
of recently deleted jobs.
requested-attributes (1setOf keyword)
IF NOT any number of 'keyword' values less than or equal to 255
octets, REJECT/RETURN 'client-error-request-value-too-long'.
Ignore unsupported values which are the keyword names of unsupported
attributes. Don't bother to copy such requested (unsupported)
attributes to the Unsupported Attribute response group since the
response will not return them.
which-jobs (type2 keyword)
IF NOT a single 'keyword' value less than or equal to 255 octets,
REJECT/RETURN 'client-error-request-value-too-long'.
IF NEITHER 'completed' NOR 'not-completed', copy the attribute and
the unsupported value to the Unsupported Attributes response group
and REJECT/RETURN 'client-error-attributes-or-values-not-
supported'.
Hastings, Manros [page 17]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
Note: a Printer still supports the 'completed' value even if it keeps
no completed/canceled/aborted jobs: by returning no jobs when so
queried.
IF NOT supplied by the client, the IPP object assumes the 'not-
completed' value.
my-jobs (boolean)
IF NOT either a single 'true' or 'false' 'boolean' value equal to 1
octet, REJECT/RETURN 'client-error-bad-request'.
IF NOT supplied by the client, the IPP object assumes the 'false'
value.
limit (integer(1:MAX))
IF NOT any single 'integer' value equal to 4 octets AND in the range
1 to MAX, REJECT/RETURN 'client-error-bad-request'.
IF NOT supplied by the client, the IPP object returns all jobs, no
matter how many.
-----------------------------------------------
2.1.1.6 Validate the values of the OPTIONAL Operation attributes
OPTIONAL Operation attributes are those that an IPP object MAY or MAY
NOT support. An IPP object validates the values of the OPTIONAL
attributes supplied by the client. The IPP object performs the same
syntactic validation checks for each OPTIONAL attribute value as in
Section 2.1.1.5. As in Section 2.1.1.5, if any fail, the IPP object
REJECTS the request and RETURNS the 'client-error-bad-request' or the
'client-error-request-value-too-long' status code.
In addition, the IPP object checks each Operation attribute value
against some Printer attribute or some hard-coded value if there is no
"xxx-supported" Printer attribute defined. If its value is not among
those supported or is not in the range supported, then the IPP object
REJECTS the request and RETURNS the error status code indicated in the
table. If the value of the Printer object's "xxx-supported" attribute
is 'no-value' (because the system administrator hasn't configured a
value), the check always fails.
If the IPP object doesn't recognize/support an attribute, the IPP object
treats the attribute as an unknown or unsupported attribute (see the
last row in the table below).
-----------------------------------------------
document-natural-language (naturalLanguage)
IF NOT any single non-empty 'naturalLanguage' value less than or
equal to 63 octets, REJECT/RETURN 'client-error-request-value-too-
long'.
Hastings, Manros [page 18]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
IF NOT a value that the Printer object supports in document formats,
(no corresponding "xxx-supported" Printer attribute), REJECT/RETURN
'client-error-natural-language-not-supported'.
compression (type3 keyword)
IF NOT any single 'keyword' values less than or equal to 255 octets,
REJECT/RETURN 'client-error-request-value-too-long'.
IF NOT in the Printer object's "compression-supported" attribute,
copy the attribute and the unsupported value to the Unsupported
Attributes response group and REJECT/RETURN 'client-error-
attributes-or-values-not-supported'.
job-k-octets (integer(0:MAX))
IF NOT any single 'integer' value equal to 4 octets,
REJECT/RETURN 'client-error-bad-request'.
IF NOT in the range of the Printer object's "job-k-octets-supported"
attribute, copy the attribute and the unsupported value to the
Unsupported Attributes response group and REJECT/RETURN 'client-
error-attributes-or-values-not-supported'.
job-impressions (integer(0:MAX))
IF NOT any single 'integer' value equal to 4 octets,
REJECT/RETURN 'client-error-bad-request'.
IF NOT in the range of the Printer object's "job-impressions-
supported" attribute, copy the attribute and the unsupported value
to the Unsupported Attributes response group and REJECT/RETURN
'client-error-attributes-or-values-not-supported'.
job-media-sheets (integer(0:MAX))
IF NOT any single 'integer' value equal to 4 octets,
REJECT/RETURN 'client-error-bad-request'.
IF NOT in the range of the Printer object's "job-media-supported"
attribute, copy the attribute and the unsupported value to the
Unsupported Attributes response group and REJECT/RETURN 'client-
error-attributes-or-values-not-supported'.
message (text(127))
IF NOT any single 'text' value less than or equal to 127 octets,
REJECT/RETURN 'client-error-request-value-too-long'.
unknown or unsupported attribute
IF the attribute syntax supplied by the client is supported but the
length is not legal for that attribute syntax, REJECT/RETURN
'client-error-request-value-too-long'.
ELSE copy the attribute and value to the Unsupported Attributes
response group and change the attribute value to the "out-of-band"
'unsupported' value, but otherwise ignore the attribute.
Hastings, Manros [page 19]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
Note: Future Operation attributes may be added to the protocol
specification that may occur anywhere in the specified group. When
the operation is otherwise successful, the IPP object returns the
'successful-ok-ignored-or-substituted-attributes' status code.
Ignoring 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.
This last 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.
(If the new attribute cannot be ignored without performing
unexpectedly, the major version number would have been increased in
the protocol document and in the request). This rule for Operation
attributes is independent of the value of the "ipp-attribute-
fidelity" attribute. For example, if an IPP object doesn't support
the OPTIONAL "job-k-octets" attribute', the IPP object treats "job-k-
octets" as an unknown attribute and only checks the length for the
'integer' attribute syntax supplied by the client. If it is not four
octets, the IPP object REJECTS the request and RETURNS the 'client-
error-bad-request' status code, else the IPP object copies the
attribute to the Unsupported Attribute response group, setting the
value to the "out-of-band" 'unsupported' value, but otherwise ignores
the attribute.
2.1.2Suggested Additional Processing Steps for Operations that
Create/Validate Jobs and Add Documents
This section in combination with the previous section recommends the
processing steps for the Print-Job, Validate-Job, Print-URI, Create-Job,
Send-Document, and Send-URI operations that IPP objects SHOULD use.
These are the operations that create jobs, validate a Print-Job request,
and add documents to a job.
2.1.2.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 not
supplied by the client, the IPP object assumes that the value is
'false'.
2.1.2.2 Check that the Printer object is accepting jobs
If the value of the Printer object's "printer-is-accepting-jobs" is
'false', the Printer object REJECTS the request and RETURNS the 'server-
error-not-accepting-jobs' status code.
2.1.2.3 Validate the values of the Job Template attributes
An IPP object validates the values of all Job Template attribute
supplied by the client. The IPP object performs the analogous syntactic
Hastings, Manros [page 20]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
validation checks of each Job Template attribute value that it performs
for Operation attributes (see Section 2.1.1.5.):
a)that the length of each value is correct for the attribute
syntax tag supplied by the client according to [IPP-MOD] Section
4.1.
b)that the attribute syntax tag is correct for that attribute
according to [IPP-MOD] Sections 4.2 to 4.4.
c)that multiple values are supplied only for multi-valued
attributes, i.e., that are 1setOf X according to [IPP-MOD]
Sections 4.2 to 4.4.
As in Section 2.1.1.5, if any of these syntactic checks fail, the IPP
object REJECTS the request and RETURNS the 'client-error-bad-request' or
'client-error-request-value-too-long' status code as appropriate,
independent of the value of the "ipp-attribute-fidelity". 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. The description for each of these
syntactic checks is explicitly expressed in the first IF statement in
the following table.
In addition, the IPP object loops through all the client-supplied Job
Template attributes, checking to see if the supplied attribute value(s)
are supported or in the range supported, i.e., the value of the "xxx"
attribute in the request is (1) a member of the set of values or is in
the range of values of the Printer' objects "xxx-supported" attribute.
If the value of the Printer object's "xxx-supported" attribute is 'no-
value' (because the system administrator hasn't configured a value), the
check always fails. If the check fails, the IPP object copies the
attribute to the Unsupported Attributes response group with its
unsupported 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 copied. If an IPP object doesn't
recognize/support a Job Template attribute, i.e., there is no
corresponding Printer object "xxx-supported" attribute, the IPP object
treats the attribute as an unknown or unsupported attribute (see the
last row in the table below).
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
using the value of the "document-format" supplied by the client (or
defaulted to the value of the Printer's "document-format-default"
attribute, if not supplied by the client). For example, if "number-up"
is supported for the 'text/plain' document format, but not for the
'application/postscript' document format, the check SHOULD (though it
NEED NOT) depend on the value of the "document-format" operation
attribute. See "document-format" in [IPP-MOD] section 3.2.1.1 and
3.2.5.1.
Hastings, Manros [page 21]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
Note: whether the request is accepted or rejected is determined by the
value of the "ipp-attribute-fidelity" attribute in a subsequent step, so
that all Job Template attribute supplied are examined and all
unsupported attributes and/or values are copied to the Unsupported
Attributes response group.
-----------------------------------------------
job-priority (integer(1:100))
IF NOT a single 'integer' value with a length equal to 4 octets,
REJECT/RETURN 'client-error-bad-request'.
IF NOT supplied by the client, use the value of the Printer object's
"job-priority-default" attribute at job submission time.
IF NOT in the range 1 to 100, inclusive, copy the attribute and the
unsupported value to the Unsupported Attributes response group.
Map the value to the nearest supported value in the range 1:100 as
specified by the number of discrete values indicated by the value
of the Printer's "job-priority-supported" attribute. See the
formula in [IPP-MOD] Section 4.2.1.
job-hold-until (type3 keyword | name)
IF NOT a single 'keyword' or 'name' value with a length less than or
equal to 255 octets, REJECT/RETURN 'client-error-request-value-too-
long'.
IF NOT supplied by the client, use the value of the Printer object's
"job-hold-until" attribute at job submission time.
IF NOT in the Printer object's "job-hold-until-supported" attribute,
copy the attribute and the unsupported value to the Unsupported
Attributes response group.
job-sheets (type3 keyword | name)
IF NOT a single 'keyword' or 'name' value with a length less than or
equal to 255 octets, REJECT/RETURN 'client-error-request-value-too-
long'.
IF NOT in the Printer object's "job-sheets-supported" attribute, copy
the attribute and the unsupported value to the Unsupported
Attributes response group.
multiple-document-handling (type2 keyword)
IF NOT a single 'keyword' value with a length less than or equal to
255 octets, REJECT/RETURN 'client-error-request-value-too-long'.
IF NOT in the Printer object's "multiple-document-handling-supported"
attribute, copy the attribute and the unsupported value to the
Unsupported Attributes response group.
copies (integer(1:MAX))
IF NOT a single 'integer' value with a length equal to 4 octets,
REJECT/RETURN 'client-error-bad-request'.
IF NOT in range of the Printer object's "copies-supported" attribute
Hastings, Manros [page 22]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
copy the attribute and the unsupported value to the Unsupported
Attributes response group.
finishings (1setOf type2 enum)
IF NOT an 'enum' value(s) each with a length equal to 4 octets,
REJECT/RETURN 'client-error-bad-request'.
IF NOT in the Printer object's "finishings-supported" attribute, copy
the attribute and the unsupported value(s), but not any supported
values, to the Unsupported Attributes response group.
page-ranges (1setOf rangeOfInteger(1:MAX))
IF NOT a 'rangeOfInteger' value(s) each with a length equal to 8
octets, REJECT/RETURN 'client-error-bad-request'.
IF first value is greater than second value in any range, the ranges
are not in ascending order, or ranges overlap, REJECT/RETURN
'client-error-bad-request'.
IF the value of the Printer object's "page-ranges-supported"
attribute is 'false', copy the attribute to the Unsupported
Attributes response group and set the value to the "out-of-band"
'unsupported' value.
sides (type2 keyword)
IF NOT a single 'keyword' value with a length less than or equal to
255 octets, REJECT/RETURN 'client-error-request-value-too-long'.
IF NOT in the Printer object's "sides-supported" attribute, copy the
attribute and the unsupported value to the Unsupported Attributes
response group.
number-up (integer(1:MAX))
IF NOT a single 'integer' value with a length equal to 4 octets,
REJECT/RETURN 'client-error-bad-request'.
IF NOT a value or in the range of one of the values of the Printer
object's "number-up-supported" attribute, copy the attribute and
value to the Unsupported Attribute response group.
orientation-requested (type2 enum)
IF NOT a single 'enum' value with a length equal to 4 octets,
REJECT/RETURN 'client-error-bad-request'.
IF NOT in the Printer object's "orientation-requested-supported"
attribute, copy the attribute and the unsupported value to the
Unsupported Attributes response group.
media (type3 keyword | name)
IF NOT a single 'keyword' or 'name' value with a length less than or
equal to 255 octets, REJECT/RETURN 'client-error-request-value-too-
long'.
Hastings, Manros [page 23]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
IF NOT in the Printer object's "media-supported" attribute, copy the
attribute and the unsupported value to the Unsupported Attributes
response group.
printer-resolution (resolution)
IF NOT a single 'resolution' value with a length equal to 9 octets,
REJECT/RETURN 'client-error-bad-request'.
IF NOT in the Printer object's "multiple-document-handling-supported"
attribute, copy the attribute and the unsupported value to the
Unsupported Attributes response group.
print-quality (type2 enum)
IF NOT a single 'enum' value with a length equal to 4 octets,
REJECT/RETURN 'client-error-bad-request'.
IF NOT in the Printer object's "print-quality-supported" attribute,
copy the attribute and the unsupported value to the Unsupported
Attributes response group.
unknown or unsupported attribute (i.e., there is no corresponding
Printer object "xxx-supported" attribute)
IF the attribute syntax supplied by the client is supported but the
length is not legal for that attribute syntax,
REJECT/RETURN 'client-error-bad-request' if the length of the
attribute syntax is fixed or 'client-error-request-value-too-long'
if the length of the attribute syntax is variable.
ELSE copy the attribute and value to the Unsupported Attributes
response group and change the attribute value to the "out-of-band"
'unsupported' value. Any remaining Job Template Attributes are
either unknown or unsupported Job Template attributes and are
validated algorithmically according to their attribute syntax for
proper length (see below).
-----------------------------------------------
If the attribute syntax is supported AND the length check fails, the IPP
object REJECTS the request and RETURNS the 'client-error-bad-request' if
the length of the attribute syntax is fixed or the 'client-error-
request-value-too-long' status code if the length of the attribute
syntax is variable. Otherwise, the IPP object copies the unsupported Job
Template attribute to the Unsupported Attributes response group and
changes the attribute value to the "out-of-band" 'unsupported' value.
The following table shows the length checks for all attribute syntaxes.
In the following table: "<=" means less than or equal, "=" means equal
to:
Hastings, Manros [page 24]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
Name Octet length check for read-write attributes
----------- --------------------------------------------
'textWithLanguage <= 1023 AND 'naturalLanguage' <= 63
'textWithoutLanguage' <= 1023
'nameWithLanguage' <= 255 AND 'naturalLanguage' <= 63
'nameWithoutLanguage' <= 255
'keyword' <= 255
'enum' = 4
'uri' <= 1023
'uriScheme' <= 63
'charset' <= 63
'naturalLanguage' <= 63
'mimeMediaType' <= 255
'octetString' <= 1023
'boolean' = 1
'integer' = 4
'rangeOfInteger' = 8
'dateTime' = 11
'resolution' = 9
'1setOf X'
2.1.2.4 Check for conflicting Job Template attributes values
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.
Note: The decisions made to resolve the conflict (if there is a choice)
is implementation dependent.
2.1.2.5 Decide whether to REJECT the request
If there were any unsupported Job Template attributes or
unsupported/conflicting Job Template 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:
Hastings, Manros [page 25]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
(1) 'client-error-conflicting-attributes' status code, if there were
any conflicts between attributes supplied by the client.
(2) 'client-error-attributes-or-values-not-supported' status code,
otherwise.
Note: Unsupported Operation attributes or values that are returned do
not affect the status returned in this step. If the unsupported
Operation attribute was a serious error, the above already rejected the
request in a previous step. If control gets to this step with
unsupported Operation attributes being returned, they are not serious
errors.
2.1.2.6 For the Validate-Job operation, RETURN one of the success
status codes
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 Job Template attributes or values.
(2) the "successful-ok-conflicting-attributes, if there are any
conflicting Job Template attribute or values.
(3) the "successful-ok-ignored-or-substituted-attributes, if there
are only unsupported Job Template attributes or values.
Note: Unsupported Operation attributes or values that are returned do
not affect the status returned in this step. If the unsupported
Operation attribute was a serious error, the above already rejected the
request in a previous step. If control gets to this step with
unsupported Operation attributes being returned, they are not serious
errors.
2.1.2.7 Create the 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) creates a Job object, assigns a unique value to the job's "job-
uri" and "job-id" attributes, and initializes all of the job's
other supported Job Description attributes.
(2) removes all unsupported attributes from the Job object.
(3) 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).
(4) 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
Hastings, Manros [page 26]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
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-Job-
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-supported" 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 later 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-
supported" 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.
Hastings, Manros [page 27]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
2.1.2.8 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 Job Template attributes or values.
(2) the 'successful-ok-conflicting-attributes' status code, if there
are any conflicting Job Template attribute or values.
(3) the 'successful-ok-ignored-or-substituted-attributes' status
code, if there are only unsupported Job Template attributes or
values.
Note: Unsupported Operation attributes or values that are returned do
not affect the status returned in this step. If the unsupported
Operation attribute was a serious error, the above already rejected the
request in a previous step. If control gets to this step with
unsupported Operation attributes being returned, they are not serious
errors.
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, [IPP-MOD] section 3.2.1.2.
2.1.2.9 Accept appended Document Content
The Printer object accepts the appended Document Content data and either
starts it printing, or spools it for later processing.
2.1.2.10 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-supported" attribute set to
'attempted'), the implementation does its best to see that IPP
attributes take precedence over embedded instructions in the document
data.
2.1.2.11 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.
Hastings, Manros [page 28]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
2.1.2.12 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.
Note: the Printer object SHOULD NOT re-use a "job-uri" or "job-id"
value for a sufficiently long time after a job has been destroyed, so
that stale references kept by clients are less likely to access the
wrong (newer) job.
2.1.2.13 Interaction with "ipp-attribute-fidelity"
Some Printer object implementations may support "ipp-attribute-fidelity"
set to 'true' and "pdl-override-supported" 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-supported", 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".
2.2 Status codes returned by operation
This section lists all status codes once in the first operation (Print-
Job). Then it lists the status codes that are different or specialized
for subsequent operations under each operation.
2.2.1Printer Operations
2.2.1.1 Print-Job
The Printer object MUST return one of the following "status-code" values
for the indicated reason. Whether all of the document data has been
accepted or not before returning the success or error response depends
on implementation. See Section 14 for a more complete description of
each status code.
For the following success status codes, the Job object has been created
and the "job-id", and "job-uri" assigned and returned in the response:
successful-ok: no request attributes were substituted or ignored.
successful-ok-ignored-or-substituted-attributes: some supplied (1)
attributes were ignored or (2) unsupported attribute syntaxes or
values were substituted with supported values or were ignored.
Hastings, Manros [page 29]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
Unsupported attributes, attribute syntaxes, or values MUST be
returned in the Unsupported Attributes group of the response.
successful-ok-conflicting-attributes: some supplied attribute values
conflicted with the values of other supplied attributes and were
either substituted or ignored. Attributes or values which conflict
with other attributes and have been substituted or ignored MUST be
returned in the Unsupported Attributes group of the response as
supplied by the client.
For the following error status codes, no job is created and no "job-id"
or "job-uri" is returned:
client-error-bad-request: The request syntax does not conform to the
specification. The IPP object SHOULD NOT return the "status-
message" operation attributes, if supported, if the "attributes-
charset" in the request has not been processed.
client-error-forbidden: The request is being refused for
authorization or authentication reasons. The implementation
security policy is to not reveal whether the failure is one of
authentication or authorization.
client-error-not-authenticated: Either the request requires
authentication information to be supplied or the authentication
information is not sufficient for authorization.
client-error-not-authorized: The requester is not authorized to
perform the request on the target object.
client-error-not-possible: The request cannot be carried out because
of the state of the system. See also 'server-error-not-accepting-
jobs' status code which MUST take precedence if the Printer
object's "printer-accepting-jobs" attribute is 'false'.
client-error-timeout: not applicable.
client-error-not-found: the target object does not exist.
client-error-gone: the target object no longer exists and no
forwarding address is known.
client-error-request-entity-too-large: the size of the request
and/or print data exceeds the capacity of the IPP Printer to
process it.
client-error-request-value-too-long: the size of request variable
length attribute values, such as 'text' and 'name' attribute
syntaxes, exceed the maximum length specified in [IPP-MOD] for the
attribute and MUST be returned in the Unsupported Attributes Group.
client-error-document-format-not-supported: the document format
supplied is not supported. The "document-format" attribute with
the unsupported value MUST be returned in the Unsupported
Attributes Group. This error SHOULD take precedence over any other
'xxx-not-supported' error, except 'client-error-charset-not-
supported'.
client-error-attributes-or-values-not-supported: one or more
supplied attributes, attribute syntaxes, or values are not
supported and the client supplied the "ipp-attributes-fidelity"
operation attribute with a 'true' value. They MUST be returned in
the Unsupported Attributes Group as explained below.
client-error-uri-scheme-not-supported: not applicable.
client-error-charset-not-supported: the charset supplied in the
"attributes-charset" operation attribute is not supported. The
Hastings, Manros [page 30]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
Printer's "configured-charset" MUST be returned in the response as
the value of the "attributes-charset" operation attribute and used
for any 'text' and 'name' attributes returned in the error
response. This error SHOULD take precedence over any other error,
unless the request syntax is so bad that the client's supplied
"attributes-charset" cannot be determined.
client-error-conflicting-attributes: one or more supplied attribute
values conflicted with each other and the client supplied the "ipp-
attributes-fidelity" operation attribute with a 'true' value. They
MUST be returned in the Unsupported Attributes Group as explained
below.
server-error-internal-error: an unexpected condition prevents the
request from being fulfilled.
server-error-operation-not-supported: not applicable (since Print-
Job is REQUIRED).
server-error-service-unavailable: the service is temporarily
overloaded.
server-error-version-not-supported: the version in the request is
not supported. The "closest" version number supported MUST be
returned in the response.
server-error-device-error: a device error occurred while receiving
or spooling the request or document data or the IPP Printer object
can only accept one job at a time.
server-error-temporary-error: a temporary error such as a buffer
full write error, a memory overflow, or a disk full condition
occurred while receiving the request and/or the document data.
server-error-not-accepting-jobs: the Printer object's "printer-is-
not-accepting-jobs" attribute is 'false'.
server-error-busy: the Printer is too busy processing jobs to accept
another job at this time.
server-error-job-canceled: the job has been canceled by an operator
or the system while the client was transmitting the document data.
2.2.1.2 Print-URI
All of the Print-Job status codes described in Section 3.2.1.2 Print-Job
Response are applicable to Print-URI with the following specializations
and differences. See Section 14 for a more complete description of each
status code.
server-error-uri-scheme-not-supported: the URI scheme supplied in
the "document-uri" operation attribute is not supported and is
returned in the Unsupported Attributes group.
2.2.1.3 Validate-Job
All of the Print-Job status codes described in Section 3.2.1.2 Print-Job
Response are applicable to Validate-Job. See Section 14 for a more
complete description of each status code.
2.2.1.4 Create-Job
All of the Print-Job status codes described in Section 3.2.1.2 Print-Job
Response are applicable to Create-Job with the following specializations
Hastings, Manros [page 31]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
and differences. See Section 14 for a more complete description of each
status code.
server-error-operation-not-supported: the Create-Job operation is
not supported.
2.2.1.5 Get-Printer-Attributes
All of the Print-Job status codes described in Section 3.2.1.2 Print-Job
Response are applicable to the Get-Printer-Attributes operation with the
following specializations and differences. See Section 14 for a more
complete description of each status code.
For the following success status codes, the requested attributes are
returned in Group 3 in the response:
successful-ok: no request attributes were substituted or ignored
(same as Print-Job) and no requested attributes were unsupported.
successful-ok-ignored-or-substituted-attributes: same as Print-Job,
except the "requested-attributes" operation attribute MAY, but NEED
NOT, be returned with the unsupported values.
successful-ok-conflicting-attributes: same as Print-Job.
For the error status codes, Group 3 is returned containing no attributes
or is not returned at all:
client-error-not-possible: Same as Print-Job, in addition the
Printer object is not accepting any requests.
client-error-request-entity-too-large: same as Print-job, except
that no print data is involved.
client-error-attributes-or-values-not-supported: not applicable,
since unsupported operation attributes MUST be ignored and
'successful-ok-ignored-or-substituted-attributes' returned.
client-error-conflicting-attributes: same as Print-Job, except that
"ipp-attribute-fidelity" is not involved.
server-error-operation-not-supported: not applicable (since Get-
Printer-Attributes is REQUIRED).
server-error-device-error: same as Print-Job, except that no
document data is involved.
server-error-temporary-error: same as Print-Job, except that no
document data is involved.
server-error-not-accepting-jobs: not applicable..
server-error-busy: same as Print-Job, except the IPP object is too
busy to accept even query requests.
server-error-job-canceled: not applicable..
2.2.1.6 Get-Jobs
All of the Print-Job status codes described in Section 3.2.1.2 Print-Job
Response are applicable to the Get-Jobs operation with the following
specializations and differences. See Section 14 for a more complete
description of each status code.
For the following success status codes, the requested attributes are
returned in Group 3 in the response:
Hastings, Manros [page 32]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
successful-ok: no request attributes were substituted or ignored
(same as Print-Job) and no requested attributes were unsupported.
successful-ok-ignored-or-substituted-attributes: same as Print-Job,
except the "requested-attributes" operation attribute MAY, but NEED
NOT, be returned with the unsupported values.
successful-ok-conflicting-attributes: same as Print-Job.
For any error status codes, Group 3 is returned containing no attributes
or is not returned at all. The following brief error status code
descriptions contain unique information for use with Get-Jobs operation.
See section 14 for the other error status codes that apply uniformly to
all operations:
client-error-not-possible: Same as Print-Job, in addition the
Printer object is not accepting any requests.
client-error-request-entity-too-large: same as Print-job, except
that no print data is involved.
client-error-document-format-not-supported: not applicable.
client-error-attributes-or-values-not-supported: not applicable,
since unsupported operation attributes MUST be ignored and
'successful-ok-ignored-or-substituted-attributes' returned.
client-error-conflicting-attributes: same as Print-Job, except that
"ipp-attribute-fidelity" is not involved.
server-error-operation-not-supported: not applicable (since Get-Jobs
is REQUIRED).
server-error-device-error: same as Print-Job, except that no
document data is involved.
server-error-temporary-error: same as Print-Job, except that no
document data is involved.
server-error-not-accepting-jobs: not applicable.
server-error-job-canceled: not applicable.
2.2.2Job Operations
2.2.2.1 Send-Document
All of the Print-Job status codes described in Section 3.2.1.2 Print-Job
Response are applicable to the Get-Printer-Attributes operation with the
following specializations and differences. See Section 14 for a more
complete description of each status code.
For the following success status codes, the document has been added to
the specified Job object and the job's "number-of-documents" attribute
has been incremented:
successful-ok: no request attributes were substituted or ignored
(same as Print-Job).
successful-ok-ignored-or-substituted-attributes: same as Print-Job.
successful-ok-conflicting-attributes: same as Print-Job.
For the error status codes, no document has been added to the Job object
and the job's "number-of-documents" attribute has not been incremented:
client-error-not-possible: Same as Print-Job, except that the
Printer's "printer-is-accepting-jobs" attribute is not involved, so
that the client is able to finish submitting a multi-document job
Hastings, Manros [page 33]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
after this attribute has been set to 'true'. Another condition is
that the state of the job precludes Send-Document, i.e., the job
has already been closed out by the client. However, if the IPP
Printer closed out the job due to timeout, the 'client-error-
timeout' error status SHOULD be returned instead.
client-error-timeout: This request was sent after the Printer closed
the job, because it has not received a Send-Document or Send-URI
operation within the Printer's "multiple-operation-time-out" period
.
client-error-request-entity-too-large: same as Print-Job.
client-error-conflicting-attributes: same as Print-Job, except that
"ipp-attributes-fidelity" operation attribute is not involved..
server-error-operation-not-supported: the Send-Document request is
not supported.
server-error-not-accepting-jobs: not applicable.
server-error-job-canceled: the job has been canceled by an operator
or the system while the client was transmitting the data.
2.2.2.2 Send-URI
All of the Print-Job status code descriptions in Section 3.2.1.2 Print-
Job Response with the specializations described for Send-Document are
applicable to Send-URI. See Section 14 for a more complete description
of each status code.
server-error-uri-scheme-not-supported: the URI scheme supplied in
the "document-uri" operation attribute is not supported and the
"document-uri" attribute MUST be returned in the Unsupported
Attributes group.
2.2.2.3 Cancel-Job
All of the Print-Job status codes described in Section 3.2.1.2 Print-Job
Response are applicable to Cancel-Job with the following specializations
and differences. See Section 14 for a more complete description of each
status code.
For the following success status codes, the Job object is being canceled
or has been canceled:
successful-ok: no request attributes were substituted or ignored
(same as Print-Job).
successful-ok-ignored-or-substituted-attributes: same as Print-Job.
successful-ok-conflicting-attributes: same as Print-Job.
For any of the error status codes, the Job object has not been canceled
or was previously canceled.
client-error-not-possible: The request cannot be carried out because
of the state of the Job object ('completed', 'canceled', or
'aborted') or the state of the system.
client-error-not-found: the target Printer and/or Job object does
not exist.
client-error-gone: the target Printer and/or Job object no longer
exists and no forwarding address is known.
Hastings, Manros [page 34]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
client-error-request-entity-too-large: same as Print-Job, except no
document data is involved.
client-error-document-format-not-supported: not applicable.
client-error-attributes-or-values-not-supported: not applicable,
since unsupported operation attributes and values MUST be ignored.
client-error-conflicting-attributes: same as Print-Job, except that
the Printer's "printer-is-accepting-jobs" attribute is not
involved.
server-error-operation-not-supported: not applicable (Cancel-Job is
REQUIRED).
server-error-device-error: same as Print-Job, except no document
data is involved.
server-error-temporary-error: same as Print-Job, except no document
data is involved.
server-error-not-accepting-jobs: not applicable..
server-error-job-canceled: not applicable.
2.2.2.4 Get-Job-Attributes
All of the Print-Job status codes described in Section 3.2.1.2 Print-Job
Response are applicable to Get-Job-Attributes with the following
specializations and differences. See Section 14 for a more complete
description of each status code.
For the following success status codes, the requested attributes are
returned in Group 3 in the response:
successful-ok: no request attributes were substituted or ignored
(same as Print-Job) and no requested attributes were unsupported.
successful-ok-ignored-or-substituted-attributes: same as Print-Job,
except the "requested-attributes" operation attribute MAY, but NEED
NOT, be returned with the unsupported values.
successful-ok-conflicting-attributes: same as Print-Job.
For the error status codes, Group 3 is returned containing no attributes
or is not returned at all.
client-error-not-possible: Same as Print-Job, in addition the
Printer object is not accepting any requests.
client-error-document-format-not-supported: not applicable.
client-error-attributes-or-values-not-supported: not applicable.
client-error-uri-scheme-not-supported: not applicable.
client-error-conflicting-attributes: not applicable
server-error-operation-not-supported: not applicable (since Get-Job-
Attributes is REQUIRED).
server-error-device-error: same as Print-Job, except no document
data is involved.
server-error-temporary-error: sane as Print-Job, except no document
data is involved..
server-error-not-accepting-jobs: not applicable.
server-error-job-canceled: not applicable.
Hastings, Manros [page 35]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
2.3 Validate-Job
The Validate-Job operation has been designed so that its implementation
may be a part of the Print-Job operation. Therefore, requiring
Validate-Job is not a burden on implementers. Also it is useful for
client's to be able to count on its presence in all conformance
implementations, so that the client can determine before sending a long
document, whether the job will be accepted by the IPP Printer or not.
2.4 Case Sensitivity in URIs
IPP client and server implementations must be aware of the diverse
uppercase/lowercase nature of URIs. RFC 2396 defines URL schemes and
Host names as case insensitive but reminds us that the rest of the URL
may well demonstrate case sensitivity. When creating URL's for fields
where the choice is completely arbitrary, it is probably best to select
lower case. However, this cannot be guaranteed and implementations MUST
NOT rely on any fields being case-sensitive or case-insensitive in the
URL beyond the URL scheme and host name fields.
The reason that the IPP specification does not make any restrictions on
URIs, is so that implementations of IPP may use off-the-shelf components
that conform to the standards that define URIs, such as RFC 2396 and the
HTTP/1.1 specifications [RFC2068]. See these specifications for rules
of matching, comparison, and case-sensitivity.
It is also recommended that that System Administrators and
implementations avoid creating URLs for different printers that differ
only in their case. For example, don't have Printer1 and printer1 as
two different IPP Printers.
The HTTP/1.1 specification [RFC2068] contains more details on comparing
URLs.
2.5 Natural Language Override (NLO)
The 'text' and 'name' attributes each have two forms. One has an
implicit natural language, and the other has an explicit natural
language. The 'textWithoutLanguage' and 'textWithoutLanguage' are the
two 'text' forms. The 'nameWithoutLanguage" and 'nameWithLanguage are
the two 'name' forms. If a receiver (IPP object or IPP client) supports
an attribute with attribute syntax 'text', it MUST support both forms in
a request and a response. A sender (IPP client or IPP object) MAY send
either form for any such attribute. When a sender sends a
WithoutLanguage form, the implicit natural language is specified in the
"attributes-natural-language" operation attribute which all senders MUST
include in every request and response.
When a sender sends a WithLanguage form, it MAY be different from the
implicit natural language supplied by the sender or it MAY be the same.
The receiver MUST treat either form equivalently.
Hastings, Manros [page 36]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
There is an implementation decision for senders, whether to always send
the WithLanguage forms or use the WithoutLanguage form when the
attribute's natural language is the same as the request or response.
The former approach makes the sender implementation simpler. The latter
approach is more efficient on the wire and allows inter-working with
non-conforming receivers that fail to support the WithLanguage forms.
As each approach have advantages, the choice is completely up to the
implementer of the sender.
Furthermore, when a client receives a 'text' or 'name' job attribute
that it had previously supplied, that client MUST NOT expect to see the
attribute in the same form, i.e., in the same WithoutLanguage or
WithLanguage form as the client supplied when it created the job. The
IPP object is free to transform the attribute from the WithLanguage form
to the WithoutLanguage form and vice versa, as long as the natural
language is preserved. However, in order to meet this latter
requirement, it is usually simpler for the IPP object implementation to
store the natural language explicitly with the attribute value, i.e., to
store using an internal representation that resembles the WithLanguage
form.
The IPP Printer MUST copy the natural language of a job, i.e., the value
of the "attributes-natural-language" operation attribute supplied by the
client in the create operation, to the Job object as a Job Description
attribute, so that a client is able to query it. In returning a Get-
Job-Attributes response, the IPP object MAY return one of three natural
language values in the response's "attributes-natural-language"
operation attribute: (1) that requested by the requester, (2) the
natural language of the job, or (3) the configured natural language of
the IPP Printer, if the requested language is not supported by the IPP
Printer.
This "attributes-natural-language" Job Description attribute is useful
for an IPP object implementation that prints start sheets in the
language of the user who submitted the job. This same Job Description
attribute is useful to a multi-lingual operator who has to communicate
with different job submitters in different natural languages. This same
Job Description attribute is expected to be used in the future to
generate notification messages in the natural language of the job
submitter.
Early drafts of [IPP-MOD] contained a job-level natural language
override (NLO) for the Get-Jobs response. A job-level (NLO) is an
(unrequested) Job Attribute which then specified the implicit natural
language for any other WithoutLanguage job attributes returned in the
response for that job. Interoperability testing of early
implementations showed that no one was implementing the job-level NLO in
Get-Job responses. So the job-level NLO was eliminated from the Get-
Jobs response. This simplification makes all requests and responses
consistent in that the implicit natural language for any WithoutLanguage
'text' or 'name' form is always supplied in the request's or response's
"attributes-natural-language" operation attribute.
Hastings, Manros [page 37]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
2.6 The "queued-job-count" Printer Description attribute
2.6.1Why is "queued-job-count" RECOMMENDED?
The reason that "queued-job-count" is RECOMMENDED, is that some clients
look at that attribute alone when summarizing the status of a list of
printers, instead of doing a Get-Jobs to determine the number of jobs in
the queue. Implementations that fail to support the "queued-job-count"
will cause that client to display 0 jobs when there are actually queued
jobs.
We would have made it a REQUIRED Printer attribute, but some
implementations had already been completed before the issue was raised,
so making it a SHOULD was a compromise.
2.6.2Is "queued-job-count" a good measure of how busy a printer is?
The "queued-job-count" is not a good measure of how busy the printer is
when there are held jobs. A future registration could be to add a
"held-job-count" (or an "active-job-count") Printer Description
attribute if experience shows that such an attribute (combination) is
needed to quickly indicate how busy a printer really is.
2.7 Sending empty attribute groups
The [IPP-MOD] and [IPP-PRO] specifications RECOMMEND that a sender not
send an empty attribute group in a request or a response. However, they
REQUIRE a receiver to accept an empty attribute group as equivalent to
the omission of that group. So a client SHOULD omit the Job Template
Attributes group entirely in a create operation that is not supplying
any Job Template attributes. Similarly, an IPP object SHOULD omit an
empty Unsupported Attributes group if there are no unsupported
attributes to be returned in a response.
2.8 Returning unsupported attributes in Get-Xxxx responses
The client cannot depend on getting unsupported attributes returned in
the Unsupported Attributes group of Get-Printer-Attributes, Get-Jobs, or
Get-Job-Attributes responses that the client requested, but are not
supported by the IPP object. However, such unsupported requested
attributes will not be returned in the Job Attributes or Printer
Attributes group (since they are unsupported). However, the IPP object
is REQUIRED to return the 'successful-ok-ignored-or-substituted-
attributes' status code, so that the client know that all that was
requested has not been returned.
2.9 Returning job-state in Print-Job response
An IPP client submits a small job via Print-Job. By the time the IPP
printer/print server is putting together a response to the operation,
Hastings, Manros [page 38]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
the job has finished printing and been removed as an object from the
print system. What should the job-state be in the response?
The Model suggests that the Printer return a response before it even
accepts the document content. The Job Object Attributes are returned
only if the IPP object returns one of the success status codes. Then the
job-state would always be "pending" or "pending-held".
This issue comes up for the implementation of an IPP Printer object as a
server that forwards jobs to devices that do not provide job status back
to the server. If the server is reasonably certain that the job
completed successfully, then it should return the job-state as
'completed'. Also the server can keep the job in its "job history" long
after the job is no longer in the device. Then a user could query the
server and see that the job was in the 'completed' state and completed
as specified by the job's "time-at-completed" time which would be the
same as the server submitted the job to the device.
An alternative is for the server to respond to the client before or
while sending the job to the device, instead of waiting until the server
has finished sending the job to the device. In this case, the server
can return the job's state as 'pending' with the 'job-outgoing' value in
the job's "job-state-reasons" attribute.
If the server doesn't know for sure whether the job completed
successfully (or at all), it could return the (out-of-band) 'unknown'
value.
On the other hand, if the server is able to query the device and/or
setup some sort of event notification that the device initiates when the
job makes state transitions, then the server can return the current job
state in the Print-Job response and in subsequent queries because the
server knows what the job state is in the device (or can query the
device).
All of these alternatives depend on implementation of the server and the
device.
2.10Multi-valued attributes
What is the attribute syntax for a multi-valued attribute? Since some
attributes support values in more than one data type, such as "media",
"job-hold-until", and "job-sheets", IPP semantics associate the
attribute syntax with each value, not with the attribute as a whole.
The protocol associates the attribute syntax tag with each value. Don't
be fooled, just because the attribute syntax tag comes before the
attribute keyword. All attribute values after the first have a zero
length attribute keyword as the indication of a subsequent value of the
same attribute.
Hastings, Manros [page 39]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
3 Encoding and Transport
This section discusses various aspects of IPP/1.0 Encoding and Transport
[IPP-PRO].
The IPP layer doesn't have to deal with chunking. In the context of CGI
scripts, the HTTP layer removes any chunking information in the received
data.
A client MUST NOT expect a response from an IPP server until after the
client has sent the entire response. But a client MAY listen for an
error response that an IPP server MAY send before it receives all the
data. In this case a client, if chunking the data, can send a premature
zero-length chunk to end the request before sending all the data. If the
request is blocked for some reason, a client MAY determine the reason by
opening another connection to query the server.
In the following sections, there are a tables of all HTTP headers which
describe their use in an IPP client or server. The following is an
explanation of each column in these tables.
@ the "header" column contains the name of a header
@ the "request/client" column indicates whether a client sends the
header.
@ the "request/ server" column indicates whether a server supports
the header when received.
@ the "response/ server" column indicates whether a server sends the
header.
@ the "response /client" column indicates whether a client supports
the header when received.
@ the "values and conditions" column specifies the allowed header
values and the conditions for the header to be present in a
request/response.
The table for "request headers" does not have columns for responses, and
the table for "response headers" does not have columns for requests.
The following is an explanation of the values in the "request/client"
and "response/ server" columns.
@ must: the client or server MUST send the header,
@ must-if: the client or server MUST send the header when the
condition described in the "values and conditions" column is met,
@ may: the client or server MAY send the header
@ not: the client or server SHOULD NOT send the header. It is not
relevant to an IPP implementation.
The following is an explanation of the values in the "response/client"
and "request/ server" columns.
@ must: the client or server MUST support the header,
@ may: the client or server MAY support the header
@ not: the client or server SHOULD NOT support the header. It is not
relevant to an IPP implementation.
Hastings, Manros [page 40]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
3.1 General Headers
The following is a table for the general headers.
General- Request Response Values and Conditions
Header
Client Server Server Client
Cache- must not must not "no-cache" only
Control
Connection must-if must must- must "close" only. Both
if client and server
SHOULD keep a
connection for the
duration of a sequence
of operations. The
client and server MUST
include this header
for the last operation
in such a sequence.
Date may may must may per RFC 1123 [RFC1123]
from RFC 2068
[RFC2068]
Pragma must not must not "no-cache" only
Transfer- must-if must must- must "chunked" only .
Encoding if Header MUST be present
if Content-Length is
absent.
Upgrade not not not not
Via not not not not
3.2 Request Headers
The following is a table for the request headers.
Request-Header Client Server Request Values and Conditions
Accept may must "application/ipp" only. This
value is the default if the
client omits it
Accept-Charset not not Charset information is within
the application/ipp entity
Accept-Encoding may must empty and per RFC 2068 [RFC2068]
and IANA registry for content-
Hastings, Manros [page 41]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
Request-Header Client Server Request Values and Conditions
codings
Accept-Language not not language information is within
the application/ipp entity
Authorization must-if must per RFC 2068. A client MUST send
this header when it receives a
401 "Unauthorized" response and
does not receive a "Proxy-
Authenticate" header.
>From not not per RFC 2068. Because RFC
recommends sending this header
only with the user's approval, it
is not very useful
Host must must per RFC 2068
If-Match not not
If-Modified- not not
Since
If-None-Match not not
If-Range not not
If-Unmodified- not not
Since
Max-Forwards not not
Proxy- must-if not per RFC 2068. A client MUST send
Authorization this header when it receives a
401 "Unauthorized" response and a
"Proxy-Authenticate" header.
Range not not
Referer not not
User-Agent not not
3.3 Response Headers
The following is a table for the request headers.
Response- Server Client Response Values and Conditions
Header
Hastings, Manros [page 42]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
Response- Server Client Response Values and Conditions
Header
Accept-Ranges not not
Age not not
Location must-if may per RFC 2068. When URI needs
redirection.
Proxy- not must per RFC 2068
Authenticate
Public may may per RFC 2068
Retry-After may may per RFC 2068
Server not not
Vary not not
Warning may may per RFC 2068
WWW- must-if must per RFC 2068. When a server needs to
Authenticate authenticate a client.
3.4 Entity Headers
The following is a table for the entity headers.
Entity-Header Request Response Values and Conditions
Client Server Server Client
Allow not not not not
Content-Base not not not not
Content- may must must must per RFC 2068 and IANA
Encoding registry for content
codings.
Content- not not not not Application/ipp
Language handles language
Content- must-if must must-if must the length of the
Length message-body per RFC
2068. Header MUST be
present if Transfer-
Encoding is absent..
Content- not not not not
Location
Hastings, Manros [page 43]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
Entity-Header Request Response Values and Conditions
Client Server Server Client
Content-MD5 may may may may per RFC 2068
Content-Range not not not not
Content-Type must must must must "application/ipp"
only
ETag not not not not
Expires not not not not
Last-Modified not not not not
3.5 Optional support for HTTP/1.0
IPP implementations consist of an HTTP layer and an IPP layer. In the
following discussion, the term "client" refers to the HTTP client layer
and the term "server" refers to the HTTP server layer. The Encoding and
Transport document [IPP-PRO] requires that HTTP 1.1 MUST be supported by
all clients and all servers. However, a client and/or a server
implementation may choose to also support HTTP 1.0.
@ This option means that a server may choose to communicate with a
(non-conforming) client that only supports HTTP 1.0. In such cases
the server should not use any HTTP 1.1 specific parameters or
features and should respond using HTTP version number 1.0.
@ This option also means that a client may choose to communicate with a
(non-conforming) server that only supports HTTP 1.0. In such cases,
if the server responds with an HTTP 'unsupported version number' to
an HTTP 1.1 request, the client should retry using HTTP version
number 1.0.
3.6 HTTP/1.1 Chunking
Clients MUST anticipate that the HTTP/1.1 server may chunk responses and
MUST accept them in responses. However, a (non-conforming) HTTP client
that is unable to accept chunked responses may attempt to request an
HTTP 1.1 server not to use chunking in its response to an operation by
using the following HTTP header:
TE: identity
This mechanism should not be used by a server to disable a client from
chunking a request, since chunking of document data is an important
feature for clients to send long documents.
Hastings, Manros [page 44]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
4 References
[IPP LPD]
Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between
LPD and IPP Protocols", draft-ietf-ipp-lpd-ipp-map-04.txt, June
1998.
[IPP-MOD]
R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
"Internet Printing Protocol/1.0: Model and Semantics", draft-ietf-
ipp-model-11.txt, November, 1998.
[IPP-PRO]
Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing
Protocol/1.0: Encoding and Transport", draft-ietf-ipp-pro-06.txt,
June, 1998.
[IPP-RAT]
Zilles, S., "Rationale for the Structure and Model and Protocol for
the Internet Printing Protocol", draft-ietf-ipp-rat-03.txt, June,
1998.
[IPP-REQ]
Wright, D., "Design Goals for an Internet Printing Protocol",
draft-ietf-ipp-req-02.txt, June, 1998.
[RFC1123]
Braden, S., "Requirements for Internet Hosts - Application and
Support", RFC 1123, October, 1989.
[RFC2068]
R Fielding, et al, "Hypertext Transfer Protocol . HTTP/1.1" RFC
2068, January 1997.
[rfc2119]
S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119 , March 1997.
[RFC2396]
Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[SSL]
Netscape, The SSL Protocol, Version 3, (Text version 3.02),
November 1996.
4.1 Authors' Address
Thomas N. Hastings
Xerox Corporation
701 Aviation Blvd.
Hastings, Manros [page 45]
Expires May 16, 1999
INTERNET-DRAFT IPP/1.0: Implementer's Guide November 16, 1998
El Segundo, CA 90245
hastings@cp10.es.xerox.com
Carl-Uno Manros
Xerox Corporation
701 Aviation Blvd.
El Segundo, CA 90245
manros@cp10.es.xerox.com
5 Appendix C: Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.
Hastings, Manros [page 46]
Expires May 16, 1999
