Subject: IPP> MOD - Incompatible attribute specs: To Print or Not To Print?

From: JK Martin <[email-masked]>
Date: Fri, 21 Mar 1997 12:38:14 -0500 (EST)

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 [email-masked] Fri Mar 21 11:33 EST 1997
Date: Fri, 21 Mar 1997 08:27:46 PST
To: [email-masked]
From: Tom Hastings <[email-masked]>
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 -----

---

From: Tom Hastings <[email-masked]>
Date: Fri, 21 Mar 1997 16:33:35 PST

Jay,

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

---

From: [email-masked] (Robert Herriot)
Date: Fri, 21 Mar 1997 18:54:03 -0800

> From [email-masked] Fri Mar 21 09:38:41 1997
> 
> 

Am I correct that your "allornone" attribute is the same idea as the 
best-effort job attribute we discussed today.  The best-effort attribute
has at least two values. One is "honor-all-attributes-or-print-nothing",
and another is "print-and-try-your-best-to-honor-all-attributes".

---

From: JK Martin <[email-masked]>
Date: Sat, 22 Mar 1997 15:18:39 -0500 (EST)

Bob,

Our "allornone" attribute is boolean, where True implies that all
aspects of the printing (including attribute parsing, etc) must
succeed (or be valid), else the job is cancelled.

I really like the resolution of "best-effort" in the telecon on
March 21, whereby that attribute becomes a single, job-wide attribute.

	...jay

----- Begin Included Message -----

>From [email-masked] Fri Mar 21 21:57 EST 1997
Date: Fri, 21 Mar 1997 18:54:03 -0800
From: [email-masked] (Robert Herriot)
To: [email-masked], [email-masked]
Subject: Re: IPP> MOD - Incompatible attribute specs: To Print or Not To Print?

----- End Included Message -----