RFC2566 - Internet Printing Protocol/1.0: Model and Semantics(5)
0x0000 reserved, not used
0x0001 reserved, not used
0x0002 Print-Job
0x0003 Print-URI
0x0004 Validate-Job
0x0005 Create-Job
0x0006 Send-Document
0x0007 Send-URI
0x0008 Cancel-Job
0x0009 Get-Job-Attributes
0x000A Get-Jobs
0x000B Get-Printer-Attributes
0x000C-0x3FFF reserved for future operations
0x4000-0x8FFF reserved for private extensions
This allows for certain vendors to implement private extensions that
are guaranteed to not conflict with future registered extensions.
However, there is no guarantee that two or more private extensions
will not conflict.
4.4.14 charset-configured (charset)
This REQUIRED Printer attribute identifies the charset that the
Printer object has been configured to represent 'text' and 'name'
Printer attributes that are set by the operator, system
administrator, or manufacturer, i.e., for "printer-name" (name),
"printer-location" (text), "printer-info" (text), and "printer-make-
and-model" (text). Therefore, the value of the Printer object's
"charset-configured" attribute MUST also be among the values of the
Printer object's "charset-supported" attribute.
4.4.15 charset-supported (1setOf charset)
This REQUIRED Printer attribute identifies the set of charsets that
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 in responses as
needed.
If more charsets than UTF-8 are supported, the IPP object MUST
perform charset conversion between the charsets as described in
Section 3.2.1.2.
4.4.16 natural-language-configured (naturalLanguage)
This REQUIRED Printer attribute identifies the natural language that
the Printer object has been configured to represent 'text' and 'name'
Printer attributes that are set by the operator, system
administrator, or manufacturer, i.e., for "printer-name" (name),
"printer-location" (text), "printer-info" (text), and "printer-make-
and-model" (text). When returning these Printer attributes, the
Printer object MAY return them in the configured natural language
specified by this attribute, instead of the natural language
requested by the client in the "attributes-natural-language"
operation attribute. See Section 3.1.4.1 for the specification of
the OPTIONAL multiple natural language support. Therefore, the value
of the Printer object's "natural-language-configured" attribute MUST
also be among the values of the Printer object's "generated-natural-
language-supported" attribute.
4.4.17 generated-natural-language-supported (1setOf naturalLanguage)
This REQUIRED Printer attribute identifies the natural language(s)
that the Printer object and contained Job objects support in
attributes with attribute syntax 'text' and 'name'. The natural
language(s) supported depends on implementation and/or configuration.
Unlike charsets, IPP objects MUST accept requests with any natural
language or any Natural Language Override whether the natural
language is supported or not.
If a Printer object supports a natural language, it means that for
any of the attributes for which the Printer or Job object generates
messages, i.e., for the "job-state-message" and "printer-state-
message" attributes and Operation Messages (see Section 3.1.5) in
operation responses, the Printer and Job objects MUST be able to
generate messages in any of the Printer's supported natural
languages. See section 3.1.4 for the specification of 'text' and '
name' attributes in operation requests and responses.
Note: A Printer object that supports multiple natural languages,
often has separate catalogs of messages, one for each natural
language supported.
4.4.18 document-format-default (mimeMediaType)
This REQUIRED Printer attribute identifies the document format that
the Printer object has been configured to assume if the client does
not supply a "document-format" operation attribute in any of the
operation requests that supply document data. The standard values
for this attribute are Internet Media types (sometimes called MIME
types). For further details see the description of the '
mimeMediaType' attribute syntax in Section 4.1.9.
4.4.19 document-format-supported (1setOf mimeMediaType)
This REQUIRED Printer attribute identifies the set of document
formats that the Printer object and contained Job objects can
support. For further details see the description of the '
mimeMediaType' attribute syntax in Section 4.1.9.
4.4.20 printer-is-accepting-jobs (boolean)
This REQUIRED Printer attribute indicates whether the printer is
currently able to accept jobs, i.e., is accepting Print-Job, Print-
URI, and Create-Job requests. If the value is 'true', the printer is
accepting jobs. If the value is 'false', the Printer object is
currently rejecting any jobs submitted to it. In this case, the
Printer object returns the 'server-error-not-accepting-jobs' status
code.
Note: This value is independent of the "printer-state" and "printer-
state-reasons" attributes because its value does not affect the
current job; rather it affects future jobs. This attribute may cause
the Printer to reject jobs when the "printer-state" is 'idle' or it
may cause the Printer object to accepts jobs when the "printer-state"
is 'stopped'.
4.4.21 queued-job-count (integer(0:MAX))
This RECOMMENDED Printer attribute contains a count of the number of
jobs that are either 'pending', 'processing', 'pending-held', or '
processing-stopped' and is set by the Printer object.
4.4.22 printer-message-from-operator (text(127))
This Printer attribute provides a message from an operator, system
administrator or "intelligent" process to indicate to the end user
information or status of the printer, such as why it is unavailable
or when it is expected to be available.
4.4.23 color-supported (boolean)
This Printer attribute identifies whether the device is capable of
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.0).
Note: end-users are able to determine the nature and details of the
color support by querying the "printer-more-info-manufacturer"
Printer attribute.
4.4.24 reference-uri-schemes-supported (1setOf uriScheme)
This Printer attribute specifies which URI schemes are supported for
use in the "document-uri" operation attribute of the Print-URI or
Send-URI operation. If a Printer object supports these optional
operations, it MUST support the "reference-uri-schemes-supported"
Printer attribute with at least the following schemed URI value:
'ftp': The Printer object will use an FTP 'get' operation as
defined in RFC2228 [RFC2228] using FTP URLs as defined by
[RFC2396] and[RFC2316].
The Printer object MAY OPTIONALLY support other URI schemes (see
section 4.1.6).
4.4.25 pdl-override-supported (type2 keyword)
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 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.
- '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.
4.4.26 printer-up-time (integer(1:MAX))
This REQUIRED Printer attribute indicates the amount of time (in
seconds) that this instance of this Printer implementation has been
up and running. This value is used to populate the Job attributes
"time-at-creation", "time-at-processing", and "time-at-completed".
These time values are all measured in seconds and all have meaning
only relative to this attribute, "printer-up-time". The value is a
monotonically increasing value starting from 1 when the Printer
object is started-up (initialized, booted, etc.).
If the Printer object goes down at some value 'n', and comes back up,
the implementation MAY:
1. Know how long it has been down, and resume at some value greater
than 'n', or
2. Restart from 1.
In the first case, the Printer SHOULD not tweak any existing related
Job attributes ("time-at-creation", "time-at-processing", and "time-
at-completed"). In the second case, the Printer object SHOULD reset
those attributes to 0. If a client queries a time-related Job
attribute and finds the value to be 0, the client MUST assume that
the Job was submitted in some life other than the Printer's current
life.
4.4.27 printer-current-time (dateTime)
This Printer attribute indicates the current absolute wall-clock
time. If an implementation supports this attribute, then a client
could calculate the absolute wall-clock time each Job's "time-at-
creation", "time-at-processing", and "time-at-completed" attributes
by using both "printer-up-time" and this attribute, "printer-
current-time". If an implementation does not support this attribute,
a client can only calculate the relative time of certain events based
on the REQUIRED "printer-up-time" attribute.
4.4.28 multiple-operation-time-out (integer(1:MAX))
This Printer attributes identifies the minimum time (in seconds) that
the Printer object waits for additional Send-Document or Send-URI
operations to follow a still-open multi-document Job object before
taking any recovery actions, such as the ones indicated in section
3.3.1.
It is RECOMMENDED that 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. If so, the system administrator
MAY be able to set values outside this range.
4.4.29 compression-supported (1setOf type3 keyword)
This Printer attribute identifies the set of supported compression
algorithms for document data. Compression only applies to the
document data; compression does not apply to the encoding of the IPP
operation itself. The supported values are used to validate the
client supplied "compression" operation attributes in Print-Job,
Send-Document, and Send-URI requests.
Standard values are :
'none': no compression is used.
'deflate': ZIP public domain inflate/deflate) compression
technology
'gzip' GNU zip compression technology described in RFC1952
[RFC1952].
'compress': UNIX compression technology
4.4.30 job-k-octets-supported (rangeOfInteger(0:MAX))
This Printer attribute specifies the upper and lower bounds of total
sizes of jobs in K octets, i.e., in units of 1024 octets. The
supported values are used to validate the client supplied "job-k-
octets" operation attributes in create requests. The corresponding
job description attribute "job-k-octets" is defined in section
4.3.17.
4.4.31 job-impressions-supported (rangeOfInteger(0:MAX))
This Printer attribute specifies the upper and lower bounds for the
number of impressions per job. The supported values are used to
validate the client supplied "job-impressions" operation attributes
in create requests. The corresponding job description attribute
"job-impressions" is defined in section 4.3.18.
4.4.32 job-media-sheets-supported (rangeOfInteger(0:MAX))
This Printer attribute specifies the upper and lower bounds for the
number of media sheets per job. The supported values are used to
validate the client supplied "job-media-sheets" operation attributes
in create requests. The corresponding Job attribute "job-media-
sheets" is defined in section 4.3.19.
5. Conformance
This section describes conformance issues and requirements. This
document introduces model entities such as objects, operations,
attributes, attribute syntaxes, and attribute values. These
conformance sections describe the conformance requirements which
apply to these model entities.
5.1 Client Conformance Requirements
A conforming client MUST support all REQUIRED operations as defined
in this document. For each attribute included in an operation
request, a conforming client MUST supply a value whose type and value
syntax conforms to the requirements of the Model document as
specified in Sections 3 and 4. A conforming client MAY supply any
registered extensions and/or private extensions in an operation
request, as long as they meet the requirements in Section 6.
Otherwise, there are no 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
might first query a Printer object in order to supply a graphical
user interface (GUI) dialogue box with supported and default values
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 be able to accept any of the attribute syntaxes defined
in Section 4.1, including their full range, that may be returned to
it in a response from a Printer object. In particular for each
attribute that the client supports whose attribute syntax is 'text',
the client MUST accept and process both the 'textWithoutLanguage' and
'textWithLanguage' forms. Similarly, for each attribute that the
client supports whose attribute syntax is 'name', the client MUST
accept and process both the 'nameWithoutLanguage' and '
nameWithLanguage' forms. For presentation purposes, truncation of
long attribute values is not recommended. A recommended approach
would be for the client implementation to allow the user to scroll
through long attribute values.
A query response may contain attribute groups, attributes, and values
that the client does not expect. Therefore, a client implementation
MUST gracefully handle such responses and not refuse to inter-operate
with a conforming Printer that is returning extended registered or
private attributes and/or attribute values that conform to Section 6.
Clients may choose to ignore any parameters, attributes, or values
that they do not understand.
5.2 IPP Object Conformance Requirements
This section specifies the conformance requirements for conforming
implementations with respect to objects, operations, and attributes.
5.2.1 Objects
Conforming implementations MUST implement all of the model objects as
defined in this specification in the indicated sections:
Section 2.1 - Printer Object
Section 2.2 - Job Object
5.2.2 Operations
Conforming IPP object implementations MUST implement all of the
REQUIRED model operations, including REQUIRED responses, as defined
in this specification in the indicated sections:
For a Printer object:
Print-Job (section 3.2.1) REQUIRED
Print-URI (section 3.2.2) OPTIONAL
Validate-Job (section 3.2.3) REQUIRED
Create-Job (section 3.2.4) OPTIONAL
Get-Printer-Attributes (section 3.2.5) REQUIRED
Get-Jobs (section 3.2.6) REQUIRED
For a Job object:
Send-Document (section 3.3.1) OPTIONAL
Send-URI (section 3.3.2) OPTIONAL
Cancel-Job (section 3.3.3) REQUIRED
Get-Job-Attributes (section 3.3.4) REQUIRED
Conforming IPP objects MUST support all REQUIRED 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 groups received in a
request, but MUST reject a request that contains a supported
operation attribute that contains an unsupported value.
The following section on object attributes specifies the support
required for object attributes.
5.2.3 IPP Object Attributes
Conforming IPP objects MUST support all of the REQUIRED object
attributes, as defined in this specification in the indicated
sections.
If an object supports an attribute, it MUST support only those values
specified in this document or through the extension mechanism
described in section 5.2.4. It MAY support any non-empty subset of
these values. That is, it MUST support at least one of the specified
values and at most all of them.
5.2.4 Extensions
A conforming IPP object MAY support registered extensions and private
extensions, as long as they meet the requirements specified in
Section 6.
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 of the Model document as specified in Sections 3
and 4.
5.2.5 Attribute Syntaxes
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
in which a client may supply attributes or the system administrator
may configure attributes (by means outside the scope of IPP/1.0). 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 object supports whose
attribute syntax is 'name', the 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
4.1, including their full range if supplied previously by a client.
5.3 Charset and Natural Language Requirements
All clients and IPP objects MUST support the 'utf-8' charset as
defined in section 4.1.7.
IPP objects MUST be able to accept any client request which correctly
uses the "attributes-natural-language" operation attribute or the
Natural 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, then it MUST be able to
translate (perhaps by table lookup) all generated 'text' or 'name'
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 '
name' value supplied by the client into that natural language.
However, the object MUST be able to translate (automatically
generate) any of its own attribute values and messages into that
natural language.
5.4 Security Conformance Requirements
Conforming IPP Printer objects MAY support Secure Socket Layer
Version 3 (SSL3) [SSL] access, support access without SSL3 or support
both means of access.
Conforming IPP clients SHOULD support SSL3 access and non-SSL3
access. Note: This client requirement to support both means that
conforming IPP clients will be able to inter-operate with any IPP
Printer object.
For a detailed discussion of security considerations and the IPP
application security profile required for SSL3 support, see section
8.
6. IANA Considerations (registered and private extensions)
This section describes how IPP can be extended to allow the following
registered and private extensions to IPP:
1. keyword attribute values
2. enum attribute values
3. attributes
4. attribute syntaxes
5. operations
6. attribute groups
7. status codes
Extensions registered for use with IPP/1.0 are OPTIONAL for client
and IPP object conformance to the IPP/1.0 Model specification.
These extension procedures are aligned with the guidelines as set
forth by the IESG [RFC2434]. Section 11 describes how to propose new
registrations for consideration. IANA will reject registration
proposals that leave out required information or do not follow the
appropriate format described in Section 11. IPP/1.0 may also be
extended by an appropriate RFCthat specifies any of the above
extensions.
6.1 Typed 'keyword' and 'enum' Extensions
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'
basic attribute syntax type in order to communicate extra information
to the reader through its name. This extra information is not
represented in the protocol because it is unimportant to a client or
Printer object. The list below describes the prefixes and their
meaning.
"type1": The IPP specification must be revised to add a new
keyword or a new enum. No private keywords or enums are
allowed.
"type2": Implementers can, at any time, add new keyword or enum
values by proposing the complete specification to IANA:
iana@iana.org
IANA will forward the registration proposal to the IPP
Designated Expert who will review the proposal with a mailing
list that the Designated Expert keeps for this purpose.
Initially, that list will be the mailing list used by the IPP
WG:
ipp@pwg.org
even after the IPP WG is disbanded as permitted by [RFC2434].
The IPP Designated Expert is appointed by the IESG Area Director
responsible for IPP, according to [RFC2434].
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.
"type3": Implementers can, at any time, add new keyword and enum
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 Designated Expert may, at his/her discretion, forward the
proposal to the same mailing list as for type2 registrations 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
registration.
For type2 and type3 keywords, the proposer includes the name of the
keyword in the registration proposal and the name is part of the
technical review.
After type2 and type3 enums specifications are approved, the IPP
Designated Expert in consultation with IANA assigns the next
available enum number for each enum value.
IANA will publish approved type2 and type3 keyword and enum
attributes value registration specifications in:
ftp.isi.edu/iana/assignments/ipp/attribute-values/xxx/yyy.txt
where xxx is the attribute name that specifies the initial values and
yyy.txt is a descriptive file name that contains one or more enums or
keywords approved at the same time. For example, if several
additional enums for stapling are approved for use with the
"finishings" attribute (and "finishings-default" and "finishings-
supported" attributes), IANA will publish the additional values in
the file:
ftp.isi.edu/iana/assignments/ipp/attribute-
values/finishings/stapling.txt
Note: Some attributes are defined to be: 'type3 keywords' 'name'
which allows for attribute values to be extended by a site
administrator with administrator defined names. Such names are not
registered with IANA.
By definition, each of the three types above assert some sort of
registry or review process in order for extensions to be considered
valid. Each higher numbered level (1, 2, 3) tends to be decreasingly
less stringent than the previous level. Therefore, any typeN value
MAY be registered using a process for some typeM where M is less than
N, however such registration is NOT REQUIRED. For example, a type3
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 specification defines keyword and enum values for all of the
above types, including type3 keywords.
For private (unregistered) keyword extensions, implementers SHOULD
use keywords with a suitable distinguishing prefix, such as "xxx-"
where xxx is the (lowercase) fully qualified company name registered
with IANA for use in domain names [RFC1035]. For example, if the
company XYZ Corp. had obtained the domain name "XYZ.com", then a
private keyword 'abc' would be: 'xyz.com-abc'.
Note: RFC1035 [RFC1035] indicates that while upper and lower case
letters are allowed in domain names, no significance is attached to
the case. That is, two names with the same spelling but different
case are to be treated as if identical. Also, the labels in a domain
name must follow the rules for ARPANET host names: They must start
with a letter, end with a letter or digit, and have as interior
characters only letters, digits, and hyphen. Labels must be 63
characters or less. Labels are separated by the "." character.
For private (unregistered) enum extension, implementers MUST use
values in the reserved integer range which is 2**30 to 2**31-1.
6.2 Attribute Extensibility
Attribute names are type2 keywords. Therefore, new attributes may be
registered and have the same status as attributes in this document by
following the type2 extension rules. For private (unregistered)
attribute extensions, implementers SHOULD use keywords with a
suitable distinguishing prefix as described in Section 6.1.
IANA will publish approved attribute registration specifications as
separate files:
ftp.isi.edu/iana/assignments/ipp/attributes/xxx-yyy.txt
where "xxx-yyy" is the new attribute name.
If a new Printer object attribute is defined and its values can be
affected by a specific document format, its specification needs to
contain the following sentence:
"The value of this attribute returned in a Get-Printer-Attributes
response MAY depend on the "document-format" attribute supplied
(see Section 3.2.5.1)."
If the specification does not, then its value in the Get-Printer-
Attributes response MUST NOT depend on the "document-format" supplied
in the request. When a new Job Template attribute is registered, the
value of the Printer attributes MAY vary with "document-format"
supplied in the request without the specification having to indicate
so.
6.3 Attribute Syntax Extensibility
Attribute syntaxes are like type2 enums. Therefore, new attribute
syntaxes may be registered and have the same status as attribute
syntaxes in this document by following the type2 extension rules
described in Section 6.1. The value codes that identify each of the
attribute syntaxes are assigned in the Encoding and Transport
specification [RFC2565], including a designated range for private,
experimental use.
For attribute syntaxes, the IPP Designated Expert in consultation
with IANA assigns the next attribute syntax code in the appropriate
range as specified in [RFC2565]. IANA will publish approved
attribute syntax registration specifications as separate files:
ftp.isi.edu/iana/assignments/ipp/attribute-syntaxes/xxx-yyy.txt
where 'xxx-yyy' is the new attribute syntax name.
6.4 Operation Extensibility
Operations may also be registered following the type2 procedures
described in Section 6.1, though major new operations will usually be
done by a new standards track RFCthat augments this document. For
private (unregistered) operation extensions, implementers MUST use
the range for the "operation-id" in requests specified in Section
4.4.13 "operations-supported" Printer attribute.
For operations, the IPP Designated Expert in consultation with IANA
assigns the next operation-id code as specified in Section 4.4.13.
IANA will publish approved operation registration specifications as
separate files:
ftp.isi.edu/iana/assignments/ipp/operations/Xxx-Yyy.txt
where "Xxx-Yyy" is the new operation name.
6.5 Attribute Groups
Attribute groups passed in requests and responses may be registered
following the type2 procedures described in Section 6.1. The tags
that identify each of the attribute groups are assigned in [RFC2565].
For attribute groups, the IPP Designated Expert in consultation with
IANA assigns the next attribute group tag code in the appropriate
range as specified in [RFC2565]. IANA will publish approved
attribute group registration specifications as separate files:
ftp.isi.edu/iana/assignments/ipp/attribute-group-tags/xxx-yyy-
tag.txt
where 'xxx-yyy-tag' is the new attribute group tag name.
6.6 Status Code Extensibility
Operation status codes may also be registered following the type2
procedures described in Section 6.1. The values for status codes are
allocated in ranges as specified in Section 13 for each status code
class:
"informational" - Request received, continuing process
"successful" - The action was successfully received, understood,
and accepted
"redirection" - Further action must be taken in order to complete
the request
"client-error" - The request contains bad syntax or cannot be
fulfilled
"server-error" - The IPP object failed to fulfill an apparently
valid request
For private (unregistered) operation status code extensions,
implementers MUST use the top of each range as specified in Section
13.
For operation status codes, the IPP Designated Expert in consultation
with IANA assigns the next status code in the appropriate class range
as specified in Section 13. IANA will publish approved status code
registration specifications as separate files:
ftp.isi.edu/iana/assignments/ipp/status-codes/xxx-yyy.txt
where "xxx-yyy" is the new operation status code keyword.
6.7 Registration of MIME types/sub-types for document-formats
The "document-format" attribute's syntax is 'mimeMediaType'. This
means that valid values are Internet Media Types (see Section 4.1.9).
RFC2045 [RFC2045] defines the syntax for valid Internet media types.
IANA is the registry for all Internet media types.
6.8 Registration of charsets for use in 'charset' attribute values
The "attributes-charset" attribute's syntax is 'charset'. This means
that valid values are charsets names. When a charset in the IANA
registry has more than one name (alias), the name labeled as
"(preferred MIME name)", if present, MUST be used (see Section
4.1.7). IANA is the registry for charsets following the procedures
of [RFC2278].
7. Internationalization Considerations
Some of the attributes have values that are text strings and names
which are intended for human understanding rather than machine
understanding (see the 'text' and 'name' attribute syntaxes in
Sections 4.1.1 and 4.1.2).
In each operation request, the client
- identifies the charset and natural language of the request which
affects each supplied 'text' and 'name' attribute value, and
- requests the charset and natural language for attributes returned
by the IPP object in operation responses (as described in Section
3.1.4.1).
In addition, the client MAY separately and individually identify the
Natural Language Override of a supplied 'text' or 'name' attribute
using the 'textWithLanguage' and 'nameWithLanguage' technique
described section 4.1.1.2 and 4.1.2.2 respectively.
All IPP objects MUST support the UTF-8 [RFC2279] charset in all '
text' and 'name' attributes supported. If an IPP object supports
more than the UTF-8 charset, the object MUST convert between them in
order to return the requested 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
natural language requested where those values are generated by the
Printer (see Section 3.1.4.1).
For Printers that support multiple charsets and/or multiple natural
languages in 'text' and 'name' attributes, different jobs may have
been submitted in differing charsets and/or natural languages. All
responses MUST be returned in the charset requested by the client.
However, the Get-Jobs operation uses the 'textWithLanguage' and '
nameWithLanguage' mechanism to identify the differing natural
languages with each job attribute returned.
The Printer object also has configured charset and natural language
attributes. The client can query the Printer object to determine
the list of charsets and natural languages supported by the Printer
object and what the Printer object's configured values are. See the
"charset-configured", "charset-supported", "natural-language-
configured", and "generated-natural-language-supported" Printer
description attributes for more details.
The "charset-supported" attributed identifies the supported charsets.
If a charset is supported, the IPP object MUST be capable of
converting to and from that 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.
The "charset-configured" attribute identifies the one supported
charset which is the native charset given the current configuration
of the IPP object (administrator defined).
The "generated-natural-language-supported" attribute identifies the
set of supported natural languages for generated messages; it is not
related to the set of natural languages that must be accepted for
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
configured to support 'en-us' natural language does not mean that the
Printer object should reject a job if the client supplies a job name
that is in 'fr-ca'.
The "natural-language-configured" attribute identifies the one
supported natural language for generated messages which is the native
natural language given the current configuration of the IPP object
(administrator defined).
Attributes of type 'text' and 'name' are populated from different
sources. These attributes can be categorized into following groups
(depending on the source of the attribute):
1. Some attributes are supplied by the client (e.g., the client
supplied "job-name", "document-name", and "requesting-user-name"
operation attributes along with the corresponding Job 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 languages for generated
messages
2. Some attributes are supplied by the system administrator (e.g.,
the Printer object's "printer-name" and "printer-location"
attributes). These too can be in any natural language. If the
natural language for these attributes is different than what a
client requests, then they must be reported using the Natural
Language Override mechanism.
3. Some attributes are supplied by the device manufacturer (e.g.,
the Printer object's "printer-make-and-model" attribute). These
too can be in any natural language. If the natural language for
these attributes is different than what a client requests, then
they must be reported using the Natural Language Override
mechanism.
4. Some attributes are supplied by the operator (e.g., the Job
object's "job-message-from-operator" attribute). These too can
be in any natural language. If the natural language for these
attributes is different than what a client requests, then they
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
"printer-state-message" attribute, and the "status-message"
operation attribute). These attributes can only be in one of
the "generated-natural-language-supported" natural languages.
If a 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"
attribute (using the Natural Language Override mechanism if
needed).
The 'text' and 'name' attributes specified in this version of this
document (additional ones will be registered according to the
procedures in Section 6) are:
Attributes Source
-------------------------- ----------
Operation Attributes
job-name (name) client
document-name (name) client
requesting-user-name (name) client
status-message Job or Printer object
Job Template Attributes:
job-hold-until) client matches administrator-configured
(keyword name
job-hold-until-default client matches administrator-configured
(keyword name)
job-hold-until-supported client matches administrator-configured
(keyword name)
job-sheets client matches administrator-configured
(keyword name)
job-sheets-default client matches administrator-configured
(keyword name)
job-sheets-supported client matches administrator-configured
(keyword name)
media client matches administrator-configured
(keyword name)
media-default client matches administrator-configured
(keyword name)
media-supported client matches administrator-configured
(keyword name)
media-ready client matches administrator-configured
(keyword name)
Job Description Attributes:
job-name (name) client or Printer object
job-originating-user-name (name) Printer object
job-state-message (text) Job or Printer object
output-device-assigned (name(127)) administrator
job-message-from-operator (text(127)) operator
Printer Description Attributes:
printer-name (name(127)) administrator
printer-location (text(127)) administrator
printer-info (text(127)) administrator
printer-make-and-model (text(127)) administrator or manufacturer
printer-state-message (text) Printer object
printer-message-from-operator (text(127)) operator
8. Security Considerations
Some IPP objects MAY be deployed over protocol stacks that support
Secure Socket Layer Version 3 (SSL3) [SSL]. Note: SSL3 is not an
IETF standards track specification. Other IPP objects MAY be
deployed over protocol stacks that do not support SSL3. Some IPP
objects MAY be deployed over both types of protocol stacks. Those
IPP objects that support SSL3, are capable of supporting mutual
authentication as well as privacy of messages via multiple encryption
schemes. An important point about security related information for
SSL3 access to an IPP object, is that the security-related parameters
(authentication, encryption keys, etc.) are "out-of-band" to the
actual IPP protocol.
An IPP object that does not support SSL3 MAY elect to support a
transport layer that provides other security mechanisms. For
example, in a mapping of IPP over HTTP/1.1 [RFC2565], if the IPP
object does not support SSL3, HTTP still allows for client
authentication using Digest Access Authentication (DAA) [RFC2069].
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, the risks of exposing document
data may be low enough that the corporation will choose not to use
encryption on that data. However, if the connection between the
client and the IPP object is over a public network, the client may
wish to protect the content of the information during transmission
through the network with encryption.
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-
service attacks, but denial-of-service attacks against printing
resources are not well understood and there is no published
precedents regarding this scenario.
Once the authenticated identity of the requester has been supplied to
the IPP object, the object uses that identity to enforce any
authorization policy that might be in place. For example, one site's
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.0, and must be established via some
other type of administrative or access control framework. However,
there are operation status codes that allow an IPP server to return
information back to a client about any potential access control
violations for an IPP object.
During a create operation, the client's identity is recorded in the
Job object in an implementation-defined attribute. This information
can be used to verify a client's identity for subsequent operations
on that Job object in order to enforce any access control policy that
might be in effect. See section 8.3 below for more details.
Since the security levels or the specific threats that any given IPP
system administrator may be concerned with cannot be anticipated, IPP
MUST be capable of operating with different security mechanisms and
security policies as required by the individual installation.
Security policies might vary from very strong, to very weak, to none
at all, and corresponding security mechanisms will be required. SSL3
supports the type of negotiated levels of security required by most,
if not all, potential IPP environments. IPP environments that require
no security can elect to deploy IPP objects that do not utilize the
optional SSL3 security mechanisms.
8.1 Security Scenarios
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
these environments will necessarily be addressed in initial
implementations of IPP.
8.1.1 Client and Server in the Same Security Domain
This environment is typical of internal networks where traditional
Office workers print the output of personal productivity applications
on shared work-group printers, or where batch applications print
their output on large production printers. Although the identity of
the user may be trusted in this environment, a user might want to
protect the content of a document against such attacks as
eavesdropping, replaying or tampering.
8.1.2 Client and Server in Different Security Domains
Examples of this environment include printing a document created by
the client on a publicly available printer, such as at a commercial
print shop; or printing a document remotely on a business associate's
printer. This latter operation is functionally equivalent to sending
the document to the business associate as a facsimile. Printing
sensitive information on a Printer in a different security domain
requires strong security measures. In this environment authentication
of the printer is required as well as protection against unauthorized
use of print resources. Since the document crosses security domains,
protection against eavesdropping and document tampering are also
required. It will also be important in this environment to protect
Printers against "spamming" and malicious document content.
8.1.3 Print by Reference
When the document is not stored on the client, printing can be done
by reference. That is, the print request can contain a reference, or
pointer, to the document instead of the actual document itself.
Standard methods currently do not exist for remote entities to
"assume" the credentials of a client for forwarding requests to a 3rd
party. It is anticipated that Print-By-Reference will be used to
access "public" documents and that sophisticated methods for
authenticating "proxies" will not be specified for version 1 of IPP.
8.2 URIs for SSL3 and non-SSL3 Access
As described earlier, an IPP object can support SSL3 access, non-SSL3
access, or both. The "printer-uri-supported" attribute contains the
Printer object's URI(s). Its companion attribute, "uri-security-
supported", identifies the security mechanism used for each URI
listed in the "printer-uri-supported" attribute. For each Printer
operation request, a client MUST supply only one URI in the
"printer-uri" operation attribute. In other words, even though the
Printer supports more than one URI, the client only interacts with
the Printer object using one if its URIs. This duality is not needed
for Job objects, since the Printer objects is the factory for Job
objects, and the Printer object will generate the correct URI for new
Job objects depending on the Printer object's security configuration.
8.3 The "requesting-user-name" (name(MAX)) Operation Attribute
Each operation MUST specify the user who is performing the operation
in both of the following two ways:
1) via the REQUIRED "requesting-user-name" operation attribute that
a client SHOULD supply in all operations. The client MUST obtain
the value for this attribute from an environmental or network
login name for the user, rather than allowing the user to supply
any value. If the client does not supply a value for
"requesting-user-name", the printer MUST assume that the client
is supplying some anonymous name, such as "anonymous".
2) via an authentication mechanism of the underlying transport
which may be configured to give no authentication information.
There are six cases to consider:
a) the authentication mechanism gives no information, and the
client doesn't specify "requesting-user-name".
b) the authentication mechanism gives no information, but the
client specifies "requesting-user-name".
c) the authentication mechanism specifies a user which has no human
readable representation, and the client doesn't specify
"requesting-user-name".
d) the authentication mechanism specifies a user which has no human
readable representation, but the client specifies "requesting-
user-name".
e) the authentication mechanism specifies a user which has a human
readable representation. The Printer object ignores the
"requesting-user-name".
f) the authentication mechanism specifies a user who is trusted and
whose name means that the value of the "requesting-user-name",
which MUST be present, is treated as the authenticated name.
Note: Case "f" is intended for a tightly coupled gateway and server
to work together so that the "user" name is able to be that of the
gateway client and not that of the gateway. Because most, if not
all, system vendors will initially implement IPP via a gateway into
their existing print system, this mechanism is necessary unless the
authentication mechanism allows a gateway (client) to act on behalf
of some other client.
The user-name has two forms:
- one that is human readable: it is held in the REQUIRED "job-
originating-user-name" Job Description attribute which is set
during the job creation operations. It is used for presentation
only, such as returning in queries or printing on start sheets
- one for authorization: it is held in an undefined (by IPP) Job
object attribute which is set by the job creation operation. It
is used to authorize other operations, such as Send-Document,
Send-URI, Cancel-Job, to determine the user when the "my-jobs"
attribute is specified with Get-Jobs, and to limit what
attributes and values to return with Get-Job-Attributes and Get-
Jobs.
The human readable user name:
- is the value of the "requesting-user-name" for cases b, d and f.
- comes from the authentication mechanism for case e
- is some anonymous name, such as "anonymous" for cases a and c.
The user name used for authorization:
- is the value of the "requesting-user-name" for cases b and f.
- comes from the authentication mechanism for cases c, d and e
- is some anonymous name, such as "anonymous" for case a.
The essence of these rules for resolving conflicting sources of
user-names is that a printer implementation is free to pick either
source as long as it achieves consistent results. That is, if a user
uses the same path for a series of requests, the requests MUST appear
to come from the same user from the standpoint of both the human-
readable user name and the user name for authorization. This rule
MUST continue to apply even if a request could be authenticated by
two or more mechanisms. It doesn't matter which of several
authentication mechanisms a Printer uses as long as it achieves
consistent results. If a client uses more than one authentication
mechanism, it is recommended that an administrator make all
credentials resolve to the same user and user-name as much as
possible.
8.4 Restricted Queries
In many IPP operations, a 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
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 cannot tell by such a response
whether the requested attribute was present or absent on the object.
8.5 Queries on jobs submitted using non-IPP protocols
If the device that an IPP Printer is representing is able to accept
jobs using other job submission protocols in addition to IPP, it is
RECOMMENDED that such an implementation at least allow such "foreign"
jobs to be queried using Get-Jobs returning "job-id" and "job-uri" as
'unknown'. Such an implementation NEED NOT support all of the same
IPP job attributes as for IPP jobs. The IPP object returns the '
unknown' out-of-band value for any requested attribute of a foreign
job that is supported for IPP jobs, but not for foreign jobs.
It is further RECOMMENDED, that the IPP Printer generate "job-id" and
"job-uri" values for such "foreign jobs", if possible, so that they
may be targets of other IPP operations, such as Get-Job-Attributes
and Cancel-Job. Such an implementation also needs to deal with the
problem of authentication of such foreign jobs. One approach would
be to treat all such foreign jobs as belonging to users other than
the user of the IPP client. Another approach would be for the
foreign job to belong to 'anonymous'. Only if the IPP client has
been authenticated as an operator or administrator of the IPP Printer
object, could the foreign jobs be queried by an IPP request.
Alternatively, if the security policy is to allow users to query
other users' jobs, then the foreign jobs would also be visible to an
end-user IPP client using Get-Jobs and Get-Job-Attributes.
8.6 IPP Security Application Profile for SSL3
The IPP application profile for SSL3 follows the "Secure Socket
Layer" requirement as documented in the SSL3 specification [SSL].
For interoperability, the SSL3 cipher suites are:
SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_DES_CBC_SHA
SSL_RSA_EXPORT_WITH_RC4_40_MD5
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5
SSL_RSA_WITH_NULL_MD5
Client implementations MUST NOT assume any other cipher suites are
supported by an IPP Printer object.
If a conforming IPP object supports SSL3, it MUST implement and
support the cipher suites listed above and MAY support additional
cipher suites.
A conforming IPP client SHOULD support SSL3 including the cipher
suites listed above. A conforming IPP client MAY support additional
cipher suites.
It is possible that due to certain government export restrictions
some non-compliant versions of this extension could be deployed.
Implementations wishing to inter-operate with such non-compliant
versions MAY offer the SSL_RSA_EXPORT_WITH_RC4_40_MD5 and
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 mechanisms. However, since 40 bit
ciphers are known to be vulnerable to attack by current technology,
any client which actives a 40 bit cipher MUST NOT indicate to the
user that the connection is completely secure from eavesdropping.
9. References
[ASCII] Coded Character Set - 7-bit American Standard Code for
Information Interchange (ASCII), ANSI X3.4-1986. This
standard is the specification of the US-ASCII charset.
[HTPP] J. Barnett, K. Carter, R. DeBry, "Initial Draft -
Hypertext Printing Protocol - HTPP/1.0", October 1996.
ftp://ftp.pwg.org/pub/pwg/ipp/historic/htpp/
overview.ps.gz
[IANA-CS] IANA Registry of Coded Character Sets:
ftp://ftp.isi.edu/in-notes/iana/assignments/character-
sets
[IANA-MT] IANA Registry of Media Types: ftp://ftp.isi.edu/in-
notes/iana/assignments/media-types/
[ipp-iig] Hastings, T. and C. Manros, "Internet Printing
Protocol/1.0: Implementer's Guide", Work in Progress.
[ISO10646-1] ISO/IEC 10646-1:1993, "Information technology --
Universal Multiple-Octet Coded Character Set (UCS) -
Part 1: Architecture and Basic Multilingual Plane,
JTC1/SC2."
[ISO8859-1] ISO/IEC 8859-1:1987, "Information technology -- 8-bit
One-Byte Coded Character Set - Part 1: Latin Alphabet Nr
1", 1987, JTC1/SC2.
[ISO10175] ISO/IEC 10175 Document Printing Application (DPA), June
1996.
[LDPA] T. Hastings, S. Isaacson, M. MacKay, C. Manros, D. Taylor, P.
Zehler, "LDPA - Lightweight Document Printing
Application", October 1996,
ftp://ftp.pwg.org/pub/pwg/ipp/historic/ldpa/ldpa8.pdf.gz
[P1387.4] Kirk, M. (Editor), POSIX System Administration - Part 4:
Printing Interfaces, POSIX 1387.4 D8, 1994.
[PSIS] Herriot, R. (editor), X/Open A Printing System
Interoperability Specification (PSIS), August 1995.
[PWG] Printer Working Group, http://www.pwg.org.
[RFC1035] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND
SPECIFICATION", STD 13, RFC1035, November 1987.
[RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S. and J.
Gyllenskog, "Printer MIB", RFC1759, March 1995.
[RFC1766] Alvestrand, H., "Tags for the Identification of
Languages", RFC1766, March 1995.
[RFC1179] McLaughlin, L. (Editor), "Line Printer Daemon Protocol",
RFC1179, August 1990.
[RFC1952] Deutsch, P., "GZIP file format specification version
4.3", RFC1952, May 1996.
[RFC2045] Freed, N. and N. Borenstein, " Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC2045, November 1996.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC2046,
November 1996.
[RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose
Internet Mail Extension (MIME) Part Four: Registration
Procedures", RFC2048, November 1996.
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. AND T.
Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1",
RFC2068, January 1997.
[RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
Luotonen, A., Sink, E. and L. Stewart, "An Extension to
HTTP: Digest Access Authentication", RFC2069, January
1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997.
[RFC2228] Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC
2228, October 1997.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages" RFC2277, January 1998.
[RFC2278] Freed, N. and J. Postel: "IANA Charset Registration
Procedures", BCP 19, RFC2278, January 1998.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC2279, January 1998.
[RFC2316] Bellovin, S., "Report of the IAB Security Architecture
Workshop", RFC2316, April 1998.
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC2396,
August 1998.