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