IPP> MOD - RESEND - ISSUE 33 - Include both IPP/1.0 and IPP/1.1 confor mance requirements

IPP> MOD - RESEND - ISSUE 33 - Include both IPP/1.0 and IPP/1.1 confor mance requirements

IPP> MOD - RESEND - ISSUE 33 - Include both IPP/1.0 and IPP/1.1 confor mance requirements

Hastings, Tom N hastings at cp10.es.xerox.com
Tue Apr 13 00:50:04 EDT 1999


Restated following Larry Masinter's suggestions (and renumbered).  Also
added points 1 and 2.  Please ignore previous mail messages on this issue.

33) OPEN - ISSUE:  Ok to include the IPP/1.0 conformance requirements in the
IPP/1.1 document?

Suggested change:
  
Most conformance requirements are the same for IPP/1.0 and IPP/1.1.  For
those make no special indication in the document.  For those for which the
conformance is REQUIRED for IPP/1.1, but OPTIONAL for IPP/1.0, state:
"IPP/1.1 xxx MUST ...; OPTIONAL in IPP/1.0", where xxx is either clients or
Printers.

Here are the 12 items for which the conformance requirements differ between
IPP/1.0 and IPP/1.1:

1. IPP/1.1 clients MUST be able to issue both IPP/1.1 and IPP/1.0 requests
and accept both IPP/1.1 and IPP/1.0 responses.

2. IPP/1.1 Printers MUST accept and support both IPP/1.1 and IPP/1.0
requests and responses.

3. IPP/1.1 clients and Printers MUST support the IPP scheme; OPTIONAL for
IPP/1.0.

4. IPP/1.1 clients SHOULD support TLS and non-TLS access; OPTIONAL for
IPP/1.0.  IPP/1.0 clients SHOULD support SSL3 and non-SSL3 access; OPTIONAL
for IPP/1.1.

5. Printers MAY support SSL3 access, access without SSL3 or both.  In
addition, IPP/1.1 Printers SHOULD support TLS access, MAY support access
without TLS, or MAY support both means of access; OPTIONAL for IPP/1.0.

6. Possible resolution of OPEN ISSUE 32:  IPP/1.1 clients and Printers MUST
support Digest; OPTIONAL for IPP/1.0.

7. IPP/1.1 Printers MUST return "document-format=xxx" in the Unsupported
Attributes Group; OPTIONAL for IPP/1.0.  See Issue 11.

8. IPP/1.1 Printers implemented as a forwarding server that can't get status
from the device or print system (such as LPD) that it forwards jobs to, MAY
put the job into the 'completed' state after forwarding the job.  However,
such implementations MUST support the "job-state-reasons" attribute with the
'queue-in-device' value when it puts the job into the 'completed' state, as
an indication that the job is not necessarily completed;  OPTIONAL for
IPP/1.0 forwarding servers.  See Issue 14.

9. Possible resolution of OPEN ISSUE 17:  IPP/1.1 Printers MUST support
dateTime for the new or existing Job attributes; OPTIONAL for IPP/1.0.

10. IPP/1.1 Printers MUST support "compression" and "compression-supported"
attributes with at least the 'none' value.  IPP/1.0 Printers MUST at least
check for the "compression" attribute being present and reject the create
request, if they don't support "compression" and "compression-supported".
Not checking is a bug, since the data will be unintelligible.
Note:  On Larry Masinter's advice, I changed the SHOULD to a MUST for
IPP/1.0, ok?

11. IPP/1.1 Printers MUST support "queued-job-count"; RECOMMEND for IPP/1.0.

12. Possible resolution of OPEN ISSUE 30:  IPP/1.1 Printers MUST support
"job-state-reasons" and "printer-state-reasons"; OPTIONAL for IPP/1.0.



More information about the Ipp mailing list