IPP Mail Archive: IPP> MOD - ISSUE 33 - Include both IPP/1.0 and IPP/1.1 conformance req
IPP> MOD - ISSUE 33 - Include both IPP/1.0 and IPP/1.1 conformance req
Hastings, Tom N (
hastings@cp10.es.xerox.com)
Mon, 12 Apr 1999 17:45:57 -0700
Here is a first cut at the 9 things that have (or might have) different
conformance requirements between IPP/1.0 and IPP/1.1 that we would need to
flag in the IPP/1.1 Model and Semantics document. The Encoding and Transport
would have one or two.
Tom
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 that apply only
to IPP/1.1 indicate as "NOT applying to IPP/1.0". For those that apply only
to IPP/1.0, indicate them as "IPP/1.0 only".
1. IPP/1.0 client implementations SHOULD support SSL3 and non-SSL3 access,
while IPP/1.1 client implementations SHOULD support TLS and non-TLS access.
2. IPP/1.0 Printer object implementations MAY support SSL3 access, access
without SSL3 or both, while IPP/1.1 Printer object implementations SHOULD
support TLS access, MAY support access without TLS, or MAY support both
means of access.
3. IPP/1.0 NEED NOT return "document-format=xxx" in Unsupported Attributes
Group, while IPP/1.1 MUST. See Issue 11.
4. IPP/1.1 forwarding server that can't get status from the device or server
that it forwards jobs to, such as an LPD system, MAY put the job into the
'completed' state after forwarding the job to the device or system, but 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. IPP/1.0 forwarding server implementations
NEED NOT. See Issue 14.
5. Possible resolution of OPEN ISSUE 17 would REQUIRE IPP/1.1
implementations to support dateTime for some new or existing Job attributes.
6. IPP/1.1 implementations MUST support "compression" and
"compression-supported" attributes with at least the 'none' value. IPP/1.0
SHOULD at least check for the "compression" attribute being present and
reject the create request, if they don't support "compression". Not
checking is a bug, since the data will be unintelligible.
7. IPP/1.1 implementations MUST support "queued-job-count". IPP/1.0
implementations SHOULD support it.
8. Possible resolution of OPEN ISSUE 30 would REQUIRE IPP/1.1
implementations to support "job-state-reasons" and "printer-state-reasons",
while they are OPTIONAL for IPP/1.0 implementations.
9. Possible resolution of OPEN ISSUE 32 would REQUIRE IPP/1.1 clients and
IPP objects to support Digest, while IPP/1.0 NEED NOT.