I am in the process of merging what you have done into the Model
document. One of your issues below asks about "operations". I have
created a whole new section of the model document (section 2) that
covers all conformance issues. I created conformance requirements
subsections for "objects", "operations", "attributes", "best effort", "client",
and "server." I plan to post this by today.
Scott
************************************************************
Scott A. Isaacson
Print Services Consulting Engineer
Novell Inc., 122 E 1700 S, Provo, UT 84606
V: (801) 861-7366, (800) 453-1267 x17366
F: (801) 861-4025, E: scott_isaacson@novell.com
W: http://www.novell.com
************************************************************
>>> Roger K Debry <rdebry@us.ibm.com> 04/23/97 11:14am >>>
Classification:
Prologue:
Epilogue: Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: rdebry@us.ibm.com
phone: 1-303-924-4080
Following is the text version of the conformance white paper. It
has been modified to include comments from Bob Herriot. Any
additional comments??
IPP Conformance White Paper
This paper does not discuss where conformance should go in the
model document. Personally, I prefer to see conformance
described all together in one section, rather than spread
throughout the document. As an implementor it seems easier to be
sure that I've got a conforming application if the requirements
are all stated in one place.
IPP conforming implementations must do the following with respect
to attributes:
Issue: We need to describe conformance as it relates to
operations, security, etc.
A Printer implements an attribute if that attribute is in the
list of attributes that the Printer knows about, i.e. when
queried for that attribute the Printer will respond with the
values supported by the Printer for that attribute. A Printer may
exhibit a behavior that corresponds to the value of some
attribute, but if the Printer doesn't know about the attribute
name, then as far as IPP is concerned, it does not implement the
attribute. For example, if a printer prints 1-sided only, but it
does not know about the attribute "sides", then in terms of IPP
it does not implement the attribute "sides".
A Printer supports an attribute value if that value represents a
valid capability or state of the Printer, and the value is in the
list of attribute values returned in response to a query on that
attribute. If a value is not supported, that does not make a
statement about whether the Printer implements the value. For
example, an output device may be capable of printing both
1-sided and 2-sided-long-edge, but if an administrator sets up
the Printer to always only print 2-sided-long-edge, then only the
value 2-sided-long-edge is supported as far as IPP is concerned.
In response to a Get_Attributes or Get_Jobs operation
o If the client supplies an attribute and it is an attribute
implemented by the Printer, the Printer shall respond with all
currently supported values for that attribute. If the value
of an implemented attribute is unknown for any reason, the
Printer shall respond with the value "unknown".
Note: this requires an encoding of "unknown" for each
attribute syntax.
o If the client supplies an attribute and it is an attribute not
implemented by the Printer, the Printer shall respond with the
value of "unsupported" for that attribute.
Note: this requires an encoding of "unsupported" for each
attribute syntax.
o If the client supplies an attribute group that is implemented
by the Printer, the Printer shall respond with all currently
supported values for each implemented attribute in the group.
It shall not respond for unimplemented attributes in the
group. If the value of an attribute is unknown for any
reason, the Printer shall respond with the value "unknown" for
that attribute.
Each job and document attribute implemented by a Printer must
have a defined default value. This value will be the first value
returned in response to a query on that attribute. Furthermore,
each job and document attribute in this specification has a
defined behavior for cases where the attribute is not implemented
by the Printer. To be a conforming implementation, a Printer must
exhibit the specified behavior for attributes which it does not
implement. Otherwise the Printer must implement the attribute
with at least the value which describes its behavior. For
example, the default behavior for _sides_ is 1-sided. If an
output device only prints 2-sided-long, then it must implement
the sides attribute with the value 2-sided-long.
In response to a Print request, if a job or document attribute is
not supplied by the client
o and the Printer implements the attribute, the default value of
that attribute shall be used in printing the job. If a client
subsequently queries the job, such attributes shall be
included in the job as if the client had included them in the
original request.
o and the Printer does not implement the attribute, the Printer
shall use the default behavior defined for that attribute in
this specification. If the attribute is not defined in this
specification, i.e. it is a private extension, then the
Printer shall use the default behavior built into the Printer
for that extension. If a client subsequently queries the job,
such attributes shall not be included in the response.
In response to a Print request, if a job or document attribute is
supplied and the best-effort attribute is set to
substitute-as-needed, an IPP Printer
Note: The following assumes best-effort as currently defined
in the model document.
o shall use the supplied attribute value in the print operation
if the Printer implements the supplied attribute and supports
the supplied value.
o shall change the attribute value to the default value for the
supplied attribute if the Printer implements the supplied
attribute but does not support the supplied value. A return
code of "001" shall indicate that the job was accepted with
attribute substitution. A subsequent query of the
aforementioned attribute should return the substituted value.
Issue: What happens when the default attribute value is
"unknown"?
o shall ignore the attribute if the Printer does not implement
the supplied attribute. A return code of "001" will indicate
that the job was accepted with some attributes ignored. The
Printer shall add the unimplemented attributes to the created
job object with a value of "unsupported", making it easier for
a client to query the job and see the attributes which were
ignored. A subsequent Get-attributes operation will return the
unsupported attributes.
In response to a Print request, if the best-effort attribute is
set to do-not-substitute, an IPP Printer
o shall use the supplied attribute value in the print operation
if the Printer implements the supplied attributed and supports
the supplied value.
o shall reject the print job if the Printer implements the
supplied attribute but does not support the supplied value. A
return code of "109" will indicate that the job was rejected
because a supplied attribute value is unsupported.
o shall reject the print job if the Printer does not implement
the supplied attribute. A return code of "109" will indicate
that the job was rejected because a supplied attribute is not
implemented.
Sending a Query or Print request, an IPP client need not specify
any attributes. A response to a query may contain attributes and
values which the client does not implement.
Issue: Are there any attributes that are mandatory for a
client to set in a Print request?