Request Operation Attributes

The client MUST supply and the Printer object MUST support the following REQUIRED operation attributes in every IPP/1.0 operation request:

"attributes-charset" (charset):

This operation attribute identifies the charset (coded character set and encoding method) used by any ’text’ and ’name’

attributes that the client is supplying in this request. It also identifies the charset that the Printer object MUST use (if supported) for all ’text’ and ’name’ attributes and status

messages that the Printer object returns in the response to this request. See Sections 4.1.1 and 4.1.2 for the specification of the ’text’ and ’name’ attribute syntaxes.

All clients and IPP objects MUST support the ’utf-8’ charset [RFC2279] and MAY support additional charsets provided that they are registered with IANA [IANA-CS]. If the Printer object does not support the client supplied charset value, the Printer object MUST reject the request, set the "attributes-charset" to ’utf-8’ in the response, and return the not-supported’ status code and any ’text’ or ’name’ attributes using the ’utf-8’ charset. The Printer object MUST indicate the charset(s) supported as the values of the "charset-supported"

Printer attribute (see Section 4.4.15), so that the client can query to determine which charset(s) are supported.

Note to client implementers: Since IPP objects are only required to support the ’utf-8’ charset, in order to maximize

interoperability with multiple IPP object implementations, a client may want to supply ’utf-8’ in the "attributes-charset"

operation attribute, even though the client is only passing and able to present a simpler charset, such as US-ASCII or 8859-1. Then the client will have to filter out (or charset convert) those characters that are returned in 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 may want to use that charset in order to avoid charset conversion or data loss.

See the ’charset’ attribute syntax description in Section 4.1.7 for the syntax and semantic interpretation of the values of this attribute and for example values.

"attributes-natural-language" (naturalLanguage):

This operation attribute identifies the natural language used by any ’text’ and ’name’ attributes that the client is supplying in this request. This attribute also identifies the natural

language that the Printer object SHOULD use for all ’text’ and ’ name’ attributes and status messages that the Printer object returns in the response to this request.

There are no REQUIRED natural languages required for the Printer object to support. However, the Printer object’s natural-language-supported" attribute identifies the 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 this attribute to determine which natural language(s) are supported for generated messages.

For any of the attributes for which the Printer object generates text, i.e., for the "job-state-message",

message", and status messages (see Section 3.1.6), the Printer object MUST be able to generate these text strings in any of its supported natural languages. If the client requests a natural language that is not supported, the Printer object MUST return these generated messages in the Printer’s configured natural language as specified by the Printer’s configured" attribute" (see Section 4.4.16).

For other ’text’ and ’name’ attributes supplied by the client, authentication system, operator, system administrator, or manufacturer (i.e., for "job-originating-user-name", name" (name), "printer-location" (text), "printer-info" (text), and "printer-make-and-model" (text)), the Printer object is only required to support the configured natural language of the

Printer identified by the Printer object’s configured" attribute, though support of additional natural languages for these attributes is permitted.

For any ’text’ or ’name’ attribute in the request that is in a different natural language than the value supplied in the "attributes-natural-language" operation attribute, the client MUST use the Natural Language Override mechanism (see sections 4.1.1.2 and 4.1.2.2) for each such attribute value supplied.

The client MAY use the Natural Language Override mechanism redundantly, i.e., use it even when the value is in the same natural language as the value supplied in the natural-language" operation attribute of the request.

The IPP object MUST accept any natural language and any Natural Language Override, whether the IPP object supports that natural language or not (and independent of the value of the attribute-fidelity" Operation attribute). That is the IPP object accepts all client supplied values no matter what the values are in the Printer object’s supported" attribute. That attribute, language-supported", only applies to generated messages,

not client supplied messages. The IPP object MUST remember that natural language for all client-supplied attributes, and when returning those attributes in response to a query, the IPP object MUST indicate that natural language.

Each value whose attribute syntax type is ’text’ or ’name’ (see sections 4.1.1 and 4.1.2) has an Associated Natural-Language.

This document does not specify how this association is stored in a Printer or Job object. When such a value is encoded in a request or response, the natural language is either implicit or explicit:

- In the implicit case, the value contains only the text/name value, and the language is specified by the "attributes-natural-language" operation attribute in the request or response (see sections 4.1.1.1

textWithoutLanguage and 4.1.2.1 nameWithoutLanguage).

- In the explicit case (also known as the Natural-Language Override case), the value contains both the language and the text/name value (see sections 4.1.1.2

textWithLanguage and 4.1.2.2 nameWithLanguage).

For example, the "job-name" attribute MAY be supplied by the client in a create request. The text value for this attribute will be in the natural language identified by the natural-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 Override mechanism to specify the natural language, if it is different from that reported in the language" operation attribute of the response. The IPP object MAY use the Natural Language Override mechanism redundantly, i.e., use it even when the value is in the same natural language as the value supplied in the "attributes-natural-language"

operation attribute of the response.

An IPP object MUST NOT reject a request based on a supplied natural language in an "attributes-natural-language" Operation attribute or in any attribute that uses the Natural Language Override.

See the ’naturalLanguage’ attribute syntax description in

section 4.1.8 for the syntax and semantic interpretation of the values of this attribute and for example values.

Clients SHOULD NOT supply ’text’ or ’name’ attributes that use an illegal combination of natural language and charset. For example, suppose a Printer object supports charsets ’utf-8’, ’iso-8859-1’, and ’iso-8859-7’. Suppose also, that it supports natural languages ’en’

(English), ’fr’ (French), and ’el’ (Greek). Although the Printer object supports the charset ’iso-8859-1’ and natural language ’el’, it probably does not support the combination of Greek text strings using the ’iso-8859-1’ charset. The Printer object handles this apparent incompatibility differently depending on the context in which it occurs:

- In a create request: If the client supplies a text or name

attribute (for example, the "job-name" operation attribute) that uses an apparently incompatible combination, it is a client choice that does not affect the Printer object or its correct operation. Therefore, the Printer object simply accepts the client supplied value, stores it with the Job object, and

responds back with the same combination whenever the client (or any client) queries for that attribute.

- In a query-type operation, like Get-Printer-Attributes: If the client requests an apparently incompatible combination, the Printer object responds (as described in section 3.1.4.2) using the Printer’s configured natural language rather than the natural language requested by the client.

In either case, the Printer object does not reject the request

because of the apparent incompatibility. The potential incompatible combination of charset and natural language can occur either at the global operation level or at the Natural Language Override

attribute-by-attribute level. In addition, since the response always includes explicit charset and natural language information, there is never any question or ambiguity in how the client interprets the response.