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

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

Hastings, Tom N hastings at cp10.es.xerox.com
Mon Apr 12 21:06:38 EDT 1999


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.




More information about the Ipp mailing list