IPP> PRO - Updated Conformance section for IPP/1.1 Encoding and Transp ort document (Issues 33 and 36)

IPP> PRO - Updated Conformance section for IPP/1.1 Encoding and Transp ort document (Issues 33 and 36)

IPP> PRO - Updated Conformance section for IPP/1.1 Encoding and Transp ort document (Issues 33 and 36)

Hastings, Tom N hastings at cp10.es.xerox.com
Thu Jun 10 22:15:46 EDT 1999


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.





More information about the Ipp mailing list