Here is the updated text for the Conformance Section of the IPP/1.1 Encoding
and Transport document. It replaces the "Compatibility with IPP/1.0
Implementations" section that we had in the May I-D. These changes follow
the same changes we have made in the Model and Semantics document for
interoperability with IPP/1.0 (Issues 33 and 36). We've also simplified the
IPP/1.1 requirements so that the server doesn't have to restrict itself to
IPP/1.0 server functionality when it gets an IPP/1.0 request. And we have
incorporated Keith's concern that security not be compromised if the client
sends a request with the "version-number" parameter set to '1.0'.
Tom
7. Conformance Requirements
Clients MUST meet the conformance requirements for clients specified in this
document and [ipp-mod]. For interoperability with IPP/1.0 servers, IPP/1.1
clients SHOULD also meet the conformance requirements for clients as
specified in [RFC2566] and [RFC2565].
IPP Printer and Job objects MUST meet the conformance requirements for IPP
objects specified in this document and [ipp-mod]. For interoperability with
IPP/1.0 clients, IPP/1.1 objects SHOULD also meet the conformance
requirements for IPP objects as specified in [RFC2565] and [RFC2566].
7.1 The "version-number" Parameter
The following are specific rules for conformance requirements regarding the
"version-number" parameter (see section 3.3):
1. Clients MUST send requests containing a "version-number" parameter
with a '1.1' value and SHOULD try supplying alternate version numbers if
they receive a 'server-error-version-not-supported' error return in a
response.
2. IPP objects MUST accept requests containing a "version-number"
parameter with a '1.1' value (or reject the request for reasons other than
'server-error-version-not-supported').
3. IPP objects SHOULD accept any request with the major version '1' (or
reject the request for reasons other than
'server-error-version-not-supported'). See [ipp-mod] "versions"
sub-section.
4. In any case, security MUST NOT be compromised when a 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 configured
to enforce Digest Authentication, it MUST do the same for a version '1.0'
request.
7.2 Security and URI Schemes
The following are specific rules for conformance regarding security, the
"version-number" parameter, and the URI scheme supplied in target attributes
and responses:
1. When a client supplies a request, the "printer-uri" or "job-uri"
target operation attribute MUST have the same scheme as that indicated in
one of the values of the "printer-uri-supported" Printer attribute.
2. When the server returns the "job-printer-uri" or "job-uri" Job
Description attributes, it SHOULD return the same scheme ('ipp', 'https',
etc.) that the client supplied in the "printer-uri" or "job-uri" target
operation attributes in the Get-Job-Attributes or Get-Jobs request, rather
than the scheme used when the job was created. However, when a client
requests job attributes using the Get-Job-Attributes or Get-Jobs operations,
the jobs and job attributes that the server returns depends on: (1) the
security in effect when the job was created, (2) the security in effect in
the query request, and (3) the security policy in force.
3. If a server registers a non-secure ipp-URL with a name service, then
it SHOULD also register an http-URL for interoperability with IPP/1.0
clients (see section 7).
4. In any case, security MUST NOT be compromised when a client supplies
an 'http' or other non-secure URI scheme in the target "printer-uri" and
"job-uri" operation attributes in a request.