For example, using Tom's approach below, say I want to print a 500 page
manual on a small desktop printer, and that I really want duplex output
(since I'm about to hop on an airplane and plan to read the document in
flight).
According to Tom's approach, the desktop printer will merrily print all
500 pages...but do so in a simplex manner. Wouldn't this be considered
a major waste of paper? (Not to mention the user's frustration.)
Put simply, when (if ever?) should a job submission be rejected due to
incompatible attribute specifications?
Underscore's forte is in the area of network printer drivers and printing
system support software. We have already encountered the situation where
certain attribute problems are generally acceptable (ie, go ahead and
print "as best you can"), whereas other kinds of attribute problems really
mandate a rejection of the job (to save valuable Earth resources, etc).
To solve this kind of problem, most of our software provides a special
attribute named "allornone" that a user can specify to say "if any part
of the job fails, then cancel the entire rest of the job". Part of the
job processing involves ensure all specified attributes are valid for
the target printer; hence, if "allornone" is specified--but one or more
attributes is invalid for the target printer--then the job is cancelled
(and a message is sent to the user describing the details of the failure).
I think we need to define the conditions under which a job is rejected
due to incompatible attributes specified by the client.
Comments?
...jay
----- Begin Included Message -----
Date: Fri, 21 Mar 1997 08:27:46 PST
To: ipp@pwg.org
From: Tom Hastings <hastings@cp10.es.xerox.com>
Subject: IPP> MOD - towards conformance/simplification
Here are two proposals for simplification of the Model and for
actually specifying some conformance (which is where the rubber
hits the road in determining what has to be implemented).
1. Lets make a pass through the document and see which attributes
we can make "conditionally mandatory" to use the SNMP parlance.
A conditionally mandatory attribute need not be implemented if the
implementation does not have the feature that the attribute controls.
For example, a simplex printer need not implement the sides attribute
and a printer that has no finishing need not implement the finishing
and a Printer that cannot do multiple copies from a single document
need not implement the copies attribute. A Printer that does not
allow the administrator to specify supported values need only implement
the values that are ready (like the Printer MIB). A Printer with a single
input tray and no means to request the operator to switch the media need
not implement the media attribute. etc. etc.
Thus an IPP Printer embedded in a simple desktop printer would not have
to deal with many of the attributes in the Model. It would not have
to return them at all in a Get Attributes or a Get Jobs Response.
The Printer would ignore them if submitted in a Print request.
A client either is a driver for that particualar printer and so will not
send any attributes that the Printer doesn't implement or the client should
first request the job template from the Printer and get only the attributes
that that Printer implements.
2. Lets make ALL adornments conditionally mandatory.
a. I believe that we have chosen the adornments, so that the simplest
implementation is without any adornments.
b. A conforming Printer shall ignore any adornments it doesn't understand.
c. Also adorments are keywords that can be added to after the standard
is done through type 2 keyword registration with the PWG and IANA.
I agree with Bob that we don't need to actually agree on the above
simplification before publishing our internet draft, but I wanted to
give heart to those who think what we have is too complicated for
Printers embedded in a simple desktop output device (one, but not our
only, goal).
So we could just list them as Issues for now.
Tom
----- End Included Message -----