Model Terminology

Keywords are used within this document as identifiers of semantic entities within the abstract model (see section 4.1.2.3). Attribute names, some attribute values, attribute syntaxes, and attribute group names are represented as keywords.

12.2.2 Attributes

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 are defined in section 4 and all operation attributes are defined in section 3.

Job Template Attributes are described in section 4.2. The client optionally supplies Job Template attributes in a create request

(operation requests that create Job objects). The Printer object has associated attributes which define supported and default values for the Printer.

12.2.2.1 Attribute Name

Each attribute is uniquely identified in this document by its attribute name. An attribute name is a keyword. The keyword attribute name is given in the section header describing that

attribute. In running text in this document, attribute names are indicated inside double quotation marks (") where the quotation marks are not part of the keyword itself.

12.2.2.2 Attribute Group Name

Related attributes are grouped into named groups. The name of the group is a keyword. The group name may be used in place of naming all the attributes in the group explicitly. Attribute groups are defined in section 3.

12.2.2.3 Attribute Value

Each attribute has one or more values. Attribute values are represented in the syntax type specified for that attribute. In running text in this document, attribute values are indicated inside single quotation marks (’), whether their attribute syntax is

keyword, integer, text, etc. where the quotation marks are not part of the value itself.

12.2.2.4 Attribute Syntax

Each attribute is defined using an explicit syntax type. In this document, each syntax type is defined as a keyword with specific meaning. The Encoding and Transport document [RFC2565] indicates the actual "on-the-wire" encoding rules for each syntax type. Attribute syntax types are defined in section 4.1.

12.2.3 Supports

By definition, a Printer object supports an attribute only if that Printer object responds with the corresponding attribute populated with some value(s) in a response to a query for that attribute. A 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 is concerned, that implementation does not support that feature. If the Printer object’s "xxx-supported" attribute is not populated with a particular value (even if that value is a legal value for that

attribute), then that Printer object does not support that particular value.

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

example, if a given instance of a Printer supports only certain document formats, then that Printer responds with the format-supported" attribute populated with a set of values, possibly only one, taken from the entire set of possible values defined 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 attribute or some specific value, then 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 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).

For example, consider the "finishings-supported" attribute.

1) If a Printer object is not physically capable of stapling, the "finishings-supported" attribute MUST NOT be populated with the 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.

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.

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. 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.

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 IPP. 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 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 device) the actual process for supporting a value is undefined and left up to the

implementation. However, if a Printer object supports a value, some manual human action may be needed to realize the semantic action associated with the value, but no end user action is required.

For example, if one of the values in the "finishings-supported"

attribute is ’staple’, the actual process might be an automatic

staple action by a physical device controlled by some command sent to the device. Or, the actual process of stapling might be a manual action by an operator at an operator attended Printer object.

For another example of how supported attributes function, consider a system administrator who desires to control all print jobs so that no job sheets are printed in order to conserve paper. To force no job sheets, the system administrator sets the only supported value for the "job-sheets-supported" attribute to ’none’. In this case, if a client requests anything except ’none’, the create request is

rejected or the "job-sheets" value is ignored (depending on the value of "ipp-attribute-fidelity"). To force the use of job start/end sheets on all jobs, the administrator does not include the value ’ none’ in the "job-sheets-supported" attribute. In this case, if a client requests ’none’, the create request is rejected or the sheets" value is ignored (again depending on the value of attribute-fidelity").

12.2.4 print-stream page

A "print-stream page" is a page according to the definition of pages in the language used to express the document data.

12.2.5 impression

An "impression" is the image (possibly many print-stream pages in different configurations) imposed onto a single media page.

13. APPENDIX B: Status Codes and Suggested Status Code Messages This section defines status code enum keywords and values that are used to provide semantic information on the results of an operation request. Each operation response MUST include a status code. The response MAY also contain a status message that provides a short textual description of the status. The status code is intended for use by automata, and the status message is intended for the human end 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) is NOT REQUIRED to examine or display the status message, since it MAY not be returned to the application.

The prefix of the status keyword defines the class of response as follows:

"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

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, IPP clients MUST understand the class of any status code, as

indicated by the prefix, and treat any unrecognized response as being equivalent to the first status code of that class, with the exception that an unrecognized response MUST NOT be cached. For example, if an unrecognized status code of "client-error-xxx-yyy" is received by the client, it can safely assume that there was something wrong with its request and treat the response as if it had received a 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 which will help to explain the unusual status. The name of the enum is the suggested status message for US English.

The status code values range from 0x0000 to 0x7FFF. The value ranges for each status code class are as follows:

"successful" - 0x0000 to 0x00FF "informational" - 0x0100 to 0x01FF "redirection" - 0x0200 to 0x02FF

"client-error" - 0x0400 to 0x04FF "server-error" - 0x0500 to 0x05FF

The top half (128 values) of each range (0x0n40 to 0x0nFF, for n = 0 to 5) is reserved for private use within each status code class.

Values 0x0600 to 0x7FFF are reserved for future assignment and MUST NOT be used.