IPP> MOD - Updated Model and Semantics document posted

IPP> MOD - Updated Model and Semantics document posted

IPP> MOD - Updated Model and Semantics document posted

Hastings, Tom N hastings at cp10.es.xerox.com
Wed Nov 4 03:37:09 EST 1998

I've posted the updated IPP Model with the clarifications that we have
agreed to so far to the June Model and Semantics specification as a result
of our interoperability testing in September.


There are a few remaining issues (mostly having to do with natural language
simplification) in:


We will discuss the natural language issues at the telecon, on Wed, 10/4/98,
10-12 PST (1-3 EST)
and at the IPP WG meeting next week in Tucson, 10/10 - 10/12.

Here is the Change History which is a new section at the end of the Model
APPENDIX F:  Change History for the IPP Model and Semantics document
The following substantive changes and major clarifications have been made to
this document from the June 30, 1998 version based on the interoperability
testing that took place September 23-25 1998.  They are listed in the order
of occurrence in the document.  These changes are the ones that might affect
implementations.  Clarifications that are unlikely to affect implementations
are not listed.  The issue numbers refer to the IPP Issues List which is
available at:


where yymmdd are the year, month, and day the file was posted.

Section	Description
3.1.2, 16.3.3 [now IPP-IIG]	Clarify that the IPP object SHOULD NOT
validate the range of the request-id being 1 to 2**31-1, but accepts and
returns any value.  Clients MUST still keep in the range 1 to 2**31 though.
(Issue 1.36),	Clarified that when a client submits a request in a
charset that is not supported, the IPP object MUST return any 'text' or
'name' attributes in the Printer's "charset-configured" charset.  (1.19)	Clarified that if a client is not supplying any Job Template
attributes in a request, the client MAY supply an empty Group 2 or MAY omit
Group 2 entirely. (1.16),,,,,,	Clarified that if an
IPP object is not returning any Unsupported Attributes in a response, the
IPP object MAY return an empty Group 2 or MAY omit Group 2 entirely.  (Issue
1.17),,	Clarified that an IPP object MUST treat an
unsupported attribute syntax supplied in a request in the same way as an
unsupported value.  The IPP object MUST return the attribute, the attribute
syntax, and the value in the Unsupported Attributes group.  (Issue 1.26),,,,,	Clarified
for Get-Printer-Attributes, Get-Jobs, and Get-Job-Attributes that an IPP
object MUST return 'successful-ok-ignored-or-substituted-attributes' (0x1),
rather than 'successful-ok' (0x0), when a client supplies unsupported
attributes as values of the 'requested-attributes' operation attribute.
(Issue 1.24)  Also clarified that the response NEED NOT contain the
"requested-attributes" operation attribute with any supplied values
(attribute keywords) that were requested by the client but are not supported
by the IPP object.  (Issue 1.18)

3.3.3	Clarified that the IPP object MUST reject a Cancel-Job request if
the job is in 'completed', 'canceled', or 'aborted' job states.  (Issue

4.1.5	Clarified regarding the case-insensitivity of URLs to refer only to
the RFCs that define them.  (Issue 1.10) 

4.1.11	Clarified that 'boolean' is not a full-sized integer.  (Issue 1.38)

4.1.15	Clarified that 'resolution' is not three full-sized integers.
(Issue 1.20)

4.2.*	Clarified that standard values are keywords or enums, not names.
(Issue 1.49).

4.4.18, 4.4.19	Clarified that the "document-format-default" and
"document-format-supported" Printer Description attributes are REQUIRED to
agree with the table.  (Issue 1.4) 

4.4.21	Changed "queued-job-count" from OPTIONAL to RECOMMENDED.  (Issue

6.5, 12.8	Added new section to allow Attribute Groups to be registered
as extensions for being passed in operation requests and responses.  (Issue

7.	Updated the table of text and name attributes to agree with Section

8.5	Added a new section RECOMMENDING that the Get-Jobs SHOULD return
non-IPP jobs whether or not assigning them a job-id and job-uri.  Also
RECOMMENDED generating, if possible, job-id and job-uri and supporting other
IPP operations on foreign jobs as an implementer option.  (Issue 1.32)

9.	Updated document references.	Added a new error code 'server-error-job-canceled' (0x0508)
to be returned if a job is canceled by another client or aborted by the IPP
object while the first client is still sending the document data.  (Issue

16.3, 16.4	Moved these sections recommending operation processing steps
to the new Implementer's Guide (informational).  There indicated that all of
the error checks are not required, so an IPP object MAY be forgiving and
accept non-conforming requests.  However, a conforming client MUST supply
requests that would pass all of the error checks indicated.  (Issue 1.21)

Tom Hastings
(310) 333-6413

More information about the Ipp mailing list