Suggestions from Larry Masinter on how to write IPP/1.1 with both IPP/1.1
and IPP/1.0 requirements from his experience with HTTP/1.1.
> 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".
Well, I don't like the "NEED NOT" terminology. These are all things
that you decided were good ideas. So you might as well write it
in a positive way: MUST be implemented in IPP/1.1 (optional in IPP/1.0).
> 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.
I think we're talking about the full security analysis on the list.
The result will be something which is a MUST for IPP/1.1, and
optional for IPP/1.0. Unless TLS is required in IPP/1.1, I think
"SSL" is a MAY in IPP/1.1, in which case the formulation is simpler.
> 3. IPP/1.0 NEED NOT return "document-format=xxx" in Unsupported
> Attributes Group, while IPP/1.1 MUST. See Issue 11.
Frankly, I see no point in saying "NEED NOT". Just mark this as
"IPP/1.1 only, optional in IPP/1.0".
> 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.
Yes, this is "MUST be implemented in IPP/1.1; optional in IPP/1.0."
> 5. Possible resolution of OPEN ISSUE 17 would REQUIRE IPP/1.1
> implementations to support dateTime for some new or existing Job
attributes.
Yes, this is "MUST be implemented in IPP/1.1; optional in IPP/1.0."
> 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.
Well, I think this is a case where the IPP/1.0 spec blew it; i.e.,
"if you don't do X, you will get unintelligible results" should turn into
"you MUST do X".
> 7. IPP/1.1 implementations MUST support "queued-job-count". IPP/1.0
> implementations SHOULD support it.
Yes, this is "MUST be implemented in IPP/1.1; optional in IPP/1.0."
> 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.
Yes, this is "MUST be implemented in IPP/1.1; optional in IPP/1.0."
> 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.
Yes, this is "MUST be implemented in IPP/1.1; optional in IPP/1.0."
> 10. IPP/1.1 clients and servers MUST support the IPP scheme; optional in
IPP/1.0.