draft-ietf-ipp-implementers-guide-00.txt   rfc2639.txt 
INTERNET-DRAFT Network Working Group T. Hastings
draft-ietf-ipp-implementers-guide-00.txt Request for Comments: 2639 C. Manros
T. Hastings Category: Informational Xerox Corporation
Xerox Corporation July 1999
C. Manros
Xerox Corporation
November 16, 1998
Internet Printing Protocol/1.0: Implementer's Guide Internet Printing Protocol/1.0: Implementer's Guide
Copyright (C) The Internet Society (date). All Rights Reserved.
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This memo provides information for the Internet community. It does
documents of the Internet Engineering Task Force (IETF), its areas, and not specify an Internet standard of any kind. Distribution of this
its working groups. Note that other groups may also distribute working memo is unlimited.
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Copyright Notice
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 Copyright (C) The Internet Society (1999). All Rights Reserved.
"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 Abstract
This document is one of a set of documents, which together describe all This document is one of a set of documents, which together describe
aspects of a new Internet Printing Protocol (IPP). IPP is an all aspects of a new Internet Printing Protocol (IPP). IPP is an
application level protocol that can be used for distributed printing application level protocol that can be used for distributed printing
using Internet tools and technologies. This document contains using Internet tools and technologies. This document contains
information that supplements the IPP Model and Semantics [IPP-MOD] and information that supplements the IPP Model and Semantics [RFC2566]
the IPP Transport and Encoding [IPP-PRO] documents. It is intended to and the IPP Transport and Encoding [RFC2565] documents. It is
help implementers understand IPP/1.0 and some of the considerations that intended to help implementers understand IPP/1.0 and some of the
may assist them in the design of their client and/or IPP object considerations that may assist them in the design of their client
implementations. For example, a typical order of processing requests is and/or IPP object implementations. For example, a typical order of
given, including error checking. Motivation for some of the processing requests is given, including error checking. Motivation
specification decisions is also included. for some of the specification decisions is also included.
Expires May 16, 1999 The full set of IPP documents includes:
The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol [IPP-REQ] Design Goals for an Internet Printing Protocol [RFC2567]
Rationale for the Structure and Model and Protocol for the Internet Rationale for the Structure and Model and Protocol for the Internet
Printing Protocol [IPP-RAT] Printing Protocol [RFC2568]
Internet Printing Protocol/1.0: Model and Semantics [IPP-MOD] Internet Printing Protocol/1.0: Model and Semantics [RFC2566]
Internet Printing Protocol/1.0: Encoding and Transport [IPP-PRO] Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]
Mapping between LPD and IPP Protocols [IPP LPD] Mapping between LPD and IPP Protocols [RFC2569]
The document, "Design Goals for an Internet Printing Protocol", takes a The document, "Design Goals for an Internet Printing Protocol", takes
broad look at distributed printing functionality, and it enumerates a broad look at distributed printing functionality, and it enumerates
real-life scenarios that help to clarify the features that need to be real-life scenarios that help to clarify the features that need to be
included in a printing protocol for the Internet. It identifies included in a printing protocol for the Internet. It identifies
requirements for three types of users: end users, operators, and requirements for three types of users: end users, operators, and
administrators. The design goals document calls out a subset of end administrators. The design goals document calls out a subset of end
user requirements that are satisfied in IPP/1.0. Operator and user requirements that are satisfied in IPP/1.0. Operator and
administrator requirements are out of scope for version 1.0. administrator requirements are out of scope for version 1.0.
The document, "Rationale for the Structure and Model and Protocol for The document, "Rationale for the Structure and Model and Protocol for
the Internet Printing Protocol", describes IPP from a high level view, the Internet Printing Protocol", describes IPP from a high level
defines a roadmap for the various documents that form the suite of IPP view, defines a roadmap for the various documents that form the suite
specifications, and gives background and rationale for the IETF working of IPP specifications, and gives background and rationale for the
group's major decisions. IETF working group's major decisions.
The document, "Internet Printing Protocol/1.0: Model and Semantics", The document, "Internet Printing Protocol/1.0: Model and Semantics",
describes a simplified model with abstract objects, their attributes, describes a simplified model with abstract objects, their attributes,
and their operations. The model introduces a Printer and a Job. The and their operations. The model introduces a Printer and a Job. The
Job supports multiple documents per Job. The model document also Job supports multiple documents per Job. The model document also
addresses how security, internationalization, and directory issues are addresses how security, internationalization, and directory issues
addressed. are addressed.
The document, "Internet Printing Protocol/1.0: Encoding and Transport", The document, "Internet Printing Protocol/1.0: Encoding and
is a formal mapping of the abstract operations and attributes defined in Transport", is a formal mapping of the abstract operations and
the model document onto HTTP/1.1. It also defines the encoding rules attributes defined in the model document onto HTTP/1.1. It also
for a new Internet media type called "application/ipp". defines the encoding rules for a new Internet media type called
"application/ipp".
The document, "Mapping between LPD and IPP Protocols", gives some advice The document, "Mapping between LPD and IPP Protocols", gives some
to implementers of gateways between IPP and LPD (Line Printer Daemon) advice to implementers of gateways between IPP and LPD (Line Printer
implementations. Daemon) implementations.
Expires May 16, 1999 Table of Contents
TABLE OF CONTENTS
1 Introduction......................................................5 1 Introduction......................................................4
1.1 Conformance language............................................4
1.2 Other terminology...............................................5
2 Model and Semantics...............................................5
2.1 Summary of Operation Attributes.................................5
2.2 Suggested Operation Processing Steps for IPP Objects ..........10
2.2.1 Suggested Operation Processing Steps for all Operations..11
2.2.1.1 Validate version number...............................11
2.2.1.2 Validate operation identifier.........................11
2.2.1.3 Validate the request identifier.......................11
2.2.1.4 Validate attribute group and attribute presence and
order.................................................12
2.2.1.5 Validate the values of the REQUIRED Operation
attributes............................................19
2.2.1.6 Validate the values of the OPTIONAL Operation
attributes............................................23
2.2.2 Suggested Additional Processing Steps for Operations that
Create/Validate Jobs and Add Documents.....................26
2.2.2.1 Default "ipp-attribute-fidelity" if not supplied......26
2.2.2.2 Check that the Printer object is accepting jobs.......26
2.2.2.3 Validate the values of the Job Template attributes....26
2.2.3 Algorithm for job validation...............................27
2.2.3.1 Check for conflicting Job Template attributes values..33
2.2.3.2 Decide whether to REJECT the request..................33
2.2.3.3 For the Validate-Job operation, RETURN one of the
success status codes..................................34
2.2.3.4 Create the Job object with attributes to support......34
2.2.3.5 Return one of the success status codes................36
2.2.3.6 Accept appended Document Content......................36
2.2.3.7 Scheduling and Starting to Process the Job............36
2.2.3.8 Completing the Job....................................37
2.2.3.9 Destroying the Job after completion...................37
2.2.3.10 Interaction with "ipp-attribute-fidelity".............37
2.3 Status codes returned by operation ............................37
2.3.1 Printer Operations.........................................38
2.3.1.1 Print-Job.............................................38
2.3.1.2 Print-URI.............................................40
2.3.1.3 Validate-Job..........................................40
2.3.1.4 Create-Job............................................41
2.3.1.5 Get-Printer-Attributes................................41
2.3.1.6 Get-Jobs..............................................42
2.3.2 Job Operations.............................................43
2.3.2.1 Send-Document.........................................43
2.3.2.2 Send-URI..............................................44
2.3.2.3 Cancel-Job............................................44
2.3.2.4 Get-Job-Attributes....................................45
2.4 Validate-Job...................................................46
2.5 Case Sensitivity in URIs ......................................46
2.6 Character Sets, natural languages, and internationalization....46
2.6.1 Character set code conversion support .....................46
2.6.2 What charset to return when an unsupported charset is
requested?.................................................48
2.6.3 Natural Language Override (NLO) ...........................48
2.7 The "queued-job-count" Printer Description attribute...........50
2.7.1 Why is "queued-job-count" RECOMMENDED?.....................50
2.7.2 Is "queued-job-count" a good measure of how busy a printer
is?........................................................50
2.8 Sending empty attribute groups ................................50
2.9 Returning unsupported attributes in Get-Xxxx responses ........51
2.10 Returning job-state in Print-Job response ....................51
2.11 Flow controlling the data portion of a Print-Job request .....52
2.12 Multi-valued attributes ......................................53
2.13 Querying jobs with IPP that were submitted using other job
submission protocols .........................................53
2.14 The 'none' value for empty sets ..............................54
2.15 Get-Jobs, my-jobs='true', and 'requesting-user-name'?.........54
2.16 The "multiple-document-handling" Job Template attribute and
support of multiple document jobs.............................54
3 Encoding and Transport...........................................55
3.1 General Headers................................................56
3.2 Request Headers...............................................57
3.3 Response Headers...............................................58
3.4 Entity Headers................................................59
3.5 Optional support for HTTP/1.0..................................60
3.6 HTTP/1.1 Chunking..............................................60
3.6.1 Disabling IPP Server Response Chunking.....................60
3.6.2 Warning About the Support of Chunked Requests..............60
4 References.......................................................61
4.1 Authors' Addresses.............................................62
5 Security Considerations..........................................62
6 Notices..........................................................62
Full Copyright Statement............................................65
1.1 Conformance language...........................................5 1 Introduction
1.2 Other terminology..............................................6 This document contains information that supplements the IPP Model and
Semantics [RFC2566] and the IPP Transport and Encoding [RFC2565]
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 [RFC2566] or
[RFC2565], those documents take precedence over this document.
2 Model and Semantics...............................................6 1.1 Conformance language
2.1 Suggested Operation Processing Steps for IPP Objects...........6 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 [RFC2566] and [RFC2565] documents require and
allow, rather than specifying additional conformance requirements.
These terms are defined in section 13 on conformance terminology in
[RFC2566], most of which is taken from RFC 2119 [RFC2119].
2.1.1 Suggested Operation Processing Steps for all Operations.....7 Implementers should read section 13 in [RFC2566] 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 [RFC2566] and
[RFC2565]. 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.
2.1.1.1 Validate version number.................................7 1.2 Other terminology
2.1.1.2 Validate operation identifier...........................7 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.1.1.3 Validate the request identifier.........................7 2 Model and Semantics
2.1.1.4 Validate attribute group and attribute presence and order8 This section discusses various aspects of IPP/1.0 Model and Semantics
[RFC2566].
2.1.1.5 Validate the values of the REQUIRED Operation attributes15 2.1 Summary of Operation Attributes
2.1.1.6 Validate the values of the OPTIONAL Operation attributes18 Legend for the following table:
2.1.2 Suggested Additional Processing Steps for Operations that R indicates a REQUIRED operation or attribute for an
Create/Validate Jobs and Add Documents...........................20 implementation to support
2.1.2.1 Default "ipp-attribute-fidelity" if not supplied.......20 O indicates an OPTIONAL operation or attribute for an
implementation to support
2.1.2.2 Check that the Printer object is accepting jobs........20 Table 1. Summary of operation attributes for Printer operations
2.1.2.3 Validate the values of the Job Template attributes.....20 Printer Operations
2.1.2.4 Check for conflicting Job Template attributes values...25 Requests Responses
2.1.2.5 Decide whether to REJECT the request...................25 Operation Print- Pri Crea Get- Get- All
Attributes Job, nt- te- Printer- Jobs Opera-
Validate URI Job Attribut tions
-Job (O) (O) es
2.1.2.6 For the Validate-Job operation, RETURN one of the success Operation parameters--REQUIRED to be supplied by the sender
status codes....................................................26
2.1.2.7 Create the Job object with attributes to support.......26 operation-id R R R R R
2.1.2.8 Return one of the success status codes.................28 status-code R
2.1.2.9 Accept appended Document Content.......................28 request-id R R R R R R
2.1.2.10Scheduling and Starting to Process the Job.............28 version-number R R R R R R
2.1.2.11Completing the Job.....................................28 Operation attributes-REQUIRED to be supplied by the sender
2.1.2.12Destroying the Job after completion....................29 attributes-charset R R R R R R
Expires May 16, 1999 attributes- R R R R R R
2.1.2.13Interaction with "ipp-attribute-fidelity"..............29 natural-language
2.2 Status codes returned by operation............................29 document-uri R
2.2.1 Printer Operations.........................................29 job-id*
2.2.1.1 Print-Job..............................................29 job-uri*
2.2.1.2 Print-URI..............................................31 last-document
2.2.1.3 Validate-Job...........................................31 printer-uri R R R R R
2.2.1.4 Create-Job.............................................31 Operation attributes-RECOMMENDED to be supplied by the sender
2.2.1.5 Get-Printer-Attributes.................................32 job-name R R R
2.2.1.6 Get-Jobs...............................................32 requesting-user- R R R R R
name
Printer Operations
2.2.2 Job Operations.............................................33 Requests Responses
2.2.2.1 Send-Document..........................................33 Operation Print- Pri Crea Get- Get- All
Attributes Job, nt- te- Printer Jobs Opera-
Vali- URI Job Attri- tions
date-Job (O) (O) butes
2.2.2.2 Send-URI...............................................34 Operation attributes-OPTIONAL to be supplied by the sender
2.2.2.3 Cancel-Job.............................................34 status-message O
2.2.2.4 Get-Job-Attributes.....................................35 compression O O
2.3 Validate-Job..................................................36 document-format R R O
2.4 Case Sensitivity in URIs......................................36 document-name O O
2.5 Natural Language Override (NLO)...............................36 document-natural- O O
language
2.6 The "queued-job-count" Printer Description attribute..........38 ipp-attribute- R R R
fidelity
2.6.1 Why is "queued-job-count" RECOMMENDED?.....................38 job-impressions O O O
2.6.2 Is "queued-job-count" a good measure of how busy a printer is? job-k-octets O O O
38
2.7 Sending empty attribute groups................................38 job-media-sheets O O O
2.8 Returning unsupported attributes in Get-Xxxx responses........38 limit R
2.9 Returning job-state in Print-Job response.....................38 message
2.10 Multi-valued attributes.....................................39 my-jobs R
3 Encoding and Transport...........................................40 requested- R R
attributes
3.1 General Headers...............................................41 which-jobs R
3.2 Request Headers..............................................41 * "job-id" is REQUIRED only if used together with
"printer-uri" to identify the target job; otherwise, "job-
uri" is REQUIRED.
Expires May 16, 1999 Table 2. Summary of operation attributes for Job operations
3.3 Response Headers..............................................42
3.4 Entity Headers...............................................43 Requests Responses
3.5 Optional support for HTTP/1.0.................................44 Operation Send- Send- Cancel Get- All
Attributes Document URI -Job Job- Opera-
(O) (O) Attri- tions
butes
3.6 HTTP/1.1 Chunking.............................................44 Operation parameters--REQUIRED to be supplied by the sender
4 References.......................................................45 operation-id R R R R
4.1 Authors' Address..............................................45 status-code R
5 Appendix C: Full Copyright Statement.............................46 request-id R R R R R
1 Introduction version-number R R R R R
This document contains information that supplements the IPP Model and Operation attributes-REQUIRED to be supplied by the sender
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 attributes- R R R R R
charset
Usually, this document does not contain the terminology MUST, MUST NOT, attributes- R R R R R
MAY, NEED NOT, SHOULD, SHOULD NOT, REQUIRED, and OPTIONAL. However, natural-language
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 document-uri R
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.
Expires May 16, 1999 job-id* R R R R
1.2 Other terminology
The term "sender" refers to the client that sends a request or an IPP job-uri* R R R R
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 last-document R R
This section discusses various aspects of IPP/1.0 Model and Semantics printer-uri R R R R
[IPP-MOD].
2.1 Suggested Operation Processing Steps for IPP Objects Operation attributes-RECOMMENDED to be supplied by the
sender
This section suggests the steps and error checks that an IPP object MAY job-name
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 requesting-user- R R R R
rejects the request. In order to determine whether or not to accept or name
reject the request, the IPP object SHOULD execute the following steps. Job Operations
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 Requests Responses
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 Operation Attributes Send- Send- Cance Get- All
xxx status code ." statement is encountered. Error returns are Document URI l-Job Job- Opera-
indicated by the verb: "REJECTS". Since clients have difficulty getting (O) (O) Attri- tions
the status code before sending all of the document data in a Print-Job butes
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 Operation attributes.OPTIONAL to be supplied by the sender
taken place at a lower layer.
Expires May 16, 1999 status-message O
2.1.1Suggested Operation Processing Steps for all Operations
This section is intended to apply to all operations. The next section compression O O
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 document-format R R
Every request and every response contains the "version-number" document-name O O
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, document-natural- O O
however if the client supplied minor version is explicitly supported, language
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 ipp-attribute-
fidelity
The Printer object checks to see if the "operation-id" attribute job-impressions
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 job-k-octets
The Printer object SHOULD NOT check to see if the "request-id" attribute job-media-sheets
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" limit
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.
Expires May 16, 1999 message O
2.1.1.4 Validate attribute group and attribute presence and order
The order of the following validation steps depends on implementation. my-jobs
2.1.1.4.1 Validate the presence and order of attribute groups requested-attributes R
Client requests and IPP object responses contain attribute groups that which-jobs
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 * "job-id" is REQUIRED only if used together with "printer-
missing, or (2) the attributes groups are out of order, or (3) the uri" to identify the target job; otherwise, "job-uri" is
groups are repeated, the IPP object REJECTS the request and RETURNS the REQUIRED.
'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 2.2 Suggested Operation Processing Steps for IPP Objects
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 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.
Future attribute groups may be added to the specification at the end of When an IPP object receives a request, the IPP object either accepts
requests just before the Document Content and at the end of response, or rejects the request. In order to determine whether or not to
except for the Get-Jobs response, where it maybe there or before the accept or reject the request, the IPP object SHOULD execute the
first job attributes returned. If an IPP object receives an unknown following steps. The order of the steps may be rearranged and/or
attribute group in these positions, it ignores the entire group, rather combined, including making one or multiple passes over the request.
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. 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 and/or risking
different semantics by different implementations of forgiving
implementations. For example, a forgiving implementation that
accepts multiple occurrences of the same attribute, rather than
rejecting the request might use the first occurrences, while another
might use the last occurrence. Thus such a non-conforming client
would get different results from the two forgiving implementations.
Note: By validating that requests are in the proper form, IPP objects In the following, processing continues step by step until a "RETURNS
force clients to use the proper form which, in turn, increases the the xxx status code ." statement is encountered. Error returns are
chances that customers will be able to use such clients from multiple indicated by the verb: "REJECTS". Since clients have difficulty
vendors with IPP objects from other vendors. 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.
Expires May 16, 1999 It is assumed that security authentication and authorization has
2.1.1.4.3 Validate the presence of a single occurrence of required already taken place at a lower layer.
Operation attributes
Client requests and IPP object responses contain Operation attributes 2.2.1 Suggested Operation Processing Steps for all Operations
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 This section is intended to apply to all operations. The next
repeated from a group, the IPP object REJECTS the request and RETURNS section contains the additional steps for the Print-Job, Validate-
the 'client-error-bad-request' status code. For example, it is an error Job, Print-URI, Create-Job, Send-Document, and Send-URI operations
for the "attributes-charset" or "attributes-natural-language" attribute that create jobs, adds documents, and validates jobs.
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 2.2.1.1 Validate version number
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 Every request and every response contains the "version-number"
attribute group in each request and each response. The order of the attribute. The value of this attribute is the major and minor
groups is the order that the client supplies the groups as specified in version number of the syntax and semantics that the client and IPP
[IPP-MOD] Section 3. The order of the attributes within a group is object is using, respectively. The "version-number" attribute
arbitrary, except as noted for some of the special operation attributes remains in a fixed position across all future versions so that all
(charset, natural language, and target). The tables below use the clients and IPP object that support future versions can determine
following notation: 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.
R indicates a REQUIRED attribute that an IPP object MUST support The checking of the minor version number is implementation dependent,
O indicates an OPTIONAL attribute that an IPP object NEED NOT 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.2.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 "operations-supported" attribute. If not, the Printer
REJECTS the request and returns the 'server-error-operation-not-
supported' status code in the response.
2.2.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.
2.2.1.4 Validate attribute group and attribute presence and order
The order of the following validation steps depends on
implementation.
2.2.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.2.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.
2.2.1.4.3 Validate the presence of a single occurrence of required
Operation attributes
Client requests and IPP object responses contain Operation attributes
that [RFC2566] 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 or in the wrong position, the behavior of
the IPP object is IMPLEMENTATION DEPENDENT. Some of the possible
implementations are:
1.REJECTS the request and RETURNS the 'client-error-bad-request'
status code
2.accepts the request and uses the first occurrence of the
attribute no matter where it is
3.accepts the request and uses the last occurrence of the
attribute no matter where it is
4.accept the request and assume some default value for the missing
attribute
Therefore, client MUST send conforming requests, if they want to
receive the same behavior from all IPP object implementations. 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 [RFC2566] 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 support
* indicates that a client MAY omit the attribute in a request * indicates that a client MAY omit the attribute in a request
and that an IPP object MAY omit the attribute in a and that an IPP object MAY omit the attribute in a
response. The absence of an * means that a client MUST 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 request and an IPP object MUST
supply the attribute in a response. supply the attribute in a response.
Operation Requests Operation Requests
The tables below show the attributes in their proper attribute groups The tables below show the attributes in their proper attribute groups
for operation requests: for operation requests:
Note: All operation requests contain "version-number", "operation-id", Note: All operation requests contain "version-number", "operation-
and "request-id" parameters. id", and "request-id" parameters.
Expires May 16, 1999 Print-Job Request:
Expires May 16, 1999 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 [RFC2566] Section 4.2)
Group 3: Document Content (R)
<document content>
Print-Job Request: Validate-Job Request:
Group 1: Operation Attributes (R) Group 1: Operation Attributes (R)
attributes-charset (R) attributes-charset (R)
attributes-natural-language (R) attributes-natural-language (R)
printer-uri (R) printer-uri (R)
requesting-user-name (R*) requesting-user-name (R*)
job-name (R*) job-name (R*)
ipp-attribute-fidelity (R*) ipp-attribute-fidelity (R*)
document-name (R*) document-name (R*)
document-format (R*) document-format (R*)
document-natural-language (O*) document-natural-language (O*)
compression (O*) compression (O*)
job-k-octets (O*) job-k-octets (O*)
job-impressions (O*) job-impressions (O*)
job-media-sheets (O*) job-media-sheets (O*)
Group 2: Job Template Attributes (R*) Group 2: Job Template Attributes (R*)
<Job Template attributes> (O*) <Job Template attributes> (O*)
(see [IPP-MOD] Section 4.2) (see [RFC2566] Section 4.2)
Group 3: Document Content (R)
<document content>
Validate-Job Request: Create-Job Request:
Group 1: Operation Attributes (R) Group 1: Operation Attributes (R)
attributes-charset (R) attributes-charset (R)
attributes-natural-language (R) attributes-natural-language (R)
printer-uri (R) printer-uri (R)
requesting-user-name (R*) requesting-user-name (R*)
job-name (R*) job-name (R*)
ipp-attribute-fidelity (R*) ipp-attribute-fidelity (R*)
document-name (R*) job-k-octets (O*)
document-format (R*) job-impressions (O*)
document-natural-language (O*) job-media-sheets (O*)
compression (O*) Group 2: Job Template Attributes (R*)
job-k-octets (O*) <Job Template attributes> (O*) (see
job-impressions (O*) (see [RFC2566] Section 4.2)
job-media-sheets (O*)
Group 2: Job Template Attributes (R*)
<Job Template attributes> (O*)
(see [IPP-MOD] Section 4.2)
Create-Job Request: Print-URI Request:
Group 1: Operation Attributes (R) Group 1: Operation Attributes (R)
attributes-charset (R) attributes-charset (R)
attributes-natural-language (R) attributes-natural-language (R)
printer-uri (R) printer-uri (R)
requesting-user-name (R*) document-uri (R)
job-name (R*) requesting-user-name (R*)
ipp-attribute-fidelity (R*) job-name (R*)
job-k-octets (O*) ipp-attribute-fidelity (R*)
job-impressions (O*) document-name (R*)
job-media-sheets (O*) document-format (R*)
Group 2: Job Template Attributes (R*) document-natural-language (O*)
<Job Template attributes> (O*) (see compression (O*)
(see [IPP-MOD] Section 4.2) job-k-octets (O*)
job-impressions (O*)
job-media-sheets (O*)
Group 2: Job Template Attributes (R*)
<Job Template attributes> (O*) (see
(see [RFC2566] Section 4.2)
Expires May 16, 1999 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>
Print-URI Request: Send-URI Request:
Group 1: Operation Attributes (R) Group 1: Operation Attributes (R)
attributes-charset (R) attributes-charset (R)
attributes-natural-language (R) attributes-natural-language (R)
printer-uri (R) (printer-uri & job-id) | job-uri (R)
document-uri (R) last-document (R)
requesting-user-name (R*) document-uri (R)
job-name (R*) requesting-user-name (R*)
ipp-attribute-fidelity (R*) document-name (R*)
document-name (R*) document-format (R*)
document-format (R*) document-natural-language (O*)
document-natural-language (O*) compression (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: Cancel-Job Request:
Group 1: Operation Attributes (R) Group 1: Operation Attributes (R)
attributes-charset (R) attributes-charset (R)
attributes-natural-language (R) attributes-natural-language (R)
(printer-uri & job-id) | job-uri (R) (printer-uri & job-id) | job-uri (R)
last-document (R) requesting-user-name (R*)
requesting-user-name (R*) message (O*)
document-name (R*)
document-format (R*)
document-natural-language (O*)
compression (O*)
Group 2: Document Content (R*)
<document content>
Send-URI Request: Get-Printer-Attributes Request:
Group 1: Operation Attributes (R) Group 1: Operation Attributes (R)
attributes-charset (R) attributes-charset (R)
attributes-natural-language (R) attributes-natural-language (R)
(printer-uri & job-id) | job-uri (R) printer-uri (R)
last-document (R) requesting-user-name (R*)
document-uri (R) requested-attributes (R*)
requesting-user-name (R*) document-format (R*)
document-name (R*)
document-format (R*)
document-natural-language (O*)
compression (O*)
Cancel-Job Request: Get-Job-Attributes Request:
Group 1: Operation Attributes (R) Group 1: Operation Attributes (R)
attributes-charset (R) attributes-charset (R)
attributes-natural-language (R) attributes-natural-language (R)
(printer-uri & job-id) | job-uri (R) (printer-uri & job-id) | job-uri (R)
requesting-user-name (R*) requesting-user-name (R*)
requested-attributes (R*)
Expires May 16, 1999 Get-Jobs Request:
message (O*) 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*)
Get-Printer-Attributes Request: Operation Responses
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: The tables below show the response attributes in their proper
Group 1: Operation Attributes (R) attribute groups for responses.
attributes-charset (R)
attributes-natural-language (R)
(printer-uri & job-id) | job-uri (R)
requesting-user-name (R*)
requested-attributes (R*)
Get-Jobs Request: Note: All operation responses contain "version-number", "status-
Group 1: Operation Attributes (R) code", and "request-id" parameters.
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 Print-Job Response:
Print-URI Response:
Create-Job Response:
The tables below show the response attributes in their proper attribute Send-Document Response:
groups for responses. 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*)
Note: All operation responses contain "version-number", "status-code", Validate-Job Response:
and "request-id" parameters. 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*)
Expires May 16, 1999 Note 2 - the Job Object Attributes and Printer Object Attributes are
Print-Job Response: returned only if the IPP object returns one of the success status
Print-URI Response: codes.
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: Note 3 - the Unsupported Attributes Group is present only if the
Cancel-Job Response: client included some Operation and/or Job Template attributes or
Group 1: Operation Attributes (R) values that the Printer doesn't support whether a success or an error
attributes-charset (R) return.
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 Get-Printer-Attributes Response:
returned only if the IPP object returns one of the success status codes. 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 3 - the Unsupported Attributes Group is present only if the client Note 4 - the Unsupported Attributes Group is present only if the
included some Operation and/or Job Template attributes or values that client included some Operation attributes that the Printer doesn't
the Printer doesn't support whether a success or an error return. support whether a success or an error return.
Get-Printer-Attributes Response: Get-Job-Attributes Response:
Group 1: Operation Attributes (R) Group 1: Operation Attributes (R)
attributes-charset (R) attributes-charset (R)
attributes-natural-language (R) attributes-natural-language (R)
status-message (O*) status-message (O*)
Group 2: Unsupported Attributes (R*) (see Note 4) Group 2: Unsupported Attributes (R*) (see Note 4)
<unsupported attributes> (R*) <unsupported attributes> (R*)
Group 3: Printer Object Attributes(R*) (see Note 2) Group 3: Job Object Attributes(R*) (see Note 2)
<requested attributes> (R*) <requested attributes> (R*)
Note 4 - the Unsupported Attributes Group is present only if the client Get-Jobs Response:
included some Operation attributes that the Printer doesn't support Group 1: Operation Attributes (R)
whether a success or an error return. 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*)
Expires May 16, 1999 Note 5: for the Get-Jobs operation the response contains a separate
Get-Job-Attributes Response: Job Object Attributes group 3 to N containing requested-attributes
Group 1: Operation Attributes (R) for each job object in the response.
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: 2.2.1.5 Validate the values of the REQUIRED Operation attributes
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 An IPP object validates the values supplied by the client of the
Object Attributes group 3 to N containing requested-attributes for each REQUIRED Operation attribute that the IPP object MUST support. The
job object in the response. next section specifies the validation of the values of the OPTIONAL
Operation attributes that IPP objects MAY support.
2.1.1.5 Validate the values of the REQUIRED Operation attributes The IPP object performs the following syntactic validation checks of
each Operation attribute value:
An IPP object validates the values supplied by the client of the a)that the length of each Operation attribute value is correct for
REQUIRED Operation attribute that the IPP object MUST support. The next the attribute syntax tag supplied by the client according to
section specifies the validation of the values of the OPTIONAL Operation [RFC2566] Section 4.1,
attributes that IPP objects MAY support.
The IPP object performs the following syntactic validation checks of b)that the attribute syntax tag is correct for that Operation
each Operation attribute value: attribute according to [RFC2566] Section 3,
a)that the length of each Operation attribute value is correct for c)that the value is in the range specified for that Operation
the attribute syntax tag supplied by the client according to attribute according to [RFC2566] Section 3,
[IPP-MOD] Section 4.1,
b)that the attribute syntax tag is correct for that Operation d)that multiple values are supplied by the client only for
attribute according to [IPP-MOD] Section 3, operation attributes that are multi-valued, i.e., that are
1setOf X according to [RFC2566] Section 3.
c)that the value is in the range specified for that Operation If any of these checks fail, the IPP object REJECTS the request and
attribute according to [IPP-MOD] Section 3, 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 IPP object NEED NOT return an indication of which attribute
had the error in either the Unsupported Attributes Group or the
d)that multiple values are supplied by the client only for Status Message. The description for each of these syntactic checks
operation attributes that are multi-valued, i.e., that are is explicitly expressed in the first IF statement in the following
1setOf X according to [IPP-MOD] Section 3. table.
If any of these checks fail, the IPP object REJECTS the request and In addition, the IPP object checks each Operation attribute value
RETURNS the 'client-error-bad-request' or the 'client-error-request- against some Printer object attribute or some hard-coded value if
value-too-long' status code. Since such an error is most likely to be there is no "xxx-supported" Printer object attribute defined. If its
an error detected by a client developer, rather than by an end-user, the 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.
Expires May 16, 1999 attributes-charset (charset)
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 IF NOT a single non-empty 'charset' value, REJECT/RETURN 'client-
against some Printer object attribute or some hard-coded value if there error-bad-request'.
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.
IF the value length is greater than 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-charset (charset) attributes-natural-language(naturalLanguage)
IF NOT any single non-empty 'charset' value less than or equal to 63 IF NOT a single non-empty 'naturalLanguage' value, REJECT/RETURN
octets, REJECT/RETURN 'client-error-request-value-too-long'. 'client-error-bad-request'.
IF NOT in the Printer object's "charset-supported" attribute, IF the value length is greater than 63 octets, REJECT/RETURN '
REJECT/RETURN "client-error-charset-not-supported". 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. If
the supplied value is not a member of the Printer object's
"generated-natural-language-supported" attribute, use the
Printer object's "natural-language-configured" value.
attributes-natural-language(naturalLanguage) requesting-user-name
IF NOT any single non-empty 'naturalLanguage' value less than or IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-
equal to 63 octets, REJECT/RETURN 'client-error-request-value-too- request'.
long'. IF the value length is greater than 255 octets, REJECT/RETURN
ACCEPT the request even if not a member of the set in the Printer 'client-error-request-value-too-long'.
object's "generated-natural-language-supported" attribute. IF the IPP object can obtain a better authenticated name, use it
instead.
requesting-user-name job-name(name)
IF NOT any single 'name' value less than or equal to 255 octets, IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-
REJECT/RETURN 'client-error-request-value-too-long'. request'.
IF the IPP object can obtain a better authenticated name, use it IF the value length is greater than 255 octets, REJECT/RETURN
instead. '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.
job-name(name) document-name (name)
IF NOT any single 'name' value less than or equal to 255 octets, IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-
REJECT/RETURN 'client-error-request-value-too-long'. request'.
IF NOT supplied by the client, the Printer object creates a name from IF the value length is greater than 255 octets, REJECT/RETURN
the document-name or document-uri. 'client-error-request-value-too-long'.
document-name (name) ipp-attribute-fidelity (boolean)
IF NOT any single 'name' value less than or equal to 255 octets, IF NEITHER a single 'true' NOR a single 'false' 'boolean' value,
REJECT/RETURN 'client-error-request-value-too-long'. REJECT/RETURN 'client-error-bad-request'.
IF the value length is NOT equal to 1 octet, REJECT/RETURN '
client-error-request-value-too-long'
IF NOT supplied by the client, the IPP object assumes the value
'false'.
ipp-attribute-fidelity (boolean) document-format (mimeMediaType)
IF NOT either a single 'true' or 'false' 'boolean' value equal to 1 IF NOT a single non-empty 'mimeMediaType' value, REJECT/RETURN
octet, REJECT/RETURN 'client-error-bad-request'. 'client-error-bad-request'.
IF the value length is greater than 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'
Expires May 16, 1999 IF NOT supplied by the client, the IPP object assumes the value of
the Printer object's "document-format-default" attribute.
IF NOT supplied by the client, the IPP object assumes the value document-uri (uri)
'false'.
document-format (mimeMediaType) IF NOT a single non-empty 'uri' value, REJECT/RETURN 'client-
error-bad-request'.
IF the value length is greater than 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'.
The Printer object MAY check to see if the document exists and is
accessible. If the document is not found or is not accessible,
REJECT/RETURN 'client-error-not found'.
IF NOT any single non-empty 'mimeMediaType' value less than or equal last-document (boolean)
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 NEITHER a single 'true' NOR a single 'false' 'boolean' value,
REJECT/RETURN 'client-error-bad-request'.
IF the value length is NOT equal to 1 octet, REJECT/RETURN '
client-error-request-value-too-long'
IF NOT any single non-empty 'uri' value less than or equal to 1023 job-id (integer(1:MAX))
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 an single 'integer' value equal to 4 octets AND in the
range 1 to MAX, REJECT/RETURN 'client-error-bad-request'.
IF NOT either a single 'true' or 'false' 'boolean' value equal to 1 IF NOT a job-id of an existing Job object, REJECT/RETURN 'client-
octet, REJECT/RETURN 'client-error-bad-request'. error-not-found' or 'client-error-gone' status code, if keep
track of recently deleted jobs.
job-id (integer(1:MAX)) requested-attributes (1setOf keyword)
IF NOT any single 'integer' value equal to 4 octets AND in the range IF NOT one or more 'keyword' values, REJECT/RETURN 'client-error-
1 to MAX, REJECT/RETURN 'client-error-bad-request'. bad-request'.
IF NOT a job-id of an existing Job object, REJECT/RETURN 'client- IF the value length is greater than 255 octets, REJECT/RETURN
error-not-found' or 'client-error-gone' status code, if keep track 'client-error-request-value-too-long'.
of recently deleted jobs. 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.
requested-attributes (1setOf keyword) which-jobs (type2 keyword)
IF NOT any number of 'keyword' values less than or equal to 255 IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
octets, REJECT/RETURN 'client-error-request-value-too-long'. request'.
Ignore unsupported values which are the keyword names of unsupported IF the value length is greater than 255 octets, REJECT/RETURN
attributes. Don't bother to copy such requested (unsupported) 'client-error-request-value-too-long'.
attributes to the Unsupported Attribute response group since the IF NEITHER 'completed' NOR 'not-completed', copy the attribute and
response will not return them. the unsupported value to the Unsupported Attributes response
group and REJECT/RETURN 'client-error-attributes-or-values-
not-supported'.
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.
which-jobs (type2 keyword) my-jobs (boolean)
IF NOT a single 'keyword' value less than or equal to 255 octets, IF NEITHER a single 'true' NOR a single 'false' 'boolean' value,
REJECT/RETURN 'client-error-request-value-too-long'. REJECT/RETURN 'client-error-bad-request'.
IF NEITHER 'completed' NOR 'not-completed', copy the attribute and IF the value length is NOT equal to 1 octet, REJECT/RETURN '
the unsupported value to the Unsupported Attributes response group client-error-request-value-too-long'
and REJECT/RETURN 'client-error-attributes-or-values-not- IF NOT supplied by the client, the IPP object assumes the 'false'
supported'. value.
Expires May 16, 1999 limit (integer(1:MAX))
Note: a Printer still supports the 'completed' value even if it keeps IF NOT a single 'integer' value equal to 4 octets AND in the range
no completed/canceled/aborted jobs: by returning no jobs when so 1 to MAX, REJECT/RETURN 'client-error-bad-request'.
queried. IF NOT supplied by the client, the IPP object returns all jobs, no
IF NOT supplied by the client, the IPP object assumes the 'not- matter how many.
completed' value.
my-jobs (boolean) 2.2.1.6 Validate the values of the OPTIONAL Operation attributes
IF NOT either a single 'true' or 'false' 'boolean' value equal to 1 OPTIONAL Operation attributes are those that an IPP object MAY or MAY
octet, REJECT/RETURN 'client-error-bad-request'. NOT support. An IPP object validates the values of the OPTIONAL
IF NOT supplied by the client, the IPP object assumes the 'false' attributes supplied by the client. The IPP object performs the same
value. syntactic validation checks for each OPTIONAL attribute value as in
Section 2.2.1.5. As in Section 2.2.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.
limit (integer(1:MAX)) 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 NOT any single 'integer' value equal to 4 octets AND in the range If the IPP object doesn't recognize/support an attribute, the IPP
1 to MAX, REJECT/RETURN 'client-error-bad-request'. object treats the attribute as an unknown or unsupported attribute
IF NOT supplied by the client, the IPP object returns all jobs, no (see the last row in the table below).
matter how many.
document-natural-language (naturalLanguage)
2.1.1.6 Validate the values of the OPTIONAL Operation attributes IF NOT a single non-empty 'naturalLanguage' value, REJECT/RETURN '
client-error-bad-request'.
IF the value length is greater than 63 octets, REJECT/RETURN '
client-error-request-value-too-long'.
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'.
OPTIONAL Operation attributes are those that an IPP object MAY or MAY compression (type3 keyword)
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 IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
against some Printer attribute or some hard-coded value if there is no request'.
"xxx-supported" Printer attribute defined. If its value is not among IF the value length is greater than 255 octets, REJECT/RETURN '
those supported or is not in the range supported, then the IPP object client-error-request-value-too-long'.
REJECTS the request and RETURNS the error status code indicated in the IF NOT in the Printer object's "compression-supported" attribute,
table. If the value of the Printer object's "xxx-supported" attribute copy the attribute and the unsupported value to the Unsupported
is 'no-value' (because the system administrator hasn't configured a Attributes response group and REJECT/RETURN 'client-error-
value), the check always fails. attributes-or-values-not-supported'.
If the IPP object doesn't recognize/support an attribute, the IPP object job-k-octets (integer(0:MAX))
treats the attribute as an unknown or unsupported attribute (see the
last row in the table below).
IF NOT a 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'.
document-natural-language (naturalLanguage) job-impressions (integer(0:MAX))
IF NOT any single non-empty 'naturalLanguage' value less than or IF NOT a single 'integer' value equal to 4 octets,
equal to 63 octets, REJECT/RETURN 'client-error-request-value-too- REJECT/RETURN 'client-error-bad-request'.
long'.
Expires May 16, 1999 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'.
IF NOT a value that the Printer object supports in document formats, job-media-sheets (integer(0:MAX))
(no corresponding "xxx-supported" Printer attribute), REJECT/RETURN
'client-error-natural-language-not-supported'.
compression (type3 keyword) IF NOT a 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-sheets-
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'.
IF NOT any single 'keyword' values less than or equal to 255 octets, message (text(127))
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 a single 'text' value, REJECT/RETURN 'client-error-bad-
request'.
IF the value length is greater than 127 octets,
REJECT/RETURN 'client-error-request-value-too-long'.
IF NOT any single 'integer' value equal to 4 octets, unknown or unsupported attribute
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 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.
IF NOT any single 'integer' value equal to 4 octets, Note: Future Operation attributes may be added to the protocol
REJECT/RETURN 'client-error-bad-request'. specification that may occur anywhere in the specified group.
IF NOT in the range of the Printer object's "job-impressions- When the operation is otherwise successful, the IPP object returns
supported" attribute, copy the attribute and the unsupported value the 'successful-ok-ignored-or-substituted-attributes' status code.
to the Unsupported Attributes response group and REJECT/RETURN Ignoring unsupported Operation attributes in all operations is
'client-error-attributes-or-values-not-supported'. 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.
job-media-sheets (integer(0:MAX)) 2.2.2 Suggested Additional Processing Steps for Operations that
Create/Validate Jobs and Add Documents
IF NOT any single 'integer' value equal to 4 octets, This section in combination with the previous section recommends the
REJECT/RETURN 'client-error-bad-request'. processing steps for the Print-Job, Validate-Job, Print-URI, Create-
IF NOT in the range of the Printer object's "job-media-supported" Job, Send-Document, and Send-URI operations that IPP objects SHOULD
attribute, copy the attribute and the unsupported value to the use. These are the operations that create jobs, validate a Print-Job
Unsupported Attributes response group and REJECT/RETURN 'client- request, and add documents to a job.
error-attributes-or-values-not-supported'.
message (text(127)) 2.2.2.1 Default "ipp-attribute-fidelity" if not supplied
IF NOT any single 'text' value less than or equal to 127 octets, The Printer object checks to see if the client supplied an "ipp-
REJECT/RETURN 'client-error-request-value-too-long'. attribute-fidelity" Operation attribute. If the attribute is not
supplied by the client, the IPP object assumes that the value is
'false'.
unknown or unsupported attribute 2.2.2.2 Check that the Printer object is accepting jobs
IF the attribute syntax supplied by the client is supported but the If the value of the Printer object's "printer-is-accepting-jobs" is
length is not legal for that attribute syntax, REJECT/RETURN 'false', the Printer object REJECTS the request and RETURNS the
'client-error-request-value-too-long'. 'server-error-not-accepting-jobs' status code.
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.
Expires May 16, 1999 2.2.2.3 Validate the values of the Job Template attributes
Note: Future Operation attributes may be added to the protocol An IPP object validates the values of all Job Template attribute
specification that may occur anywhere in the specified group. When supplied by the client. The IPP object performs the analogous
the operation is otherwise successful, the IPP object returns the syntactic validation checks of each Job Template attribute value that
'successful-ok-ignored-or-substituted-attributes' status code. it performs for Operation attributes (see Section 2.2.1.5.):
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 a)that the length of each value is correct for the attribute
Create/Validate Jobs and Add Documents syntax tag supplied by the client according to [RFC2566] Section
4.1.
This section in combination with the previous section recommends the b)that the attribute syntax tag is correct for that attribute
processing steps for the Print-Job, Validate-Job, Print-URI, Create-Job, according to [RFC2566] Sections 4.2 to 4.4.
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 c)that multiple values are supplied only for multi-valued
attributes, i.e., that are 1setOf X according to [RFC2566]
Sections 4.2 to 4.4.
The Printer object checks to see if the client supplied an "ipp- As in Section 2.2.1.5, if any of these syntactic checks fail, the IPP
attribute-fidelity" Operation attribute. If the attribute is not object REJECTS the request and RETURNS the 'client-error-bad-request'
supplied by the client, the IPP object assumes that the value is or 'client-error-request-value-too-long' status code as appropriate,
'false'. 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.
2.1.2.2 Check that the Printer object is accepting jobs Each Job Template attribute MUST occur no more than once. If an IPP
Printer receives a create request with multiple occurrences of a Job
Template attribute, it MAY:
If the value of the Printer object's "printer-is-accepting-jobs" is 1.reject the operation and return the 'client-error-bad syntax'
'false', the Printer object REJECTS the request and RETURNS the 'server- error status code
error-not-accepting-jobs' status code.
2.1.2.3 Validate the values of the Job Template attributes 2.accept the operation and use the first occurrence of the
attribute
An IPP object validates the values of all Job Template attribute 3.accept the operation and use the last occurrence of the
supplied by the client. The IPP object performs the analogous syntactic attribute
Expires May 16, 1999 depending on implementation. Therefore, clients MUST NOT supply
validation checks of each Job Template attribute value that it performs multiple occurrences of the same Job Template attribute in the Job
for Operation attributes (see Section 2.1.1.5.): Attributes group in the request.
a)that the length of each value is correct for the attribute 2.2.3 Algorithm for job validation
syntax tag supplied by the client according to [IPP-MOD] Section
4.1.
b)that the attribute syntax tag is correct for that attribute The process of validating a Job-Template attribute "xxx" against a
according to [IPP-MOD] Sections 4.2 to 4.4. Printer attribute "xxx-supported" can use the following validation
algorithm (see section 3.2.1.2 in [RFC2566]).
c)that multiple values are supplied only for multi-valued To validate the value U of Job-Template attribute "xxx" against the
attributes, i.e., that are 1setOf X according to [IPP-MOD] value V of Printer "xxx-supported", perform the following algorithm:
Sections 4.2 to 4.4.
As in Section 2.1.1.5, if any of these syntactic checks fail, the IPP 1.If U is multi-valued, validate each value X of U by performing
object REJECTS the request and RETURNS the 'client-error-bad-request' or the algorithm in Table 3 with each value X. Each validation is
'client-error-request-value-too-long' status code as appropriate, separate from the standpoint of returning unsupported values.
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 Example: If U is "finishings" that the client supplies with
Template attributes, checking to see if the supplied attribute value(s) 'staple', 'bind' values, then X takes on the successive values:
are supported or in the range supported, i.e., the value of the "xxx" 'staple', then 'bind'
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 2.If V is multi-valued, validate X against each Z of V by
and not for others or the values are different for different document performing the algorithm in Table 3 with each value Z. If a
formats, the IPP object SHOULD take that into account in this validation value Z validates, the validation for the attribute value X
using the value of the "document-format" supplied by the client (or succeeds. If it fails, the algorithm is applied to the next
defaulted to the value of the Printer's "document-format-default" value Z of V. If there are no more values Z of V, validation
attribute, if not supplied by the client). For example, if "number-up" fails.
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.
Expires May 16, 1999 Example: If V is "sides-supported" with values: 'one-sided',
Note: whether the request is accepted or rejected is determined by the 'two-sided-long', and 'two-sided-short', then Z takes on the
value of the "ipp-attribute-fidelity" attribute in a subsequent step, so successive values: 'one-sided', 'two-sided-long', and
that all Job Template attribute supplied are examined and all 'two-sided-short'. If the client supplies "sides" with 'two-
unsupported attributes and/or values are copied to the Unsupported sided-long', the first comparison fails ('one-sided' is not
Attributes response group. equal to 'two-sided-long'), the second comparison succeeds
('two-sided-long' is equal to 'two-sided-long"), and the third
comparison ('two-sided-short' with 'two-sided-long') is not even
performed.
3.If both U and V are single-valued, let X be U and Z be V and use
the validation rules in Table 3.
job-priority (integer(1:100)) Table 3 - Rules for validating single values X against Z
IF NOT a single 'integer' value with a length equal to 4 octets, attribute attribute validated if:
REJECT/RETURN 'client-error-bad-request'. syntax of X syntax of Z
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) integer rangeOfInteger X is within the range of
Z
IF NOT a single 'keyword' or 'name' value with a length less than or uri uriScheme the uri scheme in X is
equal to 255 octets, REJECT/RETURN 'client-error-request-value-too- equal to Z
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) any boolean the value of Z is TRUE
IF NOT a single 'keyword' or 'name' value with a length less than or any any X and Z are of the same
equal to 255 octets, REJECT/RETURN 'client-error-request-value-too- type and are equal.
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 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 NOT a single 'keyword' value with a length less than or equal to If some Job Template attributes are supported for some document
255 octets, REJECT/RETURN 'client-error-request-value-too-long'. formats and not for others or the values are different for different
IF NOT in the Printer object's "multiple-document-handling-supported" document formats, the IPP object SHOULD take that into account in
attribute, copy the attribute and the unsupported value to the this validation using the value of the "document-format" supplied by
Unsupported Attributes response group. 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
[RFC2566] section 3.2.1.1 and 3.2.5.1.
copies (integer(1:MAX)) 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.
IF NOT a single 'integer' value with a length equal to 4 octets, job-priority (integer(1:100))
REJECT/RETURN 'client-error-bad-request'.
IF NOT in range of the Printer object's "copies-supported" attribute
Expires May 16, 1999 IF NOT a single 'integer' value with a length equal to 4 octets,
copy the attribute and the unsupported value to the Unsupported REJECT/RETURN 'client-error-bad-request'.
Attributes response group. 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 [RFC2566] Section 4.2.1.
finishings (1setOf type2 enum) job-hold-until (type3 keyword | name)
IF NOT an 'enum' value(s) each with a length equal to 4 octets, IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-
REJECT/RETURN 'client-error-bad-request'. error-bad-request'.
IF NOT in the Printer object's "finishings-supported" attribute, copy IF the value length is greater than 255 octets, REJECT/RETURN
the attribute and the unsupported value(s), but not any supported 'client-error-request-value-too-long'.
values, to the Unsupported Attributes response group. 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.
page-ranges (1setOf rangeOfInteger(1:MAX)) job-sheets (type3 keyword | name)
IF NOT a 'rangeOfInteger' value(s) each with a length equal to 8 IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-
octets, REJECT/RETURN 'client-error-bad-request'. error-bad-request'.
IF first value is greater than second value in any range, the ranges IF the value length is greater than 255 octets, REJECT/RETURN
are not in ascending order, or ranges overlap, REJECT/RETURN 'client-error-request-value-too-long'.
'client-error-bad-request'. IF NOT in the Printer object's "job-sheets-supported" attribute,
IF the value of the Printer object's "page-ranges-supported" copy the attribute and the unsupported value to the Unsupported
attribute is 'false', copy the attribute to the Unsupported Attributes response group.
Attributes response group and set the value to the "out-of-band"
'unsupported' value.
sides (type2 keyword) multiple-document-handling (type2 keyword)
IF NOT a single 'keyword' value with a length less than or equal to IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
255 octets, REJECT/RETURN 'client-error-request-value-too-long'. request'.
IF NOT in the Printer object's "sides-supported" attribute, copy the IF the value length is greater than 255 octets, REJECT/RETURN
attribute and the unsupported value to the Unsupported Attributes 'client-error-request-value-too-long'.
response group. 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.
number-up (integer(1:MAX)) copies (integer(1:MAX))
IF NOT a single 'integer' value with a length equal to 4 octets, IF NOT a single 'integer' value with a length equal to 4 octets,
REJECT/RETURN 'client-error-bad-request'. REJECT/RETURN 'client-error-bad-request'.
IF NOT a value or in the range of one of the values of the Printer IF NOT in range of the Printer object's "copies-supported"
object's "number-up-supported" attribute, copy the attribute and attribute copy the attribute and the unsupported value to the
value to the Unsupported Attribute response group. Unsupported
Attributes response group.
orientation-requested (type2 enum) finishings (1setOf type2 enum)
IF NOT a single 'enum' value with a length equal to 4 octets, IF NOT an 'enum' value(s) each with a length equal to 4 octets,
REJECT/RETURN 'client-error-bad-request'. REJECT/RETURN 'client-error-bad-request'.
IF NOT in the Printer object's "orientation-requested-supported" IF NOT in the Printer object's "finishings-supported" attribute,
attribute, copy the attribute and the unsupported value to the copy the attribute and the unsupported value(s), but not any
Unsupported Attributes response group. supported values, to the Unsupported Attributes response group.
media (type3 keyword | name) page-ranges (1setOf rangeOfInteger(1:MAX))
IF NOT a single 'keyword' or 'name' value with a length less than or IF NOT a 'rangeOfInteger' value(s) each with a length equal to 8
equal to 255 octets, REJECT/RETURN 'client-error-request-value-too- octets, REJECT/RETURN 'client-error-bad-request'.
long'. 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.
Expires May 16, 1999 sides (type2 keyword)
IF NOT in the Printer object's "media-supported" attribute, copy the IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
attribute and the unsupported value to the Unsupported Attributes request'.
response group. IF the value length is greater than 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.
printer-resolution (resolution) number-up (integer(1:MAX))
IF NOT a single 'resolution' value with a length equal to 9 octets, IF NOT a single 'integer' value with a length equal to 4 octets,
REJECT/RETURN 'client-error-bad-request'. REJECT/RETURN 'client-error-bad-request'.
IF NOT in the Printer object's "multiple-document-handling-supported" IF NOT a value or in the range of one of the values of the Printer
attribute, copy the attribute and the unsupported value to the object's "number-up-supported" attribute, copy the attribute
Unsupported Attributes response group. and value to the Unsupported Attribute response group.
print-quality (type2 enum) orientation-requested (type2 enum)
IF NOT a single 'enum' value with a length equal to 4 octets, IF NOT a single 'enum' value with a length equal to 4 octets,
REJECT/RETURN 'client-error-bad-request'. REJECT/RETURN 'client-error-bad-request'.
IF NOT in the Printer object's "print-quality-supported" attribute, IF NOT in the Printer object's "orientation-requested-supported"
copy the attribute and the unsupported value to the Unsupported attribute, copy the attribute and the unsupported value to the
Attributes response group. Unsupported Attributes response group.
unknown or unsupported attribute (i.e., there is no corresponding media (type3 keyword | name)
Printer object "xxx-supported" attribute)
IF the attribute syntax supplied by the client is supported but the IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-
length is not legal for that attribute syntax, error-bad-request'.
REJECT/RETURN 'client-error-bad-request' if the length of the IF the value length is greater than 255 octets, REJECT/RETURN
attribute syntax is fixed or 'client-error-request-value-too-long' 'client-error-request-value-too-long'.
if the length of the attribute syntax is variable. IF NOT in the Printer object's "media-supported" attribute, copy
ELSE copy the attribute and value to the Unsupported Attributes the attribute and the unsupported value to the Unsupported
response group and change the attribute value to the "out-of-band" Attributes response group.
'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).
printer-resolution (resolution)
If the attribute syntax is supported AND the length check fails, the IPP IF NOT a single 'resolution' value with a length equal to 9
object REJECTS the request and RETURNS the 'client-error-bad-request' if octets,
the length of the attribute syntax is fixed or the 'client-error- REJECT/RETURN 'client-error-bad-request'.
request-value-too-long' status code if the length of the attribute IF NOT in the Printer object's "printer-resolution-supported"
syntax is variable. Otherwise, the IPP object copies the unsupported Job attribute, copy the attribute and the unsupported value to the
Template attribute to the Unsupported Attributes response group and Unsupported Attributes response group.
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:
Expires May 16, 1999 print-quality (type2 enum)
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 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.
Once all the Operation and Job Template attributes have been checked unknown or unsupported attribute (i.e., there is no corresponding
individually, the Printer object SHOULD check for any conflicting values Printer object "xxx-supported" attribute)
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) IF the attribute syntax supplied by the client is supported but
is implementation dependent. 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).
2.1.2.5 Decide whether to REJECT the request 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:
If there were any unsupported Job Template attributes or Name Octet length check for read-write attributes
unsupported/conflicting Job Template attribute values and the client ----------- --------------------------------------------
supplied the "ipp-attribute-fidelity" attribute with the 'true' value, 'textWithLanguage <= 1023 AND 'naturalLanguage' <= 63
the Printer object REJECTS the request and return the status code: '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'
Expires May 16, 1999 2.2.3.1 Check for conflicting Job Template attributes values
(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 Once all the Operation and Job Template attributes have been checked
not affect the status returned in this step. If the unsupported individually, the Printer object SHOULD check for any conflicting
Operation attribute was a serious error, the above already rejected the values among all the supported values supplied by the client. For
request in a previous step. If control gets to this step with example, a Printer object might be able to staple and to print on
unsupported Operation attributes being returned, they are not serious transparencies, however due to physical stapling constraints, the
errors. 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.
2.1.2.6 For the Validate-Job operation, RETURN one of the success Note: The decisions made to resolve the conflict (if there is a
status codes choice) is implementation dependent.
If the requested operation is the Validate-Job operation, the Printer 2.2.3.2 Decide whether to REJECT the request
object returns:
(1) the "successful-ok" status code, if there are no unsupported or If there were any unsupported Job Template attributes or
conflicting Job Template attributes or values. unsupported/conflicting Job Template attribute values and the client
(2) the "successful-ok-conflicting-attributes, if there are any supplied the "ipp-attribute-fidelity" attribute with the 'true'
conflicting Job Template attribute or values. value, the Printer object REJECTS the request and return the status
(3) the "successful-ok-ignored-or-substituted-attributes, if there code:
are only unsupported Job Template attributes or values.
Note: Unsupported Operation attributes or values that are returned do (1) 'client-error-conflicting-attributes' status code, if there
not affect the status returned in this step. If the unsupported were any conflicts between attributes supplied by the client.
Operation attribute was a serious error, the above already rejected the (2) 'client-error-attributes-or-values-not-supported' status code,
request in a previous step. If control gets to this step with otherwise.
unsupported Operation attributes being returned, they are not serious
errors.
2.1.2.7 Create the Job object with attributes to support 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.
If "ipp-attribute-fidelity" is set to 'false' (or it was not supplied by 2.2.3.3 For the Validate-Job operation, RETURN one of the success
the client), the Printer object: status codes
(1) creates a Job object, assigns a unique value to the job's "job- If the requested operation is the Validate-Job operation, the Printer
uri" and "job-id" attributes, and initializes all of the job's object returns:
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
Expires May 16, 1999 (1) the "successful-ok" status code, if there are no unsupported
object (so that the normal default behavior at job processing time or conflicting Job Template attributes or values.
will take place for that attribute). (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.
If there were no attributes or values flagged as unsupported, or the Note: Unsupported Operation attributes or values that are returned
value of 'ipp-attribute-fidelity" was 'false', the Printer object is do not affect the status returned in this step. If the unsupported
able to accept the create request and create a new Job object. If the Operation attribute was a serious error, the above already rejected
"ipp-attribute-fidelity" attribute is set to 'true', the Job Template the request in a previous step. If control gets to this step with
attributes that populate the new Job object are necessarily all the Job unsupported Operation attributes being returned, they are not serious
Template attributes supplied in the create request. If the "ipp- errors.
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 2.2.3.4 Create the Job object with attributes to support
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 If "ipp-attribute-fidelity" is set to 'false' (or it was not supplied
and has an associated default value set for that attribute. In the case by the client), the Printer object:
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 (1) creates a Job object, assigns a unique value to the job's
the client did not supply were to be used to populate the Job object, "job-uri" and "job-id" attributes, and initializes all of the
then these values would become "override values" rather than defaults. job's other supported Job Description attributes.
If the Printer supports the 'attempted' value of the "pdl-override- (2) removes all unsupported attributes from the Job object.
supported" attribute, then these override values could replace values (3) for each unsupported value, removes either the unsupported
specified within the document data. This is not the intent of the value or substitutes the unsupported attribute value with some
default value mechanism. A default value for an attribute is used only supported value. If an attribute has no values after removing
if the create request did not specify that attribute (or it was ignored unsupported values from it, the attribute is removed from the
when allowed by "ipp-attribute-fidelity" being 'false') and no value was Job object (so that the normal default behavior at job
provided within the content of the document data. 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 object (so that the normal default behavior at
job processing time will take place for that attribute).
If the client does not supply a value for some Job Template attribute, If there were no attributes or values flagged as unsupported, or the
and the Printer does not support that attribute, as far as IPP is value of 'ipp-attribute-fidelity" was 'false', the Printer object is
concerned, the result of processing that Job (with respect to the able to accept the create request and create a new Job object. If
missing attribute) is undefined. 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.
Expires May 16, 1999 Note: All Job Template attributes that are persistently stored with
2.1.2.8 Return one of the success status codes 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.
Once the Job object has been created, the Printer object accepts the There are some cases, where a Printer supports a Job Template
request and returns to the client: 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.
(1) the 'successful-ok' status code, if there are no unsupported or Note: If the default values associated with Job Template attributes
conflicting Job Template attributes or values. that the client did not supply were to be used to populate the Job
(2) the 'successful-ok-conflicting-attributes' status code, if there object, then these values would become "override values" rather than
are any conflicting Job Template attribute or values. defaults. If the Printer supports the 'attempted' value of the
(3) the 'successful-ok-ignored-or-substituted-attributes' status "pdl-override-supported" attribute, then these override values could
code, if there are only unsupported Job Template attributes or replace values specified within the document data. This is not the
values. 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.
Note: Unsupported Operation attributes or values that are returned do If the client does not supply a value for some Job Template
not affect the status returned in this step. If the unsupported attribute, and the Printer does not support that attribute, as far as
Operation attribute was a serious error, the above already rejected the IPP is concerned, the result of processing that Job (with respect to
request in a previous step. If control gets to this step with the missing attribute) is undefined.
unsupported Operation attributes being returned, they are not serious
errors.
The Printer object also returns Job status attributes that indicate the 2.2.3.5 Return one of the success status codes
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 Once the Job object has been created, the Printer object accepts the
request and returns to the client:
The Printer object accepts the appended Document Content data and either (1) the 'successful-ok' status code, if there are no unsupported
starts it printing, or spools it for later processing. 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.
2.1.2.10 Scheduling and Starting to Process the Job 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 uses its own configuration and implementation The Printer object also returns Job status attributes that indicate
specific algorithms for scheduling the Job in the correct processing the initial state of the Job ('pending', 'pending-held', '
order. Once the Printer object begins processing the Job, the Printer processing', etc.), etc. See Print-Job Response, [RFC2566] section
changes the Job's state to 'processing'. If the Printer object supports 3.2.1.2.
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 2.2.3.6 Accept appended Document Content
The Printer object continues to process the Job until it can move the The Printer object accepts the appended Document Content data and
Job into the 'completed' state. If an Cancel-Job operation is received, either starts it printing, or spools it for later processing.
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.
Expires May 16, 1999 2.2.3.7 Scheduling and Starting to Process the Job
2.1.2.12 Destroying the Job after completion
Once the Job moves to the 'completed', 'aborted', or 'canceled' state, The Printer object uses its own configuration and implementation
it is an implementation decision as to when to destroy the Job object specific algorithms for scheduling the Job in the correct processing
and release all associated resources. Once the Job has been destroyed, order. Once the Printer object begins processing the Job, the
the Printer would return either the "client-error-not-found" or "client- Printer changes the Job's state to 'processing'. If the Printer
error-gone" status codes for operations directed at that Job. 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.
Note: the Printer object SHOULD NOT re-use a "job-uri" or "job-id" 2.2.3.8 Completing the Job
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" 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.
Some Printer object implementations may support "ipp-attribute-fidelity" 2.2.3.9 Destroying the Job after completion
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 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.
This section lists all status codes once in the first operation (Print- Note: the Printer object SHOULD NOT re-use a "job-uri" or "job-id"
Job). Then it lists the status codes that are different or specialized value for a sufficiently long time after a job has been destroyed, so
for subsequent operations under each operation. that stale references kept by clients are less likely to access the
wrong (newer) job.
2.2.1Printer Operations 2.2.3.10 Interaction with "ipp-attribute-fidelity"
2.2.1.1 Print-Job 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".
The Printer object MUST return one of the following "status-code" values 2.3 Status codes returned by operation
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 This section lists all status codes once in the first operation
and the "job-id", and "job-uri" assigned and returned in the response: (Print-Job). Then it lists the status codes that are different or
specialized for subsequent operations under each operation.
successful-ok: no request attributes were substituted or ignored. 2.3.1 Printer Operations
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.
Expires May 16, 1999 2.3.1.1 Print-Job
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" The Printer object MUST return one of the following "status-code"
or "job-uri" is returned: 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.
client-error-bad-request: The request syntax does not conform to the For the following success status codes, the Job object has been
specification. The IPP object SHOULD NOT return the "status- created and the "job-id", and "job-uri" assigned and returned in the
message" operation attributes, if supported, if the "attributes- response:
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
Expires May 16, 1999 successful-ok: no request attributes were substituted or ignored.
Printer's "configured-charset" MUST be returned in the response as successful-ok-ignored-or-substituted-attributes: some supplied
the value of the "attributes-charset" operation attribute and used (1) attributes were ignored or (2) unsupported attribute
for any 'text' and 'name' attributes returned in the error syntaxes or values were substituted with supported values or
response. This error SHOULD take precedence over any other error, were ignored. Unsupported attributes, attribute syntaxes, or
unless the request syntax is so bad that the client's supplied values MUST be returned in the Unsupported Attributes group of
"attributes-charset" cannot be determined. the response.
client-error-conflicting-attributes: one or more supplied attribute successful-ok-conflicting-attributes: some supplied attribute
values conflicted with each other and the client supplied the "ipp- values conflicted with the values of other supplied attributes
attributes-fidelity" operation attribute with a 'true' value. They and were either substituted or ignored. Attributes or values
MUST be returned in the Unsupported Attributes Group as explained which conflict with other attributes and have been substituted
below. or ignored MUST be returned in the Unsupported Attributes group
server-error-internal-error: an unexpected condition prevents the of the response as supplied by the client.
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 [RFC2566] section 3.1.6 Operation Status Codes and Messages states:
All of the Print-Job status codes described in Section 3.2.1.2 Print-Job If the Printer object supports the "status-message" operation
Response are applicable to Print-URI with the following specializations attribute, it SHOULD use the REQUIRED 'utf-8' charset to return
and differences. See Section 14 for a more complete description of each a status message for the following error status codes (see
status code. section 14): 'client-error-bad-request', 'client-error-
charset-not-supported', 'server-error-internal-error', '
server-error-operation-not-supported', and 'server-error-
version-not-supported'. In this case, it MUST set the value of
the "attributes-charset" operation attribute to 'utf-8' in the
error response.
server-error-uri-scheme-not-supported: the URI scheme supplied in For the following error status codes, no job is created and no "job-
the "document-uri" operation attribute is not supported and is id" or "job-uri" is returned:
returned in the Unsupported Attributes group.
2.2.1.3 Validate-Job client-error-bad-request: The request syntax does not conform to
the specification.
All of the Print-Job status codes described in Section 3.2.1.2 Print-Job client-error-forbidden: The request is being refused for
Response are applicable to Validate-Job. See Section 14 for a more authorization or authentication reasons. The implementation
complete description of each status code. 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 [RFC2566] 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
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.
2.2.1.4 Create-Job client-error-conflicting-attributes: one or more supplied
attribute va 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.
All of the Print-Job status codes described in Section 3.2.1.2 Print-Job 2.3.1.2 Print-URI
Response are applicable to Create-Job with the following specializations
Expires May 16, 1999 All of the Print-Job status codes described in Section 3.2.1.2
and differences. See Section 14 for a more complete description of each Print-Job Response are applicable to Print-URI with the following
status code. specializations and differences. See Section 14 for a more complete
description of each status code.
server-error-operation-not-supported: the Create-Job operation is server-error-uri-scheme-not-supported: the URI scheme supplied in
not supported. the "document-uri" operation attribute is not supported and is
returned in the Unsupported Attributes group.
2.2.1.5 Get-Printer-Attributes 2.3.1.3 Validate-Job
All of the Print-Job status codes described in Section 3.2.1.2 Print-Job All of the Print-Job status codes described in Section 3.2.1.2
Response are applicable to the Get-Printer-Attributes operation with the Print-Job Response are applicable to Validate-Job. See Section 14
following specializations and differences. See Section 14 for a more for a more complete description of each status code.
complete description of each status code.
For the following success status codes, the requested attributes are 2.3.1.4 Create-Job
returned in Group 3 in the response:
successful-ok: no request attributes were substituted or ignored All of the Print-Job status codes described in Section 3.2.1.2
(same as Print-Job) and no requested attributes were unsupported. Print-Job Response are applicable to Create-Job with the following
successful-ok-ignored-or-substituted-attributes: same as Print-Job, specializations and differences. See Section 14 for a more complete
except the "requested-attributes" operation attribute MAY, but NEED description of each status code.
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 server-error-operation-not-supported: the Create-Job operation is
or is not returned at all: not supported.
client-error-not-possible: Same as Print-Job, in addition the 2.3.1.5 Get-Printer-Attributes
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-Printer-Attributes
operation with the following specializations and differences. See
Section 14 for a more complete description of each status code.
All of the Print-Job status codes described in Section 3.2.1.2 Print-Job For the following success status codes, the requested attributes are
Response are applicable to the Get-Jobs operation with the following returned in Group 3 in the response:
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 successful-ok: no request attributes were substituted or ignored
returned in Group 3 in the response: (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.
Expires May 16, 1999 For the error status codes, Group 3 is returned containing no
successful-ok: no request attributes were substituted or ignored attributes or is not returned at all:
(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 client-error-not-possible: Same as Print-Job, in addition the
or is not returned at all. The following brief error status code Printer object is not accepting any requests.
descriptions contain unique information for use with Get-Jobs operation. client-error-request-entity-too-large: same as Print-job, except
See section 14 for the other error status codes that apply uniformly to that no print data is involved.
all operations: 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.
client-error-not-possible: Same as Print-Job, in addition the server-error-busy: same as Print-Job, except the IPP object is
Printer object is not accepting any requests. too busy to accept even query requests.
client-error-request-entity-too-large: same as Print-job, except server-error-job-canceled: not applicable.
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.3.1.6 Get-Jobs
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-Jobs operation with the
following specializations and differences. See Section 14 for a
more complete description of each status code.
All of the Print-Job status codes described in Section 3.2.1.2 Print-Job For the following success status codes, the requested attributes are
Response are applicable to the Get-Printer-Attributes operation with the returned in Group 3 in the response:
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 successful-ok: no request attributes were substituted or ignored
the specified Job object and the job's "number-of-documents" attribute (same as Print-Job) and no requested attributes were
has been incremented: 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.
successful-ok: no request attributes were substituted or ignored For any error status codes, Group 3 is returned containing no
(same as Print-Job). attributes or is not returned at all. The following brief error
successful-ok-ignored-or-substituted-attributes: same as Print-Job. status code descriptions contain unique information for use with
successful-ok-conflicting-attributes: same as Print-Job. Get-Jobs operation. See section 14 for the other error status codes
that apply uniformly to all operations:
For the error status codes, no document has been added to the Job object client-error-not-possible: Same as Print-Job, in addition the
and the job's "number-of-documents" attribute has not been incremented: 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.
client-error-not-possible: Same as Print-Job, except that the 2.3.2 Job Operations
Printer's "printer-is-accepting-jobs" attribute is not involved, so
that the client is able to finish submitting a multi-document job
Expires May 16, 1999 2.3.2.1 Send-Document
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 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.
All of the Print-Job status code descriptions in Section 3.2.1.2 Print- For the following success status codes, the document has been added
Job Response with the specializations described for Send-Document are to the specified Job object and the job's "number-of-documents"
applicable to Send-URI. See Section 14 for a more complete description attribute has been incremented:
of each status code.
server-error-uri-scheme-not-supported: the URI scheme supplied in successful-ok: no request attributes were substituted or ignored
the "document-uri" operation attribute is not supported and the (same as Print-Job).
"document-uri" attribute MUST be returned in the Unsupported successful-ok-ignored-or-substituted-attributes: same as Print-
Attributes group. Job.
successful-ok-conflicting-attributes: same as Print-Job.
2.2.2.3 Cancel-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:
All of the Print-Job status codes described in Section 3.2.1.2 Print-Job client-error-not-possible: Same as Print-Job, except that the
Response are applicable to Cancel-Job with the following specializations Printer's "printer-is-accepting-jobs" attribute is not
and differences. See Section 14 for a more complete description of each involved, so that the client is able to finish submitting a
status code. multi-document job 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.
For the following success status codes, the Job object is being canceled 2.3.2.2 Send-URI
or has been canceled:
successful-ok: no request attributes were substituted or ignored All of the Print-Job status code descriptions in Section 3.2.1.2
(same as Print-Job). Print-Job Response with the specializations described for Send-
successful-ok-ignored-or-substituted-attributes: same as Print-Job. Document are applicable to Send-URI. See Section 14 for a more
successful-ok-conflicting-attributes: same as Print-Job. complete description of each status code.
For any of the error status codes, the Job object has not been canceled server-error-uri-scheme-not-supported: the URI scheme supplied in
or was previously canceled. the "document-uri" operation attribute is not supported and the
"document-uri" attribute MUST be returned in the Unsupported
Attributes group.
client-error-not-possible: The request cannot be carried out because 2.3.2.3 Cancel-Job
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.
Expires May 16, 1999 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.
client-error-request-entity-too-large: same as Print-Job, except no For the following success status codes, the Job object is being
document data is involved. canceled or has been canceled:
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 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.
All of the Print-Job status codes described in Section 3.2.1.2 Print-Job For any of the error status codes, the Job object has not been
Response are applicable to Get-Job-Attributes with the following canceled or was previously canceled.
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 client-error-not-possible: The request cannot be carried out
returned in Group 3 in the response: 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.
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.
successful-ok: no request attributes were substituted or ignored server-error-operation-not-supported: not applicable (Cancel-Job
(same as Print-Job) and no requested attributes were unsupported. is REQUIRED).
successful-ok-ignored-or-substituted-attributes: same as Print-Job, server-error-device-error: same as Print-Job, except no document
except the "requested-attributes" operation attribute MAY, but NEED data is involved.
NOT, be returned with the unsupported values. server-error-temporary-error: same as Print-Job, except no
successful-ok-conflicting-attributes: same as Print-Job. document data is involved.
server-error-not-accepting-jobs: not applicable.
server-error-job-canceled: not applicable.
For the error status codes, Group 3 is returned containing no attributes 2.3.2.4 Get-Job-Attributes
or is not returned at all.
client-error-not-possible: Same as Print-Job, in addition the All of the Print-Job status codes described in Section 3.2.1.2
Printer object is not accepting any requests. Print-Job Response are applicable to Get-Job-Attributes with the
client-error-document-format-not-supported: not applicable. following specializations and differences. See Section 14 for a more
client-error-attributes-or-values-not-supported: not applicable. complete description of each status code.
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.
Expires May 16, 1999 For the following success status codes, the requested attributes are
returned in Group 3 in the response:
2.3 Validate-Job 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.
The Validate-Job operation has been designed so that its implementation For the error status codes, Group 3 is returned containing no
may be a part of the Print-Job operation. Therefore, requiring attributes or is not returned at all.
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 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.
IPP client and server implementations must be aware of the diverse 2.4 Validate-Job
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 The Validate-Job operation has been designed so that its
URIs, is so that implementations of IPP may use off-the-shelf components implementation may be a part of the Print-Job operation. Therefore,
that conform to the standards that define URIs, such as RFC 2396 and the requiring Validate-Job is not a burden on implementers. Also it is
HTTP/1.1 specifications [RFC2068]. See these specifications for rules useful for client's to be able to count on its presence in all
of matching, comparison, and case-sensitivity. 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.
It is also recommended that that System Administrators and 2.5 Case Sensitivity in URIs
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 IPP client and server implementations must be aware of the diverse
URLs. 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.
2.5 Natural Language Override (NLO) 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.
The 'text' and 'name' attributes each have two forms. One has an It is also recommended that System Administrators and implementations
implicit natural language, and the other has an explicit natural avoid creating URLs for different printers that differ only in their
language. The 'textWithoutLanguage' and 'textWithoutLanguage' are the case. For example, don't have Printer1 and printer1 as two different
two 'text' forms. The 'nameWithoutLanguage" and 'nameWithLanguage are IPP Printers.
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 The HTTP/1.1 specification [RFC2068] contains more details on
implicit natural language supplied by the sender or it MAY be the same. comparing URLs.
The receiver MUST treat either form equivalently.
Expires May 16, 1999 2.6 Character Sets, natural languages, and internationalization
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 This section discusses character set support, natural language
that it had previously supplied, that client MUST NOT expect to see the support and internationalization.
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 2.6.1 Character set code conversion support
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 IPP clients and IPP objects are REQUIRED to support UTF-8. They MAY
for an IPP object implementation that prints start sheets in the support additional charsets. It is RECOMMENDED that an IPP object
language of the user who submitted the job. This same Job Description also support US-ASCII, since many clients support US-ASCII, and
attribute is useful to a multi-lingual operator who has to communicate indicate that UTF-8 and US-ASCII are supported by populating the
with different job submitters in different natural languages. This same Printer's "charset-supported" with 'utf-8' and 'us-ascii' values. An
Job Description attribute is expected to be used in the future to IPP object is required to code covert with as little loss as possible
generate notification messages in the natural language of the job between the charsets that it supports, as indicated in the Printer's
submitter. "charsets-supported" attribute.
Early drafts of [IPP-MOD] contained a job-level natural language How should the server handle the situation where the "attributes-
override (NLO) for the Get-Jobs response. A job-level (NLO) is an charset" of the response itself is "us-ascii", but one or more
(unrequested) Job Attribute which then specified the implicit natural attributes in that response is in the "utf-8" format?
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.
Expires May 16, 1999 Example: Consider a case where a client sends a Print-Job request
2.6 The "queued-job-count" Printer Description attribute with "utf-8" as the value of "attributes-charset" and with the "job-
name" attribute supplied. Later another client submits a Get-Job-
Attribute or Get-Jobs request. This second request contains the
"attributes-charset" with value "us-ascii" and "requested-attributes"
attribute with exactly one value "job-name".
2.6.1Why is "queued-job-count" RECOMMENDED? According to the RFC2566 document (section 3.1.4.2), the value of the
"attributes-charset" for the response of the second request must be
"us-ascii" since that is the charset specified in the request. The
"job-name" value, however, is in "utf-8" format. Should the request
be rejected even though both "utf-8" and "us-ascii" charsets are
supported by the server? or should the "job-name" value be converted
to "us-ascii" and return "successful-ok-conflicting-attributes"
(0x0002) as the status code?
The reason that "queued-job-count" is RECOMMENDED, is that some clients Answer: An IPP object that supports both utf-8 (REQUIRED) and us-
look at that attribute alone when summarizing the status of a list of ascii, the second paragraph of section 3.1.4.2 applies so that the
printers, instead of doing a Get-Jobs to determine the number of jobs in IPP object MUST accept the request, perform code set conversion
the queue. Implementations that fail to support the "queued-job-count" between these two charsets with "the highest fidelity possible" and
will cause that client to display 0 jobs when there are actually queued return 'successful-ok', rather than a warning 'successful-ok-
jobs. conflicting-attributes, or an error. The printer will do the best it
can to convert between each of the character sets that it supports--
even if that means providing a string of question marks because none
of the characters are representable in US ASCII. If it can't perform
such conversion, it MUST NOT advertise us-ascii as a value of its
"attributes-charset-supported" and MUST reject any request that
requests 'us-ascii'.
We would have made it a REQUIRED Printer attribute, but some One IPP object implementation strategy is to convert all request text
implementations had already been completed before the issue was raised, and name values to a Unicode internal representation. This is 16-bit
so making it a SHOULD was a compromise. and virtually universal. Then convert to the specified operation
attributes-charset on output.
2.6.2Is "queued-job-count" a good measure of how busy a printer is? Also it would be smarter for a client to ask for 'utf-8', rather than
'us-ascii' and throw away characters that it doesn't understand,
rather than depending on the code conversion of the IPP object.
The "queued-job-count" is not a good measure of how busy the printer is 2.6.2 What charset to return when an unsupported charset is requested?
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 Section 3.1.4.1 Request Operation attributes was clarified in
November 1998 as follows:
The [IPP-MOD] and [IPP-PRO] specifications RECOMMEND that a sender not All clients and IPP objects MUST support the 'utf-8' charset
send an empty attribute group in a request or a response. However, they [RFC2044] and MAY support additional charsets provided that they
REQUIRE a receiver to accept an empty attribute group as equivalent to are registered with IANA [IANA-CS]. If the Printer object does
the omission of that group. So a client SHOULD omit the Job Template not support the client supplied charset value, the Printer object
Attributes group entirely in a create operation that is not supplying MUST reject the request, set the "attributes-charset" to 'utf-8'
any Job Template attributes. Similarly, an IPP object SHOULD omit an in the response, and return the 'client-error-charset-not-
empty Unsupported Attributes group if there are no unsupported supported' status code and any 'text' or 'name' attributes using
attributes to be returned in a response. the 'utf-8' charset.
2.8 Returning unsupported attributes in Get-Xxxx responses Since the client and IPP object MUST support UTF-8, returning any
text or name attributes in UTF-8 when the client requests a charset
that is not supported should allow the client to display the text or
name.
The client cannot depend on getting unsupported attributes returned in Since such an error is a client error, rather than a user error, the
the Unsupported Attributes group of Get-Printer-Attributes, Get-Jobs, or client should check the status code first so that it can avoid
Get-Job-Attributes responses that the client requested, but are not displaying any other returned 'text' and 'name' attributes that are
supported by the IPP object. However, such unsupported requested not in the charset 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 Furthermore, [RFC2566] section 14.1.4.14 client-error-charset-not-
supported (0x040D) was clarified in November 1998 as follows:
An IPP client submits a small job via Print-Job. By the time the IPP For any operation, if the IPP Printer does not support the charset
printer/print server is putting together a response to the operation, supplied by the client in the "attributes-charset" operation
attribute, the Printer MUST reject the operation and return this
status and any 'text' or 'name' attributes using the 'utf-8'
charset (see Section 3.1.4.1).
Expires May 16, 1999 2.6.3 Natural Language Override (NLO)
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 The 'text' and 'name' attributes each have two forms. One has an
accepts the document content. The Job Object Attributes are returned implicit natural language, and the other has an explicit natural
only if the IPP object returns one of the success status codes. Then the language. The 'textWithoutLanguage' and 'textWithoutLanguage' are
job-state would always be "pending" or "pending-held". 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.
This issue comes up for the implementation of an IPP Printer object as a When a sender sends a WithLanguage form, it MAY be different from the
server that forwards jobs to devices that do not provide job status back implicit natural language supplied by the sender or it MAY be the
to the server. If the server is reasonably certain that the job same. The receiver MUST treat either form equivalently.
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 There is an implementation decision for senders, whether to always
while sending the job to the device, instead of waiting until the server send the WithLanguage forms or use the WithoutLanguage form when the
has finished sending the job to the device. In this case, the server attribute's natural language is the same as the request or response.
can return the job's state as 'pending' with the 'job-outgoing' value in The former approach makes the sender implementation simpler. The
the job's "job-state-reasons" attribute. 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.
If the server doesn't know for sure whether the job completed Furthermore, when a client receives a 'text' or 'name' job attribute
successfully (or at all), it could return the (out-of-band) 'unknown' that it had previously supplied, that client MUST NOT expect to see
value. 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.
On the other hand, if the server is able to query the device and/or The IPP Printer MUST copy the natural language of a job, i.e., the
setup some sort of event notification that the device initiates when the value of the "attributes-natural-language" operation attribute
job makes state transitions, then the server can return the current job supplied by the client in the create operation, to the Job object as
state in the Print-Job response and in subsequent queries because the a Job Description attribute, so that a client is able to query it.
server knows what the job state is in the device (or can query the In returning a Get-Job-Attributes response, the IPP object MAY return
device). 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.
All of these alternatives depend on implementation of the server and the This "attributes-natural-language" Job Description attribute is
device. 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.
2.10Multi-valued attributes Early drafts of [RFC2566] 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.
What is the attribute syntax for a multi-valued attribute? Since some 2.7 The "queued-job-count" Printer Description attribute
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.
Expires May 16, 1999 2.7.1 Why is "queued-job-count" RECOMMENDED?
3 Encoding and Transport
This section discusses various aspects of IPP/1.0 Encoding and Transport The reason that "queued-job-count" is RECOMMENDED, is that some
[IPP-PRO]. 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.
The IPP layer doesn't have to deal with chunking. In the context of CGI We would have made it a REQUIRED Printer attribute, but some
scripts, the HTTP layer removes any chunking information in the received implementations had already been completed before the issue was
data. raised, so making it a SHOULD was a compromise.
A client MUST NOT expect a response from an IPP server until after the 2.7.2 Is "queued-job-count" a good measure of how busy a printer is?
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 The "queued-job-count" is not a good measure of how busy the printer
describe their use in an IPP client or server. The following is an is when there are held jobs. A future registration could be to add a
explanation of each column in these tables. "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.
@ the "header" column contains the name of a header 2.8 Sending empty attribute groups
@ 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 [RFC2566] and [RFC2565] specifications RECOMMEND that a sender
the table for "response headers" does not have columns for requests. 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.
The following is an explanation of the values in the "request/client" The [RFC2565] specification REQUIRES a receiver to be able to receive
and "response/ server" columns. either an empty attribute group or an omitted attribute group and
treat them equivalently. The term "receiver" means an IPP object for
a request and a client for a response. The term "sender' means a
client for a request and an IPP object for a response.
@ must: the client or server MUST send the header, There is an exception to the rule for Get-Jobs when there are no
@ must-if: the client or server MUST send the header when the attributes to be returned. [RFC2565] contains the following
condition described in the "values and conditions" column is met, paragraph:
@ 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" The syntax allows an xxx-attributes-tag to be present when the
and "request/ server" columns. xxx-attribute-sequence that follows is empty. The syntax is
defined this way to allow for the response of Get-Jobs where no
attributes are returned for some job-objects. Although it is
RECOMMENDED that the sender not send an xxx-attributes-tag if
there are no attributes (except in the Get-Jobs response just
mentioned), the receiver MUST be able to decode such syntax.
@ must: the client or server MUST support the header, 2.9 Returning unsupported attributes in Get-Xxxx responses
@ 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.
Expires May 16, 1999 In the Get-Printer-Attributes, Get-Jobs, or Get-Job-Attributes
responses, the client cannot depend on getting unsupported attributes
returned in the Unsupported Attributes group 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).
Furthermore, the IPP object is REQUIRED to return the 'successful-
ok-ignored-or-substituted-attributes' status code, so that the client
knows that not all that was requested has been returned.
3.1 General Headers 2.10 Returning job-state in Print-Job response
The following is a table for the general headers. 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,
the job has finished printing and been removed as an object from the
print system. What should the job-state be in the response?
General- Request Response Values and Conditions The Model suggests that the Printer return a response before it even
Header 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".
Client Server Server Client 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.
Cache- must not must not "no-cache" only An alternative is for the server to respond to the client before or
Control 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.
Connection must-if must must- must "close" only. Both If the server doesn't know for sure whether the job completed
if client and server successfully (or at all), it could return the (out-of-band) 'unknown'
SHOULD keep a value.
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] On the other hand, if the server is able to query the device and/or
from RFC 2068 setup some sort of event notification that the device initiates when
[RFC2068] 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).
Pragma must not must not "no-cache" only All of these alternatives depend on implementation of the server and
the device.
Transfer- must-if must must- must "chunked" only . 2.11 Flow controlling the data portion of a Print-Job request
Encoding if Header MUST be present
if Content-Length is
absent.
Upgrade not not not not A paused printer (or one that is stopped due to paper out or jam or
spool space full or buffer space full, may flow control the data of a
Print-Job operation (at the TCP/IP layer), so that the client is not
able to send all the document data. Consequently, the Printer will
not return a response until the condition is changed.
Via not not not not The Printer should not return a Print-Job response with an error code
in any of these conditions, since either the printer will be resumed
and/or the condition will be freed either by human intervention or as
jobs print.
3.2 Request Headers In writing test scripts to test IPP Printers, the script must also be
written not to expect a response, if the printer has been paused,
until the printer is resumed, in order to work with all possible
implementations.
The following is a table for the request headers. 2.12 Multi-valued attributes
Request-Header Client Server Request Values and Conditions 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.
Accept may must "application/ipp" only. This 2.13 Querying jobs with IPP that were submitted using other job
value is the default if the submission protocols
client omits it
Accept-Charset not not Charset information is within The following clarification was added to [RFC2566] section 8.5:
the application/ipp entity
Accept-Encoding may must empty and per RFC 2068 [RFC2068] 8.5 Queries on jobs submitted using non-IPP protocols
and IANA registry for content-
Expires May 16, 1999 If the device that an IPP Printer is representing is able to
accept jobs using other job submission protocols in addition to
IPP, it is RECOMMEND that such an implementation at least allow
such "foreign" jobs to be queried using Get-Jobs returning "job-
id" and "job-uri" as 'unknown'. Such an implementation NEED NOT
support all of the same IPP job attributes as for IPP jobs. The
IPP object returns the 'unknown' out-of-band value for any
requested attribute of a foreign job that is supported for IPP
jobs, but not for foreign jobs.
Request-Header Client Server Request Values and Conditions It is further RECOMMENDED, that the IPP Printer generate "job-id"
and "job-uri" values for such "foreign jobs", if possible, so that
they may be targets of other IPP operations, such as Get-Job-
Attributes and Cancel-Job. Such an implementation also needs to
deal with the problem of authentication of such foreign jobs. One
approach would be to treat all such foreign jobs as belonging to
users other than the user of the IPP client. Another approach
would be for the foreign job to belong to 'anonymous'. Only if
the IPP client has been authenticated as an operator or
administrator of the IPP Printer object, could the foreign jobs be
queried by an IPP request. Alternatively, if the security policy
is to allow users to query other users' jobs, then the foreign
jobs would also be visible to an end-user IPP client using Get-
Jobs and Get-Job-Attributes.
codings Thus IPP MAY be implemented as a "universal" protocol that provides
access to jobs submitted with any job submission protocol. As IPP
becomes widely implemented, providing a more universal access makes
sense.
Accept-Language not not language information is within 2.14 The 'none' value for empty sets
the application/ipp entity
Authorization must-if must per RFC 2068. A client MUST send [RFC2566] states that the 'none' value should be used as the value of
this header when it receives a a 1SetOf when the set is empty. In most cases, sets that are
401 "Unauthorized" response and potentially empty contain keywords so the keyword 'none' is used, but
does not receive a "Proxy- for the 3 finishings attributes, the values are enums and thus the
Authenticate" header. empty set is represented by the enum 3. Currently there are no other
attributes with 1SetOf values which can be empty and can contain
values that are not keywords. This exception requires special code
and is a potential place for bugs. It would have been better if we
had chosen an out-of-band value, either "no-value" or some new value,
such as 'none'. Since we didn't, implementations have to deal with
the different representations of 'none', depending on the attribute
syntax.
>From not not per RFC 2068. Because RFC 2.15 Get-Jobs, my-jobs='true', and 'requesting-user-name'?
recommends sending this header
only with the user's approval, it
is not very useful
Host must must per RFC 2068 In [RFC2566] section 3.2.6.1 'Get-Jobs Request', if the attribute '
my-jobs' is present and set to TRUE, MUST the 'requesting-user-name'
attribute be there to, and if it's not present what should the IPP
printer do?
If-Match not not [RFC2566] Section 8.3 describes the various cases of "requesting-
user-name" being present or not for any operation. If the client
does not supply a value for "requesting-user-name", the printer MUST
assume that the client is supplying some anonymous name, such as
"anonymous".
If-Modified- not not 2.16 The "multiple-document-handling" Job Template attribute and support
Since of multiple document jobs
If-None-Match not not ISSUE: IPP/1.0 is silent on which of the four effects an
implementation would perform if it supports Create-Job, but does not
support "multiple-document-handling".
If-Range not not A fix to IPP/1.0 would be to require implementing all four values of
"multiple-document-handling" if Create-Job is supported at all. Or
at least 'single-document-new-sheet' and 'separate-documents-
uncollated-copies'. In any case, an implementation that supports
Create-Job SHOULD also support "multiple-document-handling". Support
for all four values is RECOMMENDED, but at least the 'single-
document-new-sheet' and 'separate-documents-uncollated-copies'
values, along with the "multiple-document-handling-default"
indicating the default behavior and "multiple-document-handling-
supported" values. If an implementation spools the data, it should
also support the 'separate-documents-collated-copies' value as well.
If-Unmodified- not not 3 Encoding and Transport
Since
Max-Forwards not not This section discusses various aspects of IPP/1.0 Encoding and
Transport [RFC2565].
Proxy- must-if not per RFC 2068. A client MUST send A server is not required to send a response until after it has
Authorization this header when it receives a received the client.s entire request. Hence, a client must not
401 "Unauthorized" response and a expect a response until after it has sent the entire request.
"Proxy-Authenticate" header. However, we recommend that the server return a response as soon as
possible if an error is detected while the client is still sending
the data, rather than waiting until all of the data is received.
Therefore, we also recommend that a client 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 (and
so the client can keep the connection open for other requests, rather
than closing it). If the request is blocked for some reason, a client
MAY determine the reason by opening another connection to query the
server using Get-Printer-Attributes.
Range not not 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.
Referer not not - 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.
User-Agent not not The table for .request headers. does not have columns for responses,
and the table for .response headers. does not have columns for
requests.
3.3 Response Headers The following is an explanation of the values in the .request/client.
and .response/ server. columns.
The following is a table for the request headers. - 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,
Response- Server Client Response Values and Conditions - may: the client or server MAY send the header
Header - not: the client or server SHOULD NOT send the header. It is not
relevant to an IPP implementation.
Expires May 16, 1999 The following is an explanation of the values in the
Response- Server Client Response Values and Conditions .response/client. and .request/ server. columns.
Header
Accept-Ranges not not - 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.
Age not not 3.1 General Headers
Location must-if may per RFC 2068. When URI needs The following is a table for the general headers.
redirection.
Proxy- not must per RFC 2068 General- Request Response Values and Conditions
Authenticate Header
Public may may per RFC 2068 Client Server Server Client
Retry-After may may per RFC 2068 Cache- must not must not .no-cache. only
Control
Server not not 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.
Vary not not Date may may must may per RFC 1123 [RFC1123]
from RFC 2068
[RFC2068]
Warning may may per RFC 2068 Pragma must not must not .no-cache. only
WWW- must-if must per RFC 2068. When a server needs to Transfer- must-if must must- must .chunked. only .
Authenticate authenticate a client. 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
Request-Header Client Server Request Values and Conditions
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-
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
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 3.4 Entity Headers
The following is a table for the entity headers. The following is a table for the entity headers.
Entity-Header Request Response Values and Conditions Entity-Header Request Response Values and Conditions
Client Server Server Client Client Server Server Client
Allow not not not not Allow not not not not
Content-Base not not not not Content-Base not not not not
Content- may must must must per RFC 2068 and IANA Content- may must must must per RFC 2068 and IANA
Encoding registry for content Encoding registry for content
codings. codings.
Content- not not not not Application/ipp Content- not not not not Application/ipp
Language handles language Language handles language
Content- must-if must must-if must the length of the Content- must-if must must-if must the length of the
Length message-body per RFC Length message-body per RFC
2068. Header MUST be 2068. Header MUST be
present if Transfer- present if Transfer-
Encoding is absent..
Content- not not not not Entity-Header Request Response Values and Conditions
Location
Expires May 16, 1999 Client Server Server Client
Entity-Header Request Response Values and Conditions
Client Server Server Client Encoding is absent.
Content-MD5 may may may may per RFC 2068 Content- not not not not
Location
Content-Range not not not not Content-MD5 may may may may per RFC 2068
Content-Type must must must must "application/ipp" Content-Range not not not not
only
ETag not not not not Content-Type must must must must .application/ipp.
only
Expires not not not not ETag not not not not
Last-Modified not not not not Expires not not not not
Last-Modified not not not not
3.5 Optional support for HTTP/1.0 3.5 Optional support for HTTP/1.0
IPP implementations consist of an HTTP layer and an IPP layer. In the IPP implementations consist of an HTTP layer and an IPP layer. In
following discussion, the term "client" refers to the HTTP client layer the following discussion, the term "client" refers to the HTTP client
and the term "server" refers to the HTTP server layer. The Encoding and layer and the term "server" refers to the HTTP server layer. The
Transport document [IPP-PRO] requires that HTTP 1.1 MUST be supported by Encoding and Transport document [RFC2565] requires that HTTP 1.1 MUST
all clients and all servers. However, a client and/or a server be supported by all clients and all servers. However, a client
implementation may choose to also support HTTP 1.0. 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 - This option means that a server may choose to communicate with a
(non-conforming) client that only supports HTTP 1.0. In such cases (non-conforming) client that only supports HTTP 1.0. In such cases
the server should not use any HTTP 1.1 specific parameters or the server should not use any HTTP 1.1 specific parameters or
features and should respond using HTTP version number 1.0. features and should respond using HTTP version number 1.0.
@ This option also means that a client may choose to communicate with a - This option also means that a client may choose to communicate with
(non-conforming) server that only supports HTTP 1.0. In such cases, a (non-conforming) server that only supports HTTP 1.0. In such
if the server responds with an HTTP 'unsupported version number' to cases, if the server responds with an HTTP .unsupported version
an HTTP 1.1 request, the client should retry using HTTP version number. to an HTTP 1.1 request, the client should retry using HTTP
number 1.0. version number 1.0.
3.6 HTTP/1.1 Chunking 3.6 HTTP/1.1 Chunking
Clients MUST anticipate that the HTTP/1.1 server may chunk responses and 3.6.1 Disabling IPP Server Response Chunking
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 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:
This mechanism should not be used by a server to disable a client from TE: identity
chunking a request, since chunking of document data is an important
feature for clients to send long documents. 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.
3.6.2 Warning About the Support of Chunked Requests
This section describes some problems with the use of chunked requests
and HTTP/1.1 servers.
The HTTP/1.1 standard [HTTP] requires that conforming servers support
chunked requests for any method. However, in spite of this
requirement, some HTTP/1.1 implementations support chunked responses
in the GET method, but do not support chunked POST method requests.
Some HTTP/1.1 implementations that support CGI scripts [CGI] and/or
servlets [Servlet] require that the client supply a Content-Length.
These implementations might reject a chunked POST method and return a
411 status code (Length Required), might attempt to buffer the
request and run out of room returning a 413 status code (Request
Entity Too Large), or might successfully accept the chunked request.
Because of this lack of conformance of HTTP servers to the HTTP/1.1
standard, the IPP standard [RFC2565] REQUIRES that a conforming IPP
Printer object implementation support chunked requests and that
conforming clients accept chunked responses. Therefore, IPP object
implementers are warned to seek HTTP server implementations that
support chunked POST requests in order to conform to the IPP standard
and/or use implementation techniques that support chunked POST
requests.
Expires May 16, 1999
4 References 4 References
[IPP LPD] [CGI] Coar, K. and D. Robinson, "The WWW Common Gateway Interface
Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between Version 1.1 (CGI/1.1)", Work in Progress.
LPD and IPP Protocols", draft-ietf-ipp-lpd-ipp-map-04.txt, June
1998.
[IPP-MOD] [HTTP] Fielding, R., Gettys,J., Mogul, J., Frystyk,, H., Masinter,
R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer
"Internet Printing Protocol/1.0: Model and Semantics", draft-ietf- Protocol -- HTTP/1.1", RFC 2616, June 1999.
ipp-model-11.txt, November, 1998.
[IPP-PRO] [RFC2569] Herriot, R., Hastings, T., Jacobs, N. and J. Martin,
Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing "Mapping between LPD and IPP Protocols", RFC 2569, April
Protocol/1.0: Encoding and Transport", draft-ietf-ipp-pro-06.txt, 1999.
June, 1998.
[IPP-RAT] [RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S. and P.
Zilles, S., "Rationale for the Structure and Model and Protocol for Powell, "Internet Printing Protocol/1.0: Model and
the Internet Printing Protocol", draft-ietf-ipp-rat-03.txt, June, Semantics", RFC 2566, April 1999.
1998.
[IPP-REQ] [RFC2565] Herriot, R., Butler, S., Moore, P. and R. Tuner, "Internet
Wright, D., "Design Goals for an Internet Printing Protocol", Printing Protocol/1.0: Encoding and Transport", RFC 2565,
draft-ietf-ipp-req-02.txt, June, 1998. April 1999.
[RFC1123] [RFC2568] Zilles, S., "Rationale for the Structure and Model and
Braden, S., "Requirements for Internet Hosts - Application and Protocol for the Internet Printing Protocol", RFC 2568,
Support", RFC 1123, October, 1989. April 1999.
[RFC2068] [RFC2567] Wright, D., "Design Goals for an Internet Printing
R Fielding, et al, "Hypertext Transfer Protocol . HTTP/1.1" RFC Protocol", RFC 2567, April 1999.
2068, January 1997.
[rfc2119] [RFC1123] Braden, S., "Requirements for Internet Hosts - Application
S. Bradner, "Key words for use in RFCs to Indicate Requirement and Support", STD 3, RFC 1123, October 1989.
Levels", RFC 2119 , March 1997.
[RFC2396] [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource 3", BCP 9, RFC 2026, October 1996.
Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[SSL] [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
Netscape, The SSL Protocol, Version 3, (Text version 3.02), Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
November 1996. 2068, January 1997.
4.1 Authors' Address [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Thomas N. Hastings [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Xerox Corporation Resource Identifiers (URI): Generic Syntax", RFC 2396,
701 Aviation Blvd. August 1998.
Expires May 16, 1999 [Servlet] Servlet Specification Version 2.1
El Segundo, CA 90245 (http://java.sun.com/products/servlet/2.1/index.html).
hastings@cp10.es.xerox.com
Carl-Uno Manros [SSL] Netscape, The SSL Protocol, Version 3, (Text version 3.02),
Xerox Corporation November 1996.
701 Aviation Blvd.
El Segundo, CA 90245
manros@cp10.es.xerox.com
5 Appendix C: Full Copyright Statement 4.1 Authors' Addresses
Copyright (C) The Internet Society (1998). All Rights Reserved Thomas N. Hastings
Xerox Corporation
701 Aviation Blvd.
El Segundo, CA 90245
This document and translations of it may be copied and furnished to EMail: hastings@cp10.es.xerox.com
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 Carl-Uno Manros
revoked by the Internet Society or its successors or assigns. Xerox Corporation
701 Aviation Blvd.
El Segundo, CA 90245
This document and the information contained herein is provided on an "AS EMail: manros@cp10.es.xerox.com
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.
Expires May 16, 1999 5 Security Considerations
Security issues are discussed in sections 2.2, 2.3.1, and 8.5.
6 Notices
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11 [BCP-11].
Copies of claims of rights made available for publication and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (1999). 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 495 change blocks. 
1861 lines changed or deleted 2341 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/