1 - 3 - 7 - 8 - A - B - C - D - E - F - G - H - I - J - L - M - N - O - P - Q - R - S - T - U - V - W
IPP
Click on the red underlined text to get to the source
...
The Internet Printing Protocol (IPP) is an application level protocol
that can be used for distributed printing using Internet tools ...
... technologies. IPP version 1.1 (IPP/1.1) focuses primarily on end
user functionality with a few administrative operations included.
This document is just one of a suite of documents that fully define
...
... user functionality with a few administrative operations included.
This document is just one of a suite of documents that fully define
IPP. The full set of IPP documents includes:
...
... This document is just one of a suite of documents that fully define
IPP. The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol ...
...
Anyone reading these documents for the first time is strongly
encouraged to read the IPP documents in the above order.
This document is laid out as follows:
...
... This document is laid out as follows:
- The rest of Section 1 is an introduction to the IPP simplified
model for distributed printing.
- Section 2 introduces the object types covered in the model with
...
... - Section 2 introduces the object types covered in the model with
their basic behaviors, attributes, and interactions.
- Section 3 defines the operations included in IPP/1.1. IPP
operations are synchronous ...
... their basic behaviors, attributes, and interactions.
- Section 3 defines the operations included in IPP/1.1. IPP
operations are synchronous, therefore, for each operation, there is
...
... Printer not just by name, but by filtered searches as well.
- Section 17 is an appendix summarizing the additions and changes
from the IPP/1.0 "Model and Semantics" document [RFC2566] to make
...
... Semantics" document [RFC2566] to make
this IPP/1.1 document.
- Section 18 is the full copyright notice.
...
... protocol for the Internet, the Internet Printing Protocol (IPP) is
based on a simplified printing model that abstracts the many
components of real world printing solutions. The Internet ...
... service providers. This model and semantics document
describes a simple, abstract model for IPP even though the underlying
configurations may be complex "n-tier" client/server systems. An
...
... configurations may be complex "n-tier" client/server systems. An
important simplifying step in the IPP model is to expose only the key
objects and interfaces required for printing. The model described in
...
... interfaces, and
relationships that are beyond the scope of the first version of IPP
(IPP/1.1). IPP ...
... version of IPP
(IPP/1.1). IPP/1.1 incorporates many of the relevant ideas and
lessons learned from other specification and development efforts
...
... IPP
(IPP/1.1). IPP/1.1 incorporates many of the relevant ideas and
lessons learned from other specification and development efforts
[HTPP ...
... PSIS] [RFC1179] [SWP]. IPP is
heavily influenced by the printing model introduced in the Document
Printing Application (DPA) [ISO10175 ...
... Printing Application (DPA) [ISO10175] standard. Although DPA
specifies both end user and administrative features, IPP version 1.1
(IPP ...
... IPP version 1.1
(IPP/1.1) focuses primarily on end user functionality with a few
additional OPTIONAL operator operations.
...
... additional OPTIONAL operator operations.
The IPP/1.1 model encapsulates the important components of
distributed printing into two object types:
...
...
It is important, however, to understand that in real system
implementations (which lie underneath the abstracted IPP/1.1 model),
there are other components of a print service which are not
...
... there are other components of a print service which are not
explicitly defined in the IPP/1.1 model. The following figure
illustrates where IPP/1.1 fits with respect to these other
...
... explicitly defined in the IPP/1.1 model. The following figure
illustrates where IPP/1.1 fits with respect to these other
components.
...
... | | | |
| +---+------------+---+ |
N D S | | IPP Client |------------+
O I E | +---------+----------+
T R C | |
...
... C O T | --+
A R Y +--------+--------+ |
T Y | IPP Server | |
I +--------+--------+ |
O | |
...
... I +--------+--------+ |
O | |
N +-----------------+ | IPP Printer
| Print Service | |
...
... +-----------------+
An IPP Printer object encapsulates the functions normally associated
with physical ...
... which only represents the Printer object.
IPP clients implement the IPP protocol on the client side and give
...
...
IPP clients implement the IPP protocol on the client side and give
end users (or programs running on behalf of end users) the ability to
...
... end users (or programs running on behalf of end users) the ability to
query Printer objects and submit and manage print jobs. An IPP
server is just that part of the Printer object that implements the
server-side ...
...
The notification service is out of scope for this IPP/1.1 document,
but using such a notification service, the end user is able to
...
... IPP Objects ...
...
The IPP/1.1 model introduces objects of type Printer and Job. Each
type of object models relevant aspects of a real-world entity such as
...
...
The major component of the IPP/1.1 model is the Printer object. A
Printer object implements the server-side of the IPP ...
... IPP/1.1 model is the Printer object. A
Printer object implements the server-side of the IPP/1.1 protocol.
Using the protocol, end users may query the attributes of the Printer
...
... 2) An output device with a built-in spooler
3) A print server supporting IPP with one or more associated
output devices
3a) The associated output devices may or may not be capable of
...
... 3a) The associated output devices may or may not be capable of
spooling jobs
3b) The associated output devices may or may not support IPP
The following figures show some examples of how Printer objects can
...
... client" refers to a software entity that
sends IPP operation requests to an IPP Printer object and accepts IPP
...
... entity that
sends IPP operation requests to an IPP Printer object and accepts IPP
operation responses. A client ...
... sends IPP operation requests to an IPP Printer object and accepts IPP
operation responses. A client MAY be:
...
... activated by the "Print" menu item in an application or
2. the print server component that sends IPP requests to either an
output device or another "downstream ...
... IPP Printer" is a network entity that accepts IPP operation
requests and returns IPP operation responses. As such, an IPP ...
... entity that accepts IPP operation
requests and returns IPP operation responses. As such, an IPP object
MAY be:
...
... MAY be:
1. an (embedded) device component that accepts IPP requests and
controls the device or
...
... controls the device or
2. a component of a print server that accepts IPP requests (where
the print server controls one or more networked devices using
IPP ...
... IPP requests (where
the print server controls one or more networked devices using
IPP or other protocols).
Legend:
...
... any indicates any network protocol or direct
connect, including IPP
embedded printer:
...
... O +--------+ | ########### |
/|\ | client |------------IPP------------># Printer # |
/ \ +--------+ | # Object # |
| ########### |
...
... O +--------+ ########### | |
/|\ | client |--IPP--># Printer #-any->| output device |
/ \ +--------+ # Object # | |
...
... O +--------+ ########### / +---------------+
/|\ | client |-IPP-># Printer #--*
/ \ +--------+ # Object # \ +---------------+
########### any\ | |
...
... create a Job object is sent
in a create request from the end user via an IPP Client to the
Printer object. The Printer object validates the create ...
... stream of document data
In IPP/1.1, a document is not modeled as an IPP object, therefore it
has no object identifier ...
...
In IPP/1.1, a document is not modeled as an IPP object, therefore it
has no object identifier or associated attributes. All job
...
...
IPP objects have relationships that are maintained persistently along
with the persistent storage of the object attributes.
...
... RFC2246] (the mechanism for security configuration is
outside the scope of this IPP/1.1 document). In some situations,
both types of connections (both authenticated ...
... one of the communication channels to the Printer object. To support
this flexibility, the IPP Printer object type defines a multi-valued
identification attribute called the "printer-uri-supported"
attribute. It MUST contain at least one URI ...
... "printer-uri-supported" Printer attribute.
IPP/1.1 does not specify how the client obtains the client supplied
...
... directory service
and describes how the entry acts as a bridge to the actual IPP
Printer object. The entry in the directory that represents the IPP
Printer object includes the possibly many URIs for that Printer
...
... and describes how the entry acts as a bridge to the actual IPP
Printer object. The entry in the directory that represents the IPP
Printer object includes the possibly many URIs for that Printer
object as values in one its attributes.
...
... create request was originally submitted.
Therefore, in order to allow both types of client access to IPP Job
objects (either by Job URI or by numeric Job ID), when the Printer
...
... is chosen and set by an administrator through some mechanism outside
the scope of this IPP/1.1 document. A Job object's name is
optionally chosen and supplied by the IPP client submitting the job.
...
... the scope of this IPP/1.1 document. A Job object's name is
optionally chosen and supplied by the IPP client submitting the job.
If the client does not supply a Job object name, the Printer object
...
... unique). The administrator chooses and sets this name through
some mechanism outside the scope of this IPP/1.1 document. The
Printer object's "printer-name" attribute contains the name.
- Each Job object has a name (which is not necessarily unique).
...
... IPP Operations ...
...
IPP objects support operations. An operation consists of a request
and a response. When a client communicates with an IPP ...
... IPP objects support operations. An operation consists of a request
and a response. When a client communicates with an IPP object, the
client issues an operation request to the URI ...
...
This section describes the semantics of the IPP operations, both
requests and responses, in terms of the parameters, attributes, and
other data associated with each operation.
...
...
All IPP operations require some common parameters and operation
attributes. These common elements and their semantic ...
...
Each IPP operation request includes an identifying "operation-id"
value. Valid values are defined in the "operations-supported"
...
... clients to manage multiple outstanding
requests. The receiving IPP object copies all 32-bits of the client-
...
... the "request-id" is out of range. If the request is terminated
before the complete "request-id" is received, the IPP object rejects
the request and returns a response with a "request-id" of 0.
...
...
Note: In some cases, the transport protocol underneath IPP might be a
connection oriented protocol that would make it impossible for a
...
... - Operation Attributes: These attributes are passed in the
operation and affect the IPP object's behavior while processing
the operation request and may affect other attributes or groups
...
... which operation attributes are REQUIRED and which are OPTIONAL
for an IPP object to support and which attributes a client MUST
supply in a request and an IPP ...
... IPP object to support and which attributes a client MUST
supply in a request and an IPP object MUST supply in a response.
- Job Template Attributes: These attributes affect the processing
of a job. A client ...
... and how unsupported attributes are returned to the client.
Because of extensibility, any IPP object might receive a request
that contains new or unknown attributes or values for which it
has no support. In such cases, the IPP ...
... IPP object might receive a request
that contains new or unknown attributes or values for which it
has no support. In such cases, the IPP object processes what it
can and returns the unsupported attributes in the response. The
Unsupported Attribute group ...
... one of the attribute instances, depending on implementation. Which
attribute is selected when there are duplicate attributes depends on
implementation. The IPP Printer MUST NOT use the values from more
than one such duplicate attribute instance.
...
... data.
Some operations are REQUIRED for IPP objects to support; the others
are OPTIONAL (see section 5.2.2). Therefore, before using an
OPTIONAL operation, a client ...
... Job operations are actually supported. The client SHOULD NOT use an
OPTIONAL operation that is not supported. When an IPP object
receives a request to perform an operation it does not support, it
returns the 'server-error-operation-not-supported' status code ...
... returns the 'server-error-operation-not-supported' status code (see
section 13.1.5.2). An IPP object is non-conformant if it does not
support a REQUIRED operation.
...
... attribute MUST be the second attribute in the group. In other words,
these attributes MUST be supplied in every IPP request and response,
they MUST come first in the group ...
... group, and MUST come in the specified
order. For job creation operations, the IPP Printer implementation
saves these two attributes with the new Job object as Job Description
attributes. For the sake of brevity in this document, these
...
... client MUST supply and the Printer object MUST support the
following REQUIRED operation attributes in every IPP/1.1 operation
request:
...
... Note to client implementers: Since IPP objects are only
required to support the 'utf-8' charset, in order to maximize
...
... charset, in order to maximize
interoperability with multiple IPP object implementations, a
client may want to supply 'utf-8' in the "attributes-charset ...
... the response that it cannot present to its user. On the other
hand, if both the client and the IPP objects also support a
charset in common besides utf-8, the client ...
... natural languages supported by the Printer object and any
contained Job objects for all text strings generated by the IPP
object. A client MAY query ...
... operation attribute of the request.
The IPP object MUST accept any natural language and any Natural
Language ...
... language and any Natural
Language Override, whether the IPP object supports that natural
language or not (and independent of the value of the "ipp-
...
... language or not (and independent of the value of the "ipp-
attribute-fidelity" Operation attribute). That is the IPP
object accepts all client supplied values no matter what the
...
... language-supported", only applies to generated
messages, not client supplied messages. The IPP object MUST
remember that natural language for all client ...
... attributes, and when returning those attributes in response to
a query, the IPP object MUST indicate that natural language.
...
... language" attribute, or if different, as identified by
the Natural Language Override mechanism. If supplied, the IPP
object will use the value of the "job-name" attribute to
populate the Job object's "job-name" attribute. Whenever any
...
... client queries the Job object's "job-name" attribute, the IPP
object returns the attribute as stored and uses the Natural
Language ...
... language" operation attribute of the response. The IPP object
MAY use the Natural Language Override mechanism redundantly,
...
... operation attribute of the response.
An IPP object MUST NOT reject a request based on a supplied
natural language in an "attributes-natural-language ...
... client MUST support the
following REQUIRED operation attributes in every IPP/1.1 operation
response:
...
... operation attribute identifies the natural language used
by any 'text' and 'name' attributes that the IPP object is
returning in this response. Unlike the "attributes-charset"
...
... charset"
operation attribute, the IPP object NEED NOT return the same
value as that supplied by the client in the request. The IPP ...
... IPP object NEED NOT return the same
value as that supplied by the client in the request. The IPP
object MAY return the natural language of the Job object or the
...
... returned in the "attributes-natural-language" operation
attribute, the IPP object MUST use the Natural Language
Override mechanism (see sections 4.1.1.2 and 4.1.2.2) on each
...
... Language
Override mechanism (see sections 4.1.1.2 and 4.1.2.2) on each
attribute value returned. The IPP object MAY use the Natural
Language Override mechanism redundantly, i.e., use it even when
...
...
All IPP operations are directed at IPP objects. For Printer
operations, the operation is always directed at a Printer object
...
...
All IPP operations are directed at IPP objects. For Printer
operations, the operation is always directed at a Printer object
using one of its URIs ...
... In all cases, the target URIs contained within the body of IPP
operation requests and responses must be in absolute format rather
than relative format (a relative URL ...
... URI, then that port number MUST be used by the
client to contact the IPP object.
2. If the URI scheme ...
... port number implied by that URI
scheme MUST be used by the client to contact the IPP object.
3. If the URI scheme ...
... Transport document [RFC2910] shows a
mapping of IPP onto HTTP/1.1 [RFC2616] and defines a new default port
number ...
... status code is intended for use by automata. A client
implementation of IPP SHOULD convert status code values into any
localized message that has semantic ...
... status message is intended for
the human end user. If a response does include a "status-message"
attribute, an IPP client NEED NOT examine or display the messages,
however it SHOULD do so in some implementation specific manner. The
"status-message" is especially useful for a later version ...
... allows the client to identify which version of IPP it is interested
in using, i.e., the version whose conformance requirements ...
... may be depending upon the Printer to meet.
If the IPP object does not support that major version number supplied
by the client ...
... If the major version number is supported, but the minor version
number is not, the IPP object SHOULD accept and attempt to perform
the request (or reject the request if the operation is not
supported), else it rejects the request and returns the 'server-
...
... error-version-not-supported' status code. In all cases, the IPP
object MUST return the "version-number" that it supports that is
...
... a 'server-error-version-not-supported' status code from an IPP
object, a client SHOULD try again with a different version number ...
... versions are supported.
An IPP object implementation MUST support version '1.1', i.e., meet
the conformance requirements ...
... version '1.1', i.e., meet
the conformance requirements for IPP/1.1 as specified in this
document and [RFC2910]. It is recommended that IPP ...
... IPP/1.1 as specified in this
document and [RFC2910]. It is recommended that IPP object
implementations accept any request with the major version '1' (or
...
...
There is only one notion of "version number" that covers both IPP
Model and IPP Protocol changes. Thus the version number ...
... version number" that covers both IPP
Model and IPP Protocol changes. Thus the version number MUST change
when introducing a new version ...
... document indicate structural or syntactic changes that make it
impossible for older version of IPP clients and Printer objects to
correctly parse and correctly process the new or changed attributes,
operations and responses. If the major version number ...
... version '1.0'), would have required a change to
the major version number, since an IPP/1.0 Printer would not have
processed a request with the correct semantics that contained the
...
... - reordering of ordered attributes or attribute sets
- changes to the syntax of existing attributes
- adding REQUIRED (for an IPP object to support) operation
attribute groups
...
... version number indicate the addition of new
features, attributes and attribute values that may not be understood
by all IPP objects, but which can be ignored if not understood.
Items that might affect the changing of the minor version number
...
... - adding new object attributes
- adding OPTIONAL (for an IPP object to support) operation
attributes (i.e., those attributes that an IPP object can ignore
...
... - adding OPTIONAL (for an IPP object to support) operation
attributes (i.e., those attributes that an IPP object can ignore
without confusing clients)
...
... without confusing clients)
- adding OPTIONAL (for an IPP object to support) operation
attribute groups (i.e., those attributes that an IPP ...
... IPP object to support) operation
attribute groups (i.e., those attributes that an IPP object can
ignore without confusing clients)
...
... versions. As each new version is defined (through the
release of a new IPP specification document), that version will
specify which previous versions ...
... not the supplied attributes, attribute syntaxes, and values are
supported by matching them with the Printer object's corresponding
"xxx-supported" attributes. See section 3.1.7 for details. [IPP-
IIG] presents suggested steps for an IPP object to either accept or
...
... "xxx-supported" attributes. See section 3.1.7 for details. [IPP-
IIG] presents suggested steps for an IPP object to either accept or
reject any request and additional steps for processing create
...
... client MUST be prepared to keep
submitting a create request until the IPP Printer object accepts the
create request.
...
... tools, or
even stored along with the document as a document level
attribute. IPP/1.1 does not support the concept of document
level attributes.
...
... attributes for the supported Job Template attributes that were
not supplied by the client as IPP attribute or embedded
instructions in the document data.
...
... status code.
The IPP Printer MAY validate the accessibility of the document as
part of the operation or subsequently. If the Printer determines an
...
... populate the job's "job-document-access-errors" Job Description
attribute (see section 4.3.11). See The Implementer's Guide [IPP-
IIG] for suggested additional checks.
...
... 4.4.27).
It is up to the IPP object to interpret the URI and subsequently
"pull" the document from the source referenced by the URI ...
... operation
attribute with any supplied values (attribute keywords) that were
requested by the client but are not supported by the IPP object.
If the Printer object does return unsupported attributes
referenced in the "requested-attributes ...
... operation
attribute with any supplied values (attribute keywords) that were
requested by the client but are not supported by the IPP object.
If the Printer object does return unsupported attributes
referenced in the "requested-attributes ...
... Printer
operation MUST be supported, and vice-versa.
The IPP Printer stops the current job(s) on its device(s) that were
in the 'processing' or 'processing-stopped' states as soon as the
implementation permits. If the implementation will take appreciable
...
... in the 'processing' or 'processing-stopped' states as soon as the
implementation permits. If the implementation will take appreciable
time to stop, the IPP Printer adds the 'moving-to-paused' value to
the Printer object's "printer-state-reasons" attribute (see section
...
... the Printer object's "printer-state-reasons" attribute (see section
4.4.12). When the device(s) have all stopped, the IPP Printer
transitions the Printer object to the 'stopped' state, removes ...
... When the current job(s) complete that were in the 'processing' state,
the IPP Printer transitions them to the 'completed' state. When the
current job(s) stop in mid processing that were in the 'processing'
...
... current job(s) stop in mid processing that were in the 'processing'
state, the IPP Printer transitions them to the 'processing-stopped'
state and adds the 'printer-stopped' value to the job's "job-state ...
... stopped' value of the jobs' "job-state-reasons" attribute also
applies. However, the IPP Printer NEED NOT update those jobs' "job-
state ...
... Whether the Pause-Printer operation affects jobs that were submitted
to the device from other sources than the IPP Printer object in the
same way that the Pause-Printer operation affects jobs that were
...
... same way that the Pause-Printer operation affects jobs that were
submitted to the IPP Printer object using IPP, depends on
implementation, i.e., on whether the IPP ...
... Printer operation affects jobs that were
submitted to the IPP Printer object using IPP, depends on
implementation, i.e., on whether the IPP protocol is being used as a
...
... IPP Printer object using IPP, depends on
implementation, i.e., on whether the IPP protocol is being used as a
universal management protocol or just to manage IPP ...
... IPP protocol is being used as a
universal management protocol or just to manage IPP jobs,
respectively.
...
... respectively.
The IPP Printer MUST accept the request in any state and transition
the Printer to the indicated new "printer-state ...
... follows:
Current New "printer IPP Printer's response status
"printer- "printer- -state- code and action:
...
... this operation must be an operator or administrator of the Printer
object (see Sections 1 and 8.5). Otherwise, the IPP Printer MUST
reject the operation and return: 'client-error-forbidden', 'client ...
... "printer-state-reasons" attribute, if present. If there are no other
reasons to keep a device paused (such as media-jam), the IPP Printer
is free to transition itself to the 'processing' or 'idle' states,
depending on whether there are jobs to be processed or not,
...
... Printer
operation MUST be supported, and vice-versa.
The IPP Printer removes the 'printer-stopped' value from any job's
"job-state ...
... state-reasons" attributes contained in that Printer.
The IPP Printer MUST accept the request in any state, transition the
Printer object to the indicated new state ...
... state as follows:
Current New "printer- IPP Printer's response status code and
"printer- state ...
... this operation must be an operator or administrator of the Printer
object (see Sections 1 and 8.5). Otherwise, the IPP Printer MUST
reject the operation and return: 'client-error-forbidden', 'client ...
... client to remove all jobs from an
IPP Printer object, regardless of their job states, including jobs in
the Printer object's Job History (see Section 4.3.7.2). After a
Purge-Jobs operation has been performed, a Printer object MUST return
...
...
Whether the Purge-Jobs (and Get-Jobs) operation affects jobs that
were submitted to the device from other sources than the IPP Printer
object in the same way that the Purge-Jobs operation affects jobs
that were submitted to the IPP Printer ...
... IPP Printer
object in the same way that the Purge-Jobs operation affects jobs
that were submitted to the IPP Printer object using IPP, depends on
implementation, i.e., on whether the IPP ...
... object in the same way that the Purge-Jobs operation affects jobs
that were submitted to the IPP Printer object using IPP, depends on
implementation, i.e., on whether the IPP protocol is being used as a
...
... IPP Printer object using IPP, depends on
implementation, i.e., on whether the IPP protocol is being used as a
universal management protocol or just to manage IPP ...
... IPP protocol is being used as a
universal management protocol or just to manage IPP jobs,
respectively.
...
... this operation must be an operator or administrator of the Printer
object (see Sections 1 and 8.5). Otherwise, the IPP object MUST
reject the operation and return: client-error-forbidden, client ...
... URI or a combination of a Printer URI with a
Job ID. The IPP object implementation MUST support both forms of
identification for every job.
...
... period of time for a particular job, a client MUST send another send
operation within an IPP Printer defined minimum time interval after
the receipt of the previous request for the job. If a Printer object
supports the Create-Job ...
... before taking some recovery action.
An IPP object MUST recover from an errant client that does not supply
a send operation, sometime after the minimum time interval specified
...
... Create-Job operation) or an operator or administrator of the Printer
object (see Sections 1 and 8.5). Otherwise, the IPP object MUST
reject the operation and return: 'client-error-forbidden', 'client ...
... URI before returning a response, just as in the Print-URI
operation. The IPP Printer MAY validate the accessibility of the
document as part of the operation or subsequently (see section
...
... before the job is actually terminated.
The IPP object MUST accept or reject the request based on the job's
current state and transition the job to the indicated new state ...
... Rule 1: If the implementation requires some measurable time to
cancel the job in the 'processing' or 'processing-stopped' job
states, the IPP object MUST add the 'processing-to-stop-point' value
to the job's "job-state-reasons" attribute and then transition the
...
... administrator of the Printer object (see Sections 1 and 8.5).
Otherwise, the IPP object MUST reject the operation and return:
'client-error-forbidden', 'client-error-not-authenticated ...
... requested-attributes" (1setOf keyword):
The client OPTIONALLY supplies this attribute. The IPP object
MUST support this attribute. It is a set of attribute names
...
... group names in whose values the requester is
interested. If the client omits this attribute, the IPP object
MUST respond as if this attribute had been supplied with a value
of 'all'.
...
... operation
attribute with any supplied values (attribute keywords) that were
requested by the client but are not supported by the IPP object.
If the Printer object does return unsupported attributes
referenced in the "requested-attributes ...
...
This is the set of requested attributes and their current values.
The IPP object ignores (does not respond with) any requested
attribute or value which is not supported or which is restricted
by the security policy ...
... security policy in force, including whether the requesting
user is the user that submitted the job (job originating user) or
not (see section 8). However, the IPP object MUST respond with
the 'unknown' value for any supported attribute (including all
REQUIRED attributes) for which the IPP ...
... IPP object MUST respond with
the 'unknown' value for any supported attribute (including all
REQUIRED attributes) for which the IPP object does not know the
value, unless it would violate the security policy. See the
...
... indefinitely or until a specified time period, if supported.
The IPP object MUST accept or reject the request based on the job's
current state and transition the job to the indicated new state ...
... Rule 1: If the implementation supports multiple reasons for a job to
be in the 'pending-held' state, the IPP object MUST add the 'job-
hold-until-specified' value to the job's "job-state-reasons"
...
... attribute.
Rule 2: If the IPP object supports the "job-hold-until" operation
attribute, but the specified time period has already started (or is
the 'no-hold' value) and there are no other reasons to hold the job,
...
... operation
attribute, but the specified time period has already started (or is
the 'no-hold' value) and there are no other reasons to hold the job,
the IPP object MUST make the job be a candidate for processing
immediately (see Section 4.2.2) by putting the job in the 'pending'
...
... administrator of the Printer object (see Sections 1 and 8.5).
Otherwise, the IPP object MUST reject the operation and return:
'client-error-forbidden', 'client-error-not-authenticated ...
... client OPTIONALLY supplies this Operation attribute. The
IPP object MUST support this operation attribute in a Hold-Job
request, if it supports the "job-hold-until" Job template
...
... request, if it supports the "job-hold-until" Job template
attribute in create operations. See section 4.2.2. The IPP
object SHOULD support the "job-hold-until" Job Template
attribute for use in job create ...
...
If supplied and supported as specified in the Printer's "job-
hold-until-supported" attribute, the IPP object copies the
supplied operation attribute to the Job object, replacing the
...
... If supplied, but either the "job-hold-until" Operation
attribute itself or the value supplied is not supported, the
IPP object accepts the request, returns the unsupported
attribute or value in the Unsupported Attributes Group
...
... client (1) supplies a value that specifies a time period
that has already started or the 'no-hold' value (meaning don't
hold the job) and (2) the IPP object supports the "job-hold-
until" operation attribute and there are no other reasons to
...
... until" operation attribute and there are no other reasons to
hold the job, the IPP object MUST accept the operation and make
the job be a candidate for processing immediately (see Section
...
... If the client does not supply a "job-hold-until" Operation
attribute in the request, the IPP object MUST populate the job
object with a "job-hold-until" attribute with the 'indefinite'
value (if IPP ...
... IPP object MUST populate the job
object with a "job-hold-until" attribute with the 'indefinite'
value (if IPP object supports the "job-hold-until" attribute)
and hold the job indefinitely, until a client performs a
...
... Restart-Job operation and removes its effect
on the job. The IPP object MUST remove the 'job-hold-until-
specified' value from the job's "job-state ...
... present. See section 4.3.8.
The IPP object MUST accept or reject the request based on the job's
current state and transition the job to the indicated new state ...
... administrator of the Printer object (see Sections 1 and 8.5).
Otherwise, the IPP object MUST reject the operation and return:
'client-error-forbidden', 'client-error-not-authenticated ...
... state and
restarts at the beginning on the same IPP Printer object with the
same attribute values. If any of the documents in the job were
passed by reference (Print-URI ...
... only.
The IPP object MUST accept or reject the request based on the job's
current state, transition the job to the indicated new state ...
... Rule 1: If the Job Retention Period has expired for the job in this
state, then the IPP object rejects the operation. See section
4.3.7.2.
...
... administrator of the Printer object (see Sections 1 and 8.5).
Otherwise, the IPP object MUST reject the operation and return:
'client-error-forbidden', 'client-error-not-authenticated ...
... "job-hold-until" (type3 keyword | name(MAX)):
The client OPTIONALLY supplies this attribute. The IPP object
MUST support this Operation attribute in a Restart ...
... if it supports the "job-hold-until" Job Template attribute in
create operations. See section 4.2.2. Otherwise, the IPP
object NEED NOT support the "job-hold-until" Operation
attribute in a Restart ...
...
If supplied and supported as specified in the Printer's "job-
hold-until-supported" attribute, the IPP object copies the
supplied Operation attribute to the Job object, replacing the
...
... named time period. See section 4.2.2.
If supplied, but the value is not supported, the IPP object
accepts the request, returns the unsupported attribute or value
in the Unsupported Attributes Group ...
... If supplied, but the "job-hold-until" Operation attribute
itself is not supported, the IPP object accepts the request,
returns the unsupported attribute with the out-of-band
...
... client (1) supplies a value that specifies a time period
that has already started or the 'no-hold' value (meaning don't
hold the job) and (2) the IPP object supports the "job-hold-
until" operation attribute and there are no other reasons to
...
... until" operation attribute and there are no other reasons to
hold the job, the IPP object makes the job a candidate for
processing immediately (see Section 4.2.2).
...
... If the client does not supply a "job-hold-until" operation
attribute in the request, the IPP object removes the "job-
hold-until" attribute, if present, from the job. If there are
...
...
This section describes the attributes with their corresponding
attribute syntaxes and values that are part of the IPP model. The
sections below show the objects and their associated attributes which
are included within the scope of this protocol. Many of these
...
... This section defines the basic attribute syntax types that all
clients and IPP objects MUST be able to accept in responses and
accept in requests, respectively. Each attribute description in
sections 3 and 4 includes the name of attribute syntax(es) in the
...
... out-of-band" values are:
'unknown': The attribute is supported by the IPP object, but the
value is unknown to the IPP object for some reason.
...
... 'unknown': The attribute is supported by the IPP object, but the
value is unknown to the IPP object for some reason.
'unsupported': The attribute is unsupported by the IPP object.
...
... value is unknown to the IPP object for some reason.
'unsupported': The attribute is unsupported by the IPP object.
This value MUST be returned only as the value of an attribute
in the Unsupported Attributes Group ...
... interpretation of 'text' is: 'textWithoutLanguage |
textWithLanguage'. That is, for any attribute defined in this
document using the 'text' attribute syntax, all IPP objects and
clients ...
... is the so-called Natural Language Override mechanism and MUST be
supported by all IPP objects and clients.
...
...
Also like 'text', 'name' is really an abbreviated notation for either
'nameWithoutLanguage' or 'nameWithLanguage'. That is, all IPP
objects and clients MUST support both the 'nameWithoutLanguage' and
...
... rather than the normal 'textWithoutLanguage' syntax is the so-called
Natural Language Override mechanism and MUST be supported by all IPP
objects and clients.
...
... so-called Natural Language Override mechanism and MUST be supported
by all IPP objects and clients. If a name is in a language that is
...
...
When a keyword is used to represent an attribute (its name), it MUST
be unique within the full scope of all IPP objects and attributes.
When a keyword is used to represent a value of an attribute, it MUST
be unique just within the scope of that attribute. That is, the same
...
... Note: SNMP MIBs use '2' for 'unknown' which corresponds to the IPP
"out-of-band" value 'unknown'. See the description of the "out-of-
...
... Uniform Resource
Locators or URLs. The maximum length of URIs used as values of IPP
attributes is 1023 octets. Although most other IPP attribute syntax
...
... URIs used as values of IPP
attributes is 1023 octets. Although most other IPP attribute syntax
types allow for only lower-cased values, this attribute syntax type
conforms to the case-sensitive and case-insensitive ...
... RFC 2396(-> 3986std66) requires that the values be case-insensitive, IPP requires
all lower case values in IPP attributes to simplify comparing by IPP
clients ...
... case-insensitive, IPP requires
all lower case values in IPP attributes to simplify comparing by IPP
clients and Printer objects.
...
... IPP requires
all lower case values in IPP attributes to simplify comparing by IPP
clients and Printer objects.
Standard values for this syntax type are the following keywords:
...
... Standard values for this syntax type are the following keywords:
'ipp': for IPP schemed URIs (e.g., "ipp:...")
'http': for HTTP ...
... IANA-MT]. The maximum length of URI 'scheme'
values used to represent IPP attribute values is 63 octets.
...
... case-insensitive US-ASCII [ASCII], IPP requires all lower case values
in IPP attributes to simplify comparing by IPP clients ...
... ASCII], IPP requires all lower case values
in IPP attributes to simplify comparing by IPP clients and Printer
objects. When a character-set in the IANA registry ...
... IPP requires all lower case values
in IPP attributes to simplify comparing by IPP clients and Printer
objects. When a character-set in the IANA registry has more than one
...
... case-insensitive US-ASCII [ASCII], IPP
requires all lower case to simplify comparing by IPP clients and
...
... ASCII], IPP
requires all lower case to simplify comparing by IPP clients and
Printer objects. Examples include:
...
... 'de': for German
The maximum length of 'naturalLanguage' values used to represent IPP
attribute values is 63 octets.
...
... the IANA Registry [IANA-MT]. Although most other IPP syntax types
allow for only lower-cased values, this syntax type allows for
mixed-case values which are case-insensitive ...
... stream': Auto-sense - see section 4.1.9.1
The maximum length of a 'mimeMediaType' value to represent IPP
attribute values is 255 octets.
...
... priority" attribute. However, the enforcement of that
additional constraint is up to the IPP objects, not the protocol.
...
... 8 octet representation of a
"DateAndTime" value, but IPP objects MUST use the 11 octet
representation. A user interface ...
... information is supplied by the client (either explicitly as an
IPP attribute in the create request or implicitly as an
embedded instruction within the document data).
...
... client does supply the
"finishings" attribute in the create request, the IPP object
validates the value or values to make sure that they are a subset of
...
... entire range with any Printer object. If privileged jobs are
implemented outside IPP/1.1, they MUST have priorities higher than
100, rather than restricting the range ...
... An administrator MUST associate allowable print times with a named
time period (by means outside the scope of this IPP/1.1 document).
An administrator is encouraged to pick names that suggest the type of
...
... Printer object can process the job in a single pass. If the ranges
are not ascending or are overlapping, the IPP object MUST reject the
request and return the 'client-error-bad-request' status code ...
... include the subset of "media-supported" values that are physically
loaded and ready for printing with no operator intervention required.
If an IPP object supports "media-supported", it NEED NOT support
"media-ready".
...
... authenticated printable name that it can obtain from the
authentication service over which the IPP operation was received.
Only if such is not available, does the Printer object use the value
supplied by the client ...
... This REQUIRED attribute identifies the current state of the job.
Even though the IPP protocol defines seven values for job states
(plus the out-of-band 'unknown' value - see Section 4.1),
...
... output device is actually making marks on paper and/or
the 'processing-to-stop-point' value to indicate that the
IPP object is in the process of canceling or aborting the
job. Most implementations won't bother with this nuance.
...
...
As with all other IPP attributes, if the implementation cannot
determine the correct value for this attribute, it SHOULD respond
with the out-of-band ...
... provides detailed status about the print job, the implementation MAY
set the IPP Job object's state to 'completed', provided that it also
sets the 'queued-in-device' value in the job's "job-state ...
... Job Retention: When a job enters one of the three terminal job
states: 'completed', 'canceled', or 'aborted', the IPP Printer
object MAY "retain" the job in a restartable condition for an
implementation-defined ...
... restart the job using the
Restart-Job operation. If the IPP object supports the Restart-Job
operation, then it SHOULD indicate that the job is restartable by
...
... implementation-defined time, such as when the number of jobs exceeds
a fixed number or after a fixed time period (which MAY be zero
seconds), the IPP Printer removes the job from the system.
...
... security policy, in effect, everyone is an operator as far as
canceling jobs with IPP is concerned. This value SHOULD be
supported if the implementation permits canceling by other than
the owner of the job.
...
... If the implementation requires some measurable time to cancel
the job in the 'processing' or 'processing-stopped' job states,
the IPP object MUST use this value to indicate that the Printer
object is still performing some actions on the job while the
job remains in the 'processing' or 'processing-stopped' state ...
... operation (see section 3.3.7). If 'job-restartable' is a value
of the job's 'job-state-reasons' attribute, then the IPP object
MUST accept a Restart-Job operation for that job. This value
...
... time at which certain events occur for a job. If the job event has
not yet occurred, then the IPP object MUST return the 'no-value'
out-of-band value (see the beginning of Section 4.1). The "time-at-
...
... charset is implementation-defined. The IPP object MUST convert from
whatever the internal charset is to that being requested in an
...
... Note: How these attributes are set by an Administrator is outside the
scope of this IPP/1.1 document.
+----------------------------+---------------------------+-----------+
...
... URI(s) and configures this attribute to contain those URIs by some
means outside the scope of this IPP/1.1 document. The precise format
of this URI is implementation dependent and depends on the protocol.
...
... channel is secure.
It is expected that many IPP Printer objects will be configured to
support only one channel (either configured to use TLS ...
... The information obtained from this URI is intended for end user
consumption. Features outside the scope of IPP can be accessed from
this URI. The information is intended to be specific to this printer
...
... installer for this Printer object. This attribute is intended for
consumption by automata. The mechanics of print driver installation
is outside the scope of this IPP/1.1 document. The device
manufacturer may initially populate this attribute.
...
... about this type of device. The information obtained from this URI is
intended for end user consumption. Features outside the scope of IPP
can be accessed from this URI (e.g., latest firmware, upgrades, print
...
... NOT update this attribute continually, since asynchronous event
notification is not part of IPP/1.1. A Printer NEED NOT implement
all values if they are not applicable to a given implementation.
...
...
This REQUIRED attribute identifies the IPP protocol version(s) that
this Printer supports, including major and minor versions ...
...
'1.0': Meets the conformance requirement of IPP version 1.0 as
specified in RFC 2566(-> 2911prop) ...
... version or any future version of
the IPP "Model and Semantics" document or the IPP "Encoding ...
... version-number" parameter is '1.0'.
'1.1': Meets the conformance requirement of IPP version 1.1 as
specified in this document and [RFC2910 ...
... extensions registered according to Section 6 and any extension
defined in any future versions of the IPP "Model and Semantics"
document or the IPP ...
... the Printer and contained Job objects support in attributes with
attribute syntax 'text' and 'name'. At least the value 'utf-8' MUST
be present, since IPP objects MUST support the UTF-8 [RFC2279]
...
... charset. If a Printer object supports a charset, it means that for
all attributes of syntax 'text' and 'name' the IPP object MUST (1)
accept the charset in requests and return the charset ...
... If more charsets than UTF-8 are supported, the IPP object MUST
perform charset conversion between the charsets ...
... language(s) supported depends on implementation and/or configuration.
Unlike charsets, IPP objects MUST accept requests with any natural
language or any Natural Language ...
... any type of color printing at all, including highlight color. All
document instructions having to do with color are embedded within the
document PDL (none are external IPP attributes in IPP/1.1).
...
... document instructions having to do with color are embedded within the
document PDL (none are external IPP attributes in IPP/1.1).
Note: end-users are able to determine the nature and details of the
...
... This REQUIRED Printer attribute expresses the ability for a
particular Printer implementation to either attempt to override
document data instructions with IPP attributes or not.
This attribute takes on the following keyword values:
...
...
- 'attempted': This value indicates that the Printer object
attempts to make the IPP attribute values take precedence over
embedded instructions in the document data, however there is no
guarantee.
...
... guarantee.
- 'not-attempted': This value indicates that the Printer object
makes no attempt to make the IPP attribute values take
precedence over embedded instructions in the document data.
...
...
Section 15 contains a full description of how this attribute
interacts with and affects other IPP attributes, especially the
"ipp-attribute-fidelity" attribute.
...
... vendors supply a value for this attribute that
is between 60 and 240 seconds. An implementation MAY allow a system
administrator to set this attribute (by means outside this IPP/1.1
document). If so, the system administrator MAY be able to set values
...
... compression does not apply to the encoding of
the IPP operation itself. The supported values are used to validate
the client ...
... 1. contained within software controlled by an end user, e.g.
activated by the "Print" menu item in an application that sends
IPP requests or
2. the print server component that sends IPP ...
... IPP requests or
2. the print server component that sends IPP requests to either an
output device or another "downstream ...
... conformance requirements placed on the user
interfaces provided by IPP clients or their applications. For
example, one application might not allow an end user to submit
multiple documents per job, while another does. One application
...
... whereas a different implementation might not.
When sending a request, an IPP client NEED NOT supply any attributes
that are indicated as OPTIONALLY supplied by the client.
...
... A client MUST support Client Authentication as defined in the IPP/1.1
Encoding and Transport ...
... Operation Privacy and Server Authentication as defined in the IPP/1.1
Encoding and Transport ...
... IPP Object Conformance Requirements ...
... This section specifies the conformance requirements for conforming
implementations of IPP objects (see section 2). These requirements
apply to an IPP ...
... IPP objects (see section 2). These requirements
apply to an IPP object whether it is:
(1) an (embedded) device component that accepts IPP ...
... IPP object whether it is:
(1) an (embedded) device component that accepts IPP requests and
controls the device or
...
... controls the device or
(2) a component of a print server that accepts IPP requests (where
the print server control one or more networked devices using IPP or
...
... (2) a component of a print server that accepts IPP requests (where
the print server control one or more networked devices using IPP or
other protocols).
...
...
Conforming IPP object implementations MUST implement all of the
REQUIRED model operations, including REQUIRED responses, as defined
in this document in the indicated sections:
...
... Restart-Job (section 3.3.7) OPTIONAL
Conforming IPP objects MUST support all REQUIRED operation attributes
and all values of such attributes if so indicated in the description.
...
... operation attributes
and all values of such attributes if so indicated in the description.
Conforming IPP objects MUST ignore all unsupported or unknown
operation attributes or operation attribute ...
... operation attribute that contains an unsupported value.
Conforming IPP objects MAY return operation responses that contain
attributes groups, attributes names, attribute syntaxes, attribute
...
... IPP Object Attributes ...
...
Conforming IPP objects MUST support all of the REQUIRED object
attributes, as defined in this document in the indicated sections.
...
... clients
specified in this document and [RFC2910]. IPP/1.1 clients MUST send
requests containing a "version ...
... version-number" parameter with a '1.1' value.
IPP/1.1 Printer and Job objects MUST meet the conformance
requirements for IPP objects specified in this document and
...
... IPP/1.1 Printer and Job objects MUST meet the conformance
requirements for IPP objects specified in this document and
[RFC2910]. IPP ...
... IPP objects specified in this document and
[RFC2910]. IPP/1.1 objects MUST accept requests containing a
"version-number" parameter with a '1.1' value (or reject the request
...
... It is beyond the scope of this specification to mandate conformance
with previous versions. IPP/1.1 was deliberately designed, however,
to make supporting previous versions easy. It is worth noting that,
...
... versions easy. It is worth noting that,
at the time of composing this specification (1999), we would expect
IPP/1.1 Printer implementations to:
understand any valid ...
...
understand any valid request in the format of IPP/1.0, or 1.1;
respond appropriately with a response containing the same
...
... IPP/1.0, or 1.1.
It is recommended that IPP/1.1 clients try supplying alternate
version numbers ...
...
For each attribute included in an operation response, a conforming
IPP object MUST return a value whose type and value syntax conforms
to the requirement ...
...
An IPP object MUST be able to accept any of the attribute syntaxes
defined in Section 4.1, including their full range, in any operation
...
... client may supply attributes or the system administrator
may configure attributes (by means outside the scope of this IPP/1.1
document). In particular for each attribute that the IPP object
...
... may configure attributes (by means outside the scope of this IPP/1.1
document). In particular for each attribute that the IPP object
supports whose attribute syntax is 'text', the IPP object MUST accept
...
... document). In particular for each attribute that the IPP object
supports whose attribute syntax is 'text', the IPP object MUST accept
and process both the 'textWithoutLanguage' and 'textWithLanguage'
forms. Similarly, for each attribute that the IPP ...
... IPP object MUST accept
and process both the 'textWithoutLanguage' and 'textWithLanguage'
forms. Similarly, for each attribute that the IPP object supports
whose attribute syntax is 'name', the IPP object MUST accept and
...
... forms. Similarly, for each attribute that the IPP object supports
whose attribute syntax is 'name', the IPP object MUST accept and
process both the 'nameWithoutLanguage' and 'nameWithLanguage' forms.
Furthermore, an IPP ...
... IPP object MUST accept and
process both the 'nameWithoutLanguage' and 'nameWithLanguage' forms.
Furthermore, an IPP object MUST return attributes to the client in
operation responses that conform to the syntax specified in Section
...
...
An IPP Printer implementation SHOULD contain support for Client
Authentication as defined in the IPP/1.1 Encoding ...
... An IPP Printer implementation SHOULD contain support for Client
Authentication as defined in the IPP/1.1 Encoding and Transport
...
... authenticated. See also section 8 of this document.
An IPP Printer implementation SHOULD contain support for Operation
Privacy and Server Authentication ...
... client supplies a lower
"version-number" parameter in a request. For example, if an IPP/1.1
conforming Printer object accepts version '1.0' requests and is
...
... defined in section 4.1.7.
IPP objects MUST be able to accept any client request which correctly
uses the "attributes-natural-language ...
... Language Override mechanism on any individual attribute
whether or not the natural language is supported by the IPP object.
If an IPP object supports a natural language ...
... language is supported by the IPP object.
If an IPP object supports a natural language, then it MUST be able to
translate (perhaps by table lookup ...
... attribute values into one of the supported languages (see section
3.1.4). That is, the IPP object that supports a natural language
NEED NOT be a general purpose translator of any arbitrary 'text' or
...
... IETF standards track extensions and vendor extensions to
the IPP/1.1 Model and Semantics document:
...
... out-of-band attribute values
Extensions registered for use with IPP/1.1 are OPTIONAL for client
and IPP ...
... IPP/1.1 are OPTIONAL for client
and IPP object conformance to the IPP/1.1 "Model and Semantics"
...
... client
and IPP object conformance to the IPP/1.1 "Model and Semantics"
document (this document).
...
... IANA will reject registration
proposals that leave out required information or do not follow the
appropriate format described in Section 11. The IPP/1.1 Model and
Semantics document may also be extended by an appropriate RFC that
...
...
IPP allows for 'keyword' and 'enum' extensions (see sections 4.1.2.3
and 4.1.4). This document uses prefixes to the 'keyword' and 'enum'
...
... meaning.
"type1": This IPP specification document must be revised (or
another IETF standards track document which augments this
...
... IANA will forward the registration proposal to the IPP
Designated Expert who will review the proposal with a mailing
list ...
... Designated Expert keeps for this purpose.
Initially, that list will be the mailing list used by the IPP
WG:
...
... Designated Expert is appointed by the IESG Area
Director responsible for IPP, according to [IANA-CON].
...
... IANA-CON].
When a type2 keyword or enum is approved, the IPP Designated
Expert becomes the point of contact for any future maintenance
that might be required for that registration ...
... values by submitting the complete specification to IANA as for
type2 who will forward the proposal to the IPP Designated
Expert. While no additional technical review is required, the
IPP ...
... IPP Designated
Expert. While no additional technical review is required, the
IPP Designated Expert may, at his/her discretion, forward the
proposal to the same mailing list ...
... for advice and comment.
When a type3 keyword or enum is approved by the IPP Designated
Expert, the original proposer becomes the point of contact for
any future maintenance that might be required for that
...
... technical review.
After type2 and type3 enums specifications are approved, the IPP
Designated Expert in consultation with IANA ...
... value MAY be registered in a type 1 manner (by being included in a
future version of an IPP specification), however, it is NOT REQUIRED.
This document defines keyword and enum values for all of the above
...
... vendor extension.
For attribute syntaxes, the IPP Designated Expert in consultation
with IANA ...
... "operations-supported" Printer attribute.
For operations, the IPP Designated Expert in consultation with IANA
...
... client-error" - The request contains bad syntax or cannot be
fulfilled
"server-error" - The IPP object failed to fulfill an apparently
valid request
...
... charset and natural language for attributes
returned by the IPP object in operation responses (as described
in Section 3.1.4.1).
...
... described section 4.1.1.2 and 4.1.2.2 respectively.
All IPP objects MUST support the UTF-8 [RFC2279] charset ...
... RFC2279] charset in all
'text' and 'name' attributes supported. If an IPP object supports
more than the UTF-8 charset ...
... charset to the client according to
Section 3.1.4.2. If an IPP object supports more than one natural
language, the object SHOULD return 'text' and 'name' values in the
...
... charsets.
If a charset is supported, the IPP object MUST be capable of
converting to and from that charset into any other supported charset ...
... charset into any other supported charset.
In many cases, an IPP object will support only one charset and it
MUST be the UTF-8 ...
... charset which is the native charset given the current configuration
of the IPP object (administrator defined).
...
... client supplied 'text' and 'name' attributes. For client supplied
'text' and 'name' attributes, an IPP object MUST accept ALL supplied
natural languages. Just because a Printer object is currently
...
... language for generated messages which is the native
natural language given the current configuration of the IPP object
(administrator defined).
...
... object's "job-name" and "job-originating-user-name"
attributes). The IPP object MUST accept these attributes in
any natural language no matter what the set of supported
...
... must be reported using the Natural Language Override mechanism.
5. Some attributes are generated by the IPP object (e.g., the Job
object's "job-state-message" attribute, the Printer object's
...
... client requests some natural language for these attributes
other than one of the supported values, the IPP object SHOULD
respond using the value of the "natural-language-configured"
...
... It is difficult to anticipate the security risks that might exist in
any given IPP environment. For example, if IPP is used within a given
corporation over a private network ...
... security risks that might exist in
any given IPP environment. For example, if IPP is used within a given
corporation over a private network, the risks of exposing document
...
...
Furthermore, the value of the information being printed may vary from
one IPP environment to the next. Printing payroll checks, for
example, would have a different value than printing public
information from a file. There is also the possibly of denial-of-
...
... Once the authenticated identity of the requester has been supplied to
the IPP object, the object uses that identity to enforce any
authorization policy ...
... policy might be that only the job owner is allowed to cancel a job.
The details and mechanisms to set up a particular access control
policy are not part of IPP/1.1, and must be established via some
other type of administrative or access control framework ...
... framework. However,
there are operation status codes that allow an IPP server to return
information back to a client about any potential access control ...
...
Since the security levels or the specific threats that an IPP system
administrator may be concerned with cannot be anticipated, IPP MUST
...
... security levels or the specific threats that an IPP system
administrator may be concerned with cannot be anticipated, IPP MUST
be capable of operating with different security mechanisms and
...
...
The following sections describe specific security attacks for IPP
environments. Where examples are provided they should be considered
illustrative of the environment and not an exhaustive set. Not all of
...
... illustrative of the environment and not an exhaustive set. Not all of
these environments will necessarily be addressed in initial
implementations of IPP.
...
...
In many IPP operations, a client supplies a list of attributes to be
returned in the response. For security ...
... client supplies a list of attributes to be
returned in the response. For security reasons, an IPP object may be
configured not to return all attributes (or all values) that a client
requests. The job attributes returned MAY depend on whether the
...
... client
requests. The job attributes returned MAY depend on whether the
requesting user is the same as the user that submitted the job. The
IPP object MAY even return none of the requested attributes. In such
cases, the status returned is the same as if the object had returned
all requested attributes. The client ...
... is intended to be an operator or administrator of the Printer object
(see section 1). Otherwise, the IPP Printer MUST reject the
operation and return: 'client-error-forbidden', 'client ...
...
If the device that an IPP Printer is representing is able to accept
jobs using other job submission protocols in addition to IPP ...
... IPP Printer is representing is able to accept
jobs using other job submission protocols in addition to IPP, it is
RECOMMENDED that such an implementation at least allow such "foreign"
jobs to be queried using Get-Jobs returning "job-id" and "job-uri" as
...
... 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'. 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 ...
... IPP job attributes as for IPP jobs. The IPP object returns the
'unknown' out-of-band value for any requested attribute of a foreign
...
... 'unknown' out-of-band value for any requested attribute of a foreign
job that is supported for IPP jobs, but not for foreign jobs.
It is further RECOMMENDED, that the IPP Printer ...
... IPP jobs, but not for foreign jobs.
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 ...
... "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 ...
... 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
...
... 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 ...
... been authenticated as an operator or administrator of the IPP Printer
object, could the foreign jobs be queried by an IPP request.
...
... 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.
...
... Herriot, R., Hastings, T., Jacobs, N. and J. Martin, "Mapping between LPD and IPP Protocols", RFC 2569exp, April 1999. ...
... Implementers of this specification document are encouraged to join
IPP Mailing List in order to participate in any discussions of
...
... Formats for IPP Registration Proposals ...
...
In order to propose an IPP extension for registration, the proposer
must submit an application to IANA ...
... information and the formats for proposing registrations of extensions
to IPP as provided in Section 6 for:
1. type2 'keyword' attribute values
...
... Name of attribute to which this keyword specification is to be added:
Proposed keyword name of this keyword value:
Specification of this keyword value (follow the style of IPP Model
Section 4.1.2.3):
Name of proposer:
...
... Name of attribute to which this keyword specification is to be added:
Proposed keyword name of this keyword value:
Specification of this keyword value (follow the style of IPP Model
Section 4.1.2.3):
Name of proposer:
...
... Name of attribute to which this enum specification is to be added:
Keyword symbolic name of this enum value:
Numeric value (to be assigned by the IPP Designated Expert in
consultation with IANA ...
... IANA):
Specification of this enum value (follow the style of IPP Model
Section 4.1.4):
Name of proposer:
...
... Name of attribute to which this enum specification is to be added:
Keyword symbolic name of this enum value:
Numeric value (to be assigned by the IPP Designated Expert in
consultation with IANA ...
... consultation with IANA):
Specification of this enum value (follow the style of IPP Model
Section 4.1.4):
Name of proposer:
...
... If this is a Job Template attribute, how does its specification depend
on the value of the "multiple-document-handling" attribute:
Specification of this attribute (follow the style of IPP Model Section
4.2):
Name of proposer:
...
... Email address of proposer:
Note: For attributes, the IPP Designated Expert will be the point of
contact for the approved registration ...
... Numeric tag according to [RFC2910] (to be assigned by the IPP
Designated Expert in consultation with IANA ...
... Designated Expert in consultation with IANA):
Specification of this attribute (follow the style of IPP Model Section
4.1):
Name of proposer:
...
... Email address of proposer:
Note: For attribute syntaxes, the IPP Designated Expert will be the
point of contact for the approved registration ...
... Proposed name of this operation:
Numeric operation-id value according to section 4.4.15 (to be assigned
by the IPP Designated Expert in consultation with IANA):
...
... Object Target (Job, Printer, etc. that operation is upon):
Specification of this operation (follow the style of IPP Model Section
3):
Name of proposer:
...
... Email address of proposer:
Note: For operations, the IPP Designated Expert will be the point of
contact for the approved registration ...
... Numeric tag according to [RFC2910] (to be assigned by the IPP
Designated Expert in consultation with IANA ...
... group occurs:
Specification of this attribute group (follow the style of IPP Model
Section 3):
Name of proposer:
...
...
Note: For attribute groups, the IPP Designated Expert will be the
point of contact for the approved registration ...
... Keyword symbolic name of this status code value:
Numeric value (to be assigned by the IPP Designated Expert in
consultation with IANA ...
... status code may be used with:
Specification of this status code (follow the style of IPP Model
Section 13 APPENDIX B: Status Codes and Suggested Status Code ...
... Numeric tag according to [RFC2910] (to be assigned by the IPP Designated
Expert in consultation with IANA):
...
... Specification of this out-of-band attribute value (follow the style of
the beginning of IPP Model Section 4.1):
Name of proposer:
Address ...
...
Note: For out-of-band attribute values, the IPP Designated Expert
will be the point of contact for the approved registration ...
...
An attribute is an item of information that is associated with an
instance of an IPP object. An attribute consists of an attribute
name and one or more attribute values. Each attribute has a specific
attribute syntax. All object attributes ...
... Printer object supports an attribute value if the value is one of the
Printer object's "supported values" attributes. The device behind a
Printer object may exhibit a behavior that corresponds to some IPP
attribute, but if the Printer object, when queried for that
attribute, doesn't respond with the attribute, then as far as IPP ...
... IPP
attribute, but if the Printer object, when queried for that
attribute, doesn't respond with the attribute, then as far as IPP is
concerned, that implementation does not support that feature. If the
Printer object's "xxx-supported" attribute is not populated with a
...
...
A conforming implementation MUST support all REQUIRED attributes.
However, even for REQUIRED attributes, conformance to IPP does not
mandate that all implementations support all possible values
representing all possible job processing behaviors and features. For
...
... that attribute. This limited set of values represents the Printer's
set of supported document formats. Supporting an attribute and some
set of values for that attribute enables IPP end users to be aware of
and make use of those features associated with that attribute and
those values. If an implementation chooses to not support an
...
... and make use of those features associated with that attribute and
those values. If an implementation chooses to not support an
attribute or some specific value, then IPP end users would have no
ability to make use of that feature within the context of IPP ...
... IPP end users would have no
ability to make use of that feature within the context of IPP itself.
However, due to existing practice and legacy systems which are not
...
... However, due to existing practice and legacy systems which are not
IPP aware, there might be some other mechanism outside the scope of
IPP to control or request the "unsupported" feature (such as embedded
...
... IPP aware, there might be some other mechanism outside the scope of
IPP to control or request the "unsupported" feature (such as embedded
instructions within the document data itself).
...
... value of 'staple'.
2) A Printer object is physically capable of stapling, however an
implementation chooses not to support stapling in the IPP
"finishings" attribute. In this case, 'staple' MUST NOT be a
value in the "finishings-supported" Printer object attribute ...
... value in the "finishings-supported" Printer object attribute.
Without support for the value 'staple', an IPP end user would
have no means within the protocol itself to request that a Job
be stapled. However, an existing document data formatter might
...
... be able to request that the document be stapled directly with
an embedded instruction within the document data. In this
case, the IPP implementation does not "support" stapling,
however the end user is still able to have some control over
the stapling of the completed job.
...
... the stapling of the completed job.
3) A Printer object is physically capable of stapling, and an
implementation chooses to support stapling in the IPP
"finishings" attribute. In this case, 'staple' MUST be a value
in the "finishings-supported" Printer object attribute ...
... object attribute. Doing
so, would enable end users to be aware of and make use of the
stapling feature using IPP attributes.
Even though support for Job Template attributes by a Printer object
...
... is OPTIONAL, it is RECOMMENDED that if the device behind a Printer
object is capable of realizing any feature or function that
corresponds to an IPP attribute and some associated value, then that
implementation SHOULD support that IPP attribute and value.
...
... corresponds to an IPP attribute and some associated value, then that
implementation SHOULD support that IPP attribute and value.
The set of values in any of the supported value attributes is set
...
... The set of values in any of the supported value attributes is set
(populated) by some administrative process or automatic sensing
mechanism that is outside the scope of this IPP/1.1 document. For
administrative policy and control reasons, an administrator may
...
... choose to make only a subset of possible values visible to the end
user. In this case, the real output device behind the IPP Printer
abstraction may be capable of a certain feature, however an
administrator ...
... administrator is specifying that access to that feature not be
exposed to the end user through the IPP protocol. Also, since a
Printer object may represent a logical print device (not just a
physical ...
... user. Since the status message is an OPTIONAL component of the
operation response, an IPP application (i.e., a browser, GUI, print
driver or gateway ...
... client-error" - The request contains bad syntax or cannot be
fulfilled
"server-error" - The IPP object failed to fulfill an apparently
valid request
...
... As with type2 enums, IPP status codes are extensible. IPP clients
are NOT REQUIRED to understand the meaning of all registered status
codes, though such understanding is obviously desirable. However,
...
... are NOT REQUIRED to understand the meaning of all registered status
codes, though such understanding is obviously desirable. However,
IPP clients MUST understand the class of any status code, as
...
... client-
error-bad-request" status code. In such cases, IPP applications
SHOULD present the OPTIONAL message (if present) to the end user
since the message is likely to contain human readable information
...
... Implementer's Guide [IPP-IIG] describe the suggested steps for
processing IPP attributes for all operations, including returning
status codes.
...
... requested-attributes" operation attribute are
requesting attributes that are not supported, the IPP object MAY, but
is NOT REQUIRED to, return the "requested-attributes" attribute in
...
... status code is intended for cases in which the client
seems to have erred. The IPP object SHOULD return a message
containing an explanation of the error situation and whether it is a
temporary or permanent condition.
...
...
The request could not be understood by the IPP object due to
malformed syntax (such as the value of a fixed length attribute whose
length does not match the prescribed length for that attribute - see
...
... the Implementer's Guide [IPP-IIG] ). The IPP application SHOULD NOT
repeat the request without modifications.
...
...
The IPP object understood the request, but is refusing to fulfill it.
Additional authentication information or authorization ...
... credentials
will not help and the request SHOULD NOT be repeated. This status
code is commonly used when the IPP object does not wish to reveal
exactly why the request has been refused or when no other response is
applicable.
...
...
The request requires user authentication. The IPP client may repeat
the request with suitable authentication information. If the request
...
... and the request SHOULD NOT be repeated. This status code is used
when the IPP object wishes to reveal that the authentication
information is understandable, however, the requester is explicitly
not authorized to perform the request. This status codes ...
... status code is used when the request is for something that can
not happen. For example, there might be a request to cancel a job
that has already been canceled or aborted by the system. The IPP
client SHOULD NOT repeat the request.
...
...
The client did not produce a request within the time that the IPP
object was prepared to wait. For example, a client issued a Create ...
... Document operation and this error status code was returned in
response to the Send-Document request (see section 3.3.1). The IPP
object might have been forced to clean up resources that had been
held for the waiting additional Documents. The IPP ...
... IPP
object might have been forced to clean up resources that had been
held for the waiting additional Documents. The IPP object was forced
to close the Job since the client took too long. The client ...
...
The IPP object has not found anything matching the request URI. No
indication is given of whether the condition is temporary or
...
... the document can not be found.
In practice, an IPP application should avoid a not found situation by
first querying and presenting a list of valid Printer URIs ...
... delete references to the
request URI after user approval. If the IPP object does not know or
has no facility to determine, whether or not the condition is
permanent, the status code ...
... by notifying the recipient that the resource is intentionally
unavailable and that the IPP object administrator desires that remote
links ...
... permanently unavailable resources as "gone" or to keep the mark for
any length of time -- that is left to the discretion of the IPP
object administrator and/or Printer implementation.
...
...
The IPP object is refusing to process a request because the request
entity is larger than the IPP ...
... IPP object is refusing to process a request because the request
entity is larger than the IPP object is willing or able to process.
An IPP Printer returns this status code ...
... entity is larger than the IPP object is willing or able to process.
An IPP Printer returns this status code when it limits the size of
print jobs and it receives a print job ...
... of the client-supplied attributes has a variable length value that is
longer than the maximum length specified for that attribute. The IPP
object might not have sufficient resources (memory, buffers, etc.) to
...
... than the maximum length. Another use of this error code is when the
IPP object supports the processing of a large value that is less than
the maximum length, but during the processing of the request as a
whole, the object may pass the value onto some other system component
...
... client has improperly submitted a request
with long query information (e.g. an IPP application allows an end-
user to enter an invalid URI), when the client ...
... prefix that
points to a suffix of itself), or when the IPP object is under attack
by a client ...
... by a client attempting to exploit security holes present in some IPP
objects using fixed-length buffers for reading or manipulating the
...
...
The IPP object is refusing to service the request because the
document data is in a format, as specified in the "document-format"
...
... Jobs, Get-Printer-Attributes, or Get-Job-Attributes operation), if
the IPP object does not support one or more of the requested
attributes, the IPP object simply ignores the unsupported requested
...
... the IPP object does not support one or more of the requested
attributes, the IPP object simply ignores the unsupported requested
attributes and processes the request as if they had not been
supplied, rather than returning this status code ...
... supplied, rather than returning this status code. In this case, the
IPP object MUST return the 'successful-ok-ignored-or-substituted-
attributes' status code and MAY return the unsupported attributes as
...
...
The IPP object is refusing to service the request because the
document data, as specified in the "compression ...
...
The IPP object is refusing to service the request because the
document data cannot be decompressed when using the algorithm ...
...
The IPP object is refusing to service the request because Printer
encountered an error in the document data while interpreting it.
...
... This class of status codes indicates cases in which the IPP object is
aware that it has erred or is incapable of performing the request.
The IPP ...
... IPP object is
aware that it has erred or is incapable of performing the request.
The IPP object SHOULD include a message containing an explanation of
the error situation, and whether it is a temporary or permanent
condition.
...
...
The IPP object encountered an unexpected condition that prevented it
from fulfilling the request. This error status code differs from
...
...
The IPP object does not support the functionality required to fulfill
the request. This is the appropriate response when the IPP object
...
... The IPP object does not support the functionality required to fulfill
the request. This is the appropriate response when the IPP object
does not recognize an operation or is not capable of supporting it.
See sections 3.1.6.1 and 3.1.7.
...
...
The IPP object is currently unable to handle the request due to a
temporary overloading or maintenance of the IPP object. The
...
... The IPP object is currently unable to handle the request due to a
temporary overloading or maintenance of the IPP object. The
implication is that this is a temporary condition which will be
alleviated after some delay. If known, the length of the delay may be
...
... implication is that this is a temporary condition which will be
alleviated after some delay. If known, the length of the delay may be
indicated in the message. If no delay is given, the IPP application
should handle the response as it would for a "server-error-
temporary-error" response. If the condition is more permanent, the
...
...
The IPP object does not support, or refuses to support, the IPP
protocol version that was supplied as the value of the "version ...
... version that was supplied as the value of the "version-
number" operation parameter in the request. The IPP object is
indicating that it is unable or unwilling to complete the request
using the same major and minor version number ...
... version is not supported and what other versions are
supported by that IPP object. See sections 3.1.6.1, 3.1.7, and
3.1.8.
...
... version-number" operation
parameter the closest version number that the IPP object does
support. For example, if a client supplies version ...
... client supplies version '1.0' and an
IPP/1.1 object supports version '1.0', then it responds with version
...
... version '1.0', then it responds with version
'1.0' in all responses to such a request. If the IPP/1.1 object does
not support version '1.0', then it should accept the request and
...
... '1.1'. If a client supplies a version '1.2', the IPP/1.1 object
should accept the request and return version '1.1' or may reject the
...
...
A printer error, such as a paper jam, occurs while the IPP object
processes a Print or Send operation. The response contains the true
Job Status (the values of the "job-state ...
... buffer full write error, a memory
overflow (i.e. the document data exceeds the memory of the Printer),
or a disk full condition, occurs while the IPP Printer processes an
operation. The client MAY try the unmodified request again at some
...
... administrator has set the value of the
Printer's "printer-is-accepting-jobs" attribute to 'false' (by means
outside the scope of this IPP/1.1 document).
...
... the system while the client was transmitting the data to the IPP
Printer. If a job-id and job-uri had been created, then they are
returned in the Print-Job ...
...
The IPP object does not support multiple documents per job and a
client attempted to supply document data with a second Send-Document
...
... Status Codes for IPP Operations ...
... Get-Printer-Attributes, GJ = Get-Jobs, C = Cancel-Job
IPP Operations
IPP Status Keyword PJ PU CJ SD ...
... IPP Operations
IPP Status Keyword PJ PU CJ SD SU V GA GJ C
------------------ -- -- -- -- -- - -- -- -
...
... APPENDIX D: Processing IPP Attributes ...
...
When submitting a print job to a Printer object, the IPP model allows
a client to supply operation and Job Template attributes along with
...
...
The following sections describe how these two types of conflicts are
handled in the IPP model.
...
... ignored."
The IPP model accounts for this situation by introducing an "ipp-
attribute-fidelity" attribute.
...
...
If there is a conflict between the value of an IPP Job Template
attribute and a corresponding instruction in the document data, the
value of the IPP ...
... IPP Job Template
attribute and a corresponding instruction in the document data, the
value of the IPP attribute SHOULD take precedence over the document
instruction. Consider the case where a previously formatted file of
document data is sent to an IPP Printer ...
... IPP attribute SHOULD take precedence over the document
instruction. Consider the case where a previously formatted file of
document data is sent to an IPP Printer. In this case, if the client
supplies any attributes at job submission time, the client ...
... an end user that only has access to a printer with 'na-letter' media
loaded. That end user most likely wants to submit that document to
an IPP Printer with the "media" Job Template attribute set to 'na-
letter'. The job submission attribute should take precedence over
the embedded PDL instruction. However, until companies ...
... the embedded PDL instruction. However, until companies that supply
document data interpreters allow a way for external IPP attributes to
take precedence over embedded job production instructions, a Printer
might not be able to support the semantics ...
... take precedence over embedded job production instructions, a Printer
might not be able to support the semantics that IPP attributes
override the embedded instructions.
...
... override the embedded instructions.
The IPP model accounts for this situation by introducing a "pdl-
override-supported" attribute that describes the Printer objects
capabilities to override instructions embedded in the PDL data
stream ...
... capabilities to override instructions embedded in the PDL data
stream. The value of the "pdl-override-supported" attribute is
configured by means outside the scope of this IPP/1.1 document.
This REQUIRED Printer attribute takes on the following values:
...
...
- 'attempted': This value indicates that the Printer object
attempts to make the IPP attribute values take precedence over
embedded instructions in the document data, however there is no
guarantee.
...
... guarantee.
- 'not-attempted': This value indicates that the Printer object
makes no attempt to make the IPP attribute values take
precedence over embedded instructions in the document data.
...
... 1) Generate an output device specific command sequence to realize
the feature represented by the IPP attribute value.
2) Parse the document data itself and replace the conflicting
embedded instruction with a new embedded instruction that
...
... 2) Parse the document data itself and replace the conflicting
embedded instruction with a new embedded instruction that
matches the intent of the IPP attribute value.
3) Indicate to the Printer that external supplied attributes take
precedence over embedded instructions and then pass the
...
... 3) Indicate to the Printer that external supplied attributes take
precedence over embedded instructions and then pass the
external IPP attribute values to the document data interpreter.
4) Anything else that allows for the semantics that IPP ...
... IPP attribute values to the document data interpreter.
4) Anything else that allows for the semantics that IPP attributes
override embedded document data instructions.
...
... Since 'attempted' does not offer any type of guarantee, even though a
given Printer object might not do a very "good" job of attempting to
ensure that IPP attributes take a higher precedence over instructions
embedded in the document data, it would still be a conforming
implementation.
...
... instruction with a new embedded instruction that approximates,
but does not match, the semantic intent of the IPP attribute
value.
...
... ability of the Printer to override the instructions embedded in the
document data with the semantics of the IPP attributes. If the
document data attributes can be overridden ("pdl-override-supported"
set to 'attempted'), the Printer makes an attempt to use the IPP ...
... IPP attributes. If the
document data attributes can be overridden ("pdl-override-supported"
set to 'attempted'), the Printer makes an attempt to use the IPP
attributes when processing the Job. If the document data attributes
can not be overridden ("pdl-override-supported" set to 'not-
...
... can not be overridden ("pdl-override-supported" set to 'not-
attempted'), the Printer makes no attempt to override the embedded
document data instructions with the IPP attributes when processing
the Job, and hence, the IPP attributes may fail to affect the Job
...
... document data instructions with the IPP attributes when processing
the Job, and hence, the IPP attributes may fail to affect the Job
processing and output when the corresponding instruction is embedded
in the document data.
...
... service users can
locate service providers. In IPP environments, this means that IPP
Printers can be registered (either automatically or with the help of
an administrator ...
... locate service providers. In IPP environments, this means that IPP
Printers can be registered (either automatically or with the help of
an administrator) as entries of type printer in the directory using
...
... that they are only allowed to find entries to which they have certain
access rights. IPP itself does not require any specific directory
service protocol or provider.
...
... In each case, each alias refers to the same directory entry object
which refers to a single IPP Printer object.
The generic schema is a subset of IPP Printer ...
... IPP Printer object.
The generic schema is a subset of IPP Printer Job Template and
Printer Description attributes (sections 4.2 and 4.4). These
attributes are identified as either RECOMMENDED or OPTIONAL for the
...
... attributes are identified as either RECOMMENDED or OPTIONAL for the
directory entry itself. This conformance labeling is NOT the same
conformance labeling applied to the attributes of IPP Printers
objects. The conformance labeling in this Appendix is intended to
apply to directory templates and to IPP Printer ...
... IPP Printers
objects. The conformance labeling in this Appendix is intended to
apply to directory templates and to IPP Printer implementations that
subscribe by adding one or more entries to a directory. RECOMMENDED
...
... The names of attributes in directory schema and entries SHOULD be the
same as the IPP Printer attribute names as shown, as much as
possible.
...
... In order to bridge between the directory service and the IPP Printer
object, one of the RECOMMENDED directory entry attributes is the
Printer object's "printer-uri-supported" attribute. The directory
...
... client queries the "printer-uri-supported" attribute (or its
equivalent) in the directory entry and then the IPP client addresses
the IPP Printer ...
...
This Appendix is divided into two lists that summarize the
differences between IPP/1.1 (this document) and IPP/1.0 [RFC2566].
...
... This Appendix is divided into two lists that summarize the
differences between IPP/1.1 (this document) and IPP/1.0 [RFC2566].
The section numbers refer to the numbers in this document which in
...
... semantics or conformance. However, client
and IPP object implementations of IPP/1.0 MAY implement any of the
extensions and clarifications in this document.
...
... client
and IPP object implementations of IPP/1.0 MAY implement any of the
extensions and clarifications in this document.
...
... contained in software controlled by an end user or a part of a
print server that controls devices.
2. Section 2 - clarified that the term "IPP object" and "Printer
object" can either be embedded in a device object or part of a
print server that accepts IPP ...
... IPP object" and "Printer
object" can either be embedded in a device object or part of a
print server that accepts IPP requests.
3. Section 2.4 - added the description of the new "uri-
authentication ...
... 5. Section 3.1.3 - clarified that multiple occurrences of the
same attribute in an attribute group is mal-formed. An IPP
Printer MAY reject the request or choose one of the
attributes.
6. Section 3.1.6 - reorganized this section into sub-sections to
...
... channel is flow controlled off by the IPP Printer.
63. Section 5.2 - clarified that the IPP object requirements ...
... flow controlled off by the IPP Printer.
63. Section 5.2 - clarified that the IPP object requirements apply
to objects embedded in devices or that are parts of servers.
...
... requirements apply
to objects embedded in devices or that are parts of servers.
64. Section 5.2.2 - clarified that IPP objects MAY return
operation responses that contain attribute groups, attribute
names ...
... media names and drawings for
the synchro cut sizes.
75. Section 16 - softened the RECOMMENDATION for IPP Printer
attributes in a Directory schema so that they can have
...
... meaning of such messages.
2. Section 3.1.8, 5.2.4, and 13.1.5.4 - Clients and IPP objects
MUST support version 1.1 conformance requirements ...
... conformance requirements. It is
recommended that they interoperate with 1.0. Also clarified
that IPP Printers MUST accept '1.1' requests. It is
recommended that they also accept '1.x' requests.
3. Section 3.2.1.1 and section 4.4.32 - changed the "compression ...
... 18. Section 4.4.14 - added the REQUIRED "ipp-versions-supported
(1setOf keyword)" Printer Description attribute, since IPP/1.1
Printers do not have to support version '1.0' conformance
requirements ...
... security requirements from
RECOMMENDED non-standards track SSL3 to MUST support Client
Authentication as defined in the IPP/1.1 Encoding and
Transport ...
... Privacy and Server Authentication as defined in the
IPP/1.1 Encoding and Transport document [RFC2910 ...
... Transport document [RFC2910].
22. Section 5.2.7 - changed the IPP object security requirements
from OPTIONAL non-standards track SSL3 to SHOULD contain
...
... from OPTIONAL non-standards track SSL3 to SHOULD contain
support for Client Authentication as defined in the IPP/1.1
Encoding and Transport ...
... Printer so that all, some, or none of the users are
authenticated. An IPP Printer implementation SHOULD contain
support for Operation Privacy and Server Authentication ...
... Transport" [RFC2910] document for
differences between IPP/1.0 [RFC2565] and IPP/1.1 [RFC2910 ...