I agree that we need to "solidly define when a Printer should actually
attempt to process a job in the face of incorrect/incompatible job
attributes specified by the client."
Unfortunately, I did not copy into my mail note the semantics already
in the draft that a client supplied attribute without an adornment shall
be implemented by the Printer or the Printer shall reject the job.
(My mail note was not attempting to change that fundamental concept,
which your example shows is the right one.)
So your concerns are handled. If the simple simplex desktop printer
gets a Print request with sides=2 and that Printer doesn't implement
the sides attribute (or if the Printer does implement the sides attribute
but only supports the value 1), then that Printer shall reject the job.
Only if the clients includes the adornment: "best-efforts" (which we
agreed in the telecon today to change to a single job attribute),
shall the Printer ignore an attribute (or attribute value) that it doesn't
understand or support.
Ok?
Tom
At 09:38 03/21/97 PST, JK Martin wrote:
>In reading Tom's posting (attached below), it seems that we really need
>to solidly define when a Printer should actually attempt to process a
>job in the face of incorrect/incompatible job attributes specified by
>the client.
>
>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 -----
>
>>From ipp-owner@pwg.org Fri Mar 21 11:33 EST 1997
>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 -----
>
>