attachment-0001


<br><font size=2 face="sans-serif">We would prefer a job ticket approach
(and have been lobbying for one in the PWG Semantic Model, including a
submission for a simple way for IPP to carry a job ticket and the recommendation
that we consider a simplified JDF JT as the basis... thereby leveraging
expended effort). So I support Bob Taylor's recommendations, in general,
and discussions regarding optimization. Several comments, however.</font>
<br>
<br><font size=2 face="sans-serif">1. Our proposal to add &quot;-actual&quot;
(to the existing cadra of IPP &quot;-supported&quot;, &quot;-default&quot;,
&quot;-ready&quot;, &quot;-requested&quot; etc. attributes) is intended
as a SIMPLE solution which could be supported in v1 of the Semantic Model
and PSI.</font>
<br><font size=2 face="sans-serif">2. At today's SM conference call we
said we will NOT try and define a Job Ticket for v1 (wise decision, as
I'm sure we've barely begun to imagine all the nuances of JT and got stuck,
almost immediately on the question of Job vs Doc JTs).</font>
<br><font size=2 face="sans-serif">3. Assuming it will take a while for
us to hash out the ideal JT for office applications I would like to see
us go forward with the rather benign &quot;-actual&quot; proposal</font>
<br><font size=2 face="sans-serif">4. Back on the JT thread... I do NOT
like the streamlining proposed (below) by Tom. Specifically, if we limit
Job Processing Actuals to only ones deferred from attributes declared during
job creation, we will MISS information if, for example, the PDL had embedded
commands that resulted in an action that was not requested. (ex. Job creation
was silent on copies, the PDL called for 3 copies). Our view is we WANT
to know exactly what HAPPENED... (we care less why). </font>
<br><font size=2 face="sans-serif">----------------------------------------------
<br>
Harry Lewis <br>
IBM Printing Systems <br>
---------------------------------------------- </font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>&quot;Hastings, Tom N&quot; &lt;hastings@cp10.es.xerox.com&gt;</b></font>
<br><font size=1 face="sans-serif">Sent by: owner-sm@pwg.org</font>
<p><font size=1 face="sans-serif">10/10/2002 05:38 PM</font>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To:
&nbsp; &nbsp; &nbsp; &nbsp;Harry Lewis/Boulder/IBM@IBMUS, &quot;TAYLOR,BOB
(HP-Vancouver,ex1)&quot; &lt;robert_b_taylor@hp.com&gt;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc:
&nbsp; &nbsp; &nbsp; &nbsp;&quot;McDonald, Ira&quot; &lt;imcdonald@sharplabs.com&gt;,
&quot;Zehler, Peter&quot; &lt;PZehler@crt.xerox.com&gt;, sm@pwg.org, printing-jobticket@freestandards.org</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject:
&nbsp; &nbsp; &nbsp; &nbsp;RE: SM&gt; Job &quot;Actual&quot; attributes</font>
<br>
<br><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp;</font></table>
<br>
<br><font size=2 color=blue face="Arial">I like Bob Taylor's idea of using
the same PWG Semantic Model Job and Document Processing attributes (probably
not PWG SM Description attributes) in a different context to indicate what
really happened, rather than inventing more xxx-actual attributes. &nbsp;The
PWG Semantic Model already uses this approach for Job Creation, in that
Document Processing attributes can be supplied at the Job Level in the
Create-Job operation and in each Send-Document operation. &nbsp;The IPP
Document object extension proposes re-using the same IPP Job Template attributes
as Document Template attributes, rather than inventing new &quot;document-xxx&quot;
Document Template attributes. &nbsp;(Also the IPP &quot;document-overrides&quot;
and &quot;page-overrides&quot; collection attributes re-use the existing
Job Template attributes for each override collection value, rather than
inventing new name mangling for them).</font>
<br><font size=3>&nbsp;</font>
<br><font size=2 color=blue face="Arial">However, I'd also like to suggest
a streamlining, by having the new Job Processing Actuals be only the ones
that deferred from the ones submitted in the Job Creation Request. &nbsp;This
would do two good things: &nbsp;Be much more compact and provide a useful
indication to the user about what happened differently from what he requested.
&nbsp;I suspect that any defaulting that the Printer supplied would wind
up in the Actuals group, but be of the form &quot;xxx&quot;, not &quot;xxx-default&quot;.
&nbsp;If the PDL had a different value and the Printer didn't override
the PDL, then the actual should be the value from the PDL. &nbsp;</font>
<br><font size=3>&nbsp;</font>
<br><font size=2 color=blue face="Arial">Of course, the Job Processing,
Job Description, Document Processing, and Document Description attributes
that the user submitted should also be in the Job History in just the form
that he submitted (as in the current IPP Job History for Job Template attributes
and soon to be Document Template attributes - see RFC 2911 section 4.3.7.2).</font>
<br><font size=3>&nbsp;</font>
<br><font size=2 color=blue face="Arial">The FSG Job Ticket API wants to
store results in the Job Ticket eventually as well.</font>
<br><font size=3>&nbsp;</font>
<br><font size=2 color=blue face="Arial">Comments?</font>
<br><font size=3>&nbsp;</font>
<br><font size=2 color=blue face="Arial">Tom</font>
<br><font size=2 face="Tahoma">-----Original Message-----<b><br>
From:</b> Harry Lewis [mailto:harryl@us.ibm.com]<b><br>
Sent:</b> Thursday, October 03, 2002 09:37<b><br>
To:</b> TAYLOR,BOB (HP-Vancouver,ex1)<b><br>
Cc:</b> McDonald, Ira; Zehler, Peter; sm@pwg.org<b><br>
Subject:</b> RE: SM&gt; Job &quot;Actual&quot; attributes<br>
</font>
<br><font size=2 face="sans-serif"><br>
I'm not opposed to new operations but I'll observe that multiple attributes
is in keeping with the way IPP is currently structured. <br>
---------------------------------------------- <br>
Harry Lewis <br>
IBM Printing Systems <br>
---------------------------------------------- </font><font size=3><br>
<br>
</font>
<table width=100%>
<tr valign=top>
<td width=1%>
<td width=33%><font size=1 face="sans-serif"><b>&quot;TAYLOR,BOB (HP-Vancouver,ex1)&quot;
&lt;robert_b_taylor@hp.com&gt;</b></font><font size=3> </font>
<p><font size=1 face="sans-serif">10/03/2002 09:42 AM</font><font size=3>
</font>
<td width=65%><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font><font size=1 face="sans-serif"><br>
 &nbsp; &nbsp; &nbsp; &nbsp;To: &nbsp; &nbsp; &nbsp; &nbsp;&quot;Zehler,
Peter&quot; &lt;PZehler@crt.xerox.com&gt;, Harry Lewis/Boulder/IBM@IBMUS,
&quot;McDonald, Ira&quot; &lt;imcdonald@sharplabs.com&gt;, sm@pwg.org</font><font size=3>
</font><font size=1 face="sans-serif"><br>
 &nbsp; &nbsp; &nbsp; &nbsp;cc: &nbsp; &nbsp; &nbsp; &nbsp;</font><font size=3>
</font><font size=1 face="sans-serif"><br>
 &nbsp; &nbsp; &nbsp; &nbsp;Subject: &nbsp; &nbsp; &nbsp; &nbsp;RE: SM&gt;
Job &quot;Actual&quot; attributes</font><font size=3> <br>
</font><font size=1 face="Arial"><br>
 &nbsp; &nbsp; &nbsp; </font></table>
<br><font size=3><br>
</font><font size=2 color=blue face="Courier New"><br>
I think I prefer the more &quot;operations&quot; or structurally-oriented
approach. &nbsp;The model of having multiple attributes that describe the
same &quot;feature&quot; in multiple states (capabilities, intent, process,
logging/audit), etc. &nbsp;seems fragile and error-prone (hence the current
&quot;process&quot; vs. &quot;product&quot; discrepancies in CIP4 ...).
&nbsp;I'd rather have us define the feature once, and then define operations
or structures that apply the workflow stage semantics. &nbsp;</font><font size=3>
<br>
 &nbsp;</font><font size=2 color=blue face="Courier New"><br>
bt</font><font size=3> </font><font size=2 face="Tahoma"><br>
-----Original Message-----<b><br>
From:</b> Zehler, Peter [mailto:PZehler@crt.xerox.com]<b><br>
Sent:</b> Thursday, October 03, 2002 4:43 AM<b><br>
To:</b> 'Harry Lewis'; McDonald, Ira<b><br>
Cc:</b> sm@pwg.org<b><br>
Subject:</b> RE: SM&gt; Job &quot;Actual&quot; attributes</font><font size=3><br>
</font><font size=2 color=blue face="Arial"><br>
Harry,</font><font size=3> <br>
 &nbsp;</font><font size=2 color=blue face="Arial"><br>
I like the concept. &nbsp;I prefer &quot;actual&quot; to &quot;chosen&quot;.
&nbsp;Have you considered new operations (e.g. &quot;GetActualJobAttributes&quot;
&nbsp;&quot;GetJobsHistory&quot;) to accomplish the same thing. &nbsp;It
would make Printers that implement a job receipt more explicit. &nbsp;There
would be no need for all the new attributes (i.e. &quot;ZZZ-actual&quot;).
&nbsp;On the other hand using attributes instead of new operations does
have the benefit of being able to retrieve both the requested and actual
attributes together and having a static representation that differentiates
the two. &nbsp;Perhaps using both the &quot;actual&quot; attributes and
new operations might be more explicit. &nbsp;</font><font size=3> <br>
 &nbsp;</font><font size=2 color=blue face="Arial"><br>
Of course there will probably need to be some housekeeping attributes added
to the printer for history management/configuration. &nbsp;I would prefer
that something like this be documented separately and referenced in the
PWG Semantic Model. &nbsp;The document would probably be an extension to
IPP.</font><font size=3> <br>
 &nbsp;</font><font size=2 color=blue face="Arial"><br>
Pete</font><font size=3> <br>
 &nbsp;</font>
<p><font size=3 face="Impact">Peter Zehler</font><font size=3> </font><font size=3 color=red><br>
XEROX</font><font size=3> </font><font size=2 face="Tahoma"><br>
Xerox Architecture Center</font><font size=3> </font><font size=2 face="Arial"><br>
Email: PZehler@crt.xerox.com</font><font size=3> </font><font size=2 face="Arial"><br>
Voice: &nbsp; &nbsp;(585) 265-8755</font><font size=3> </font><font size=2 face="Arial"><br>
FAX: &nbsp; &nbsp; &nbsp;(585) 265-8871 <br>
US Mail: Peter Zehler</font><font size=3> </font>
<p><font size=2 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; Xerox Corp.</font><font size=3>
</font><font size=2 face="Arial"><br>
 &nbsp; &nbsp; &nbsp; 800 Phillips Rd.</font><font size=3> </font><font size=2 face="Arial"><br>
 &nbsp; &nbsp; &nbsp; M/S 128-30E</font><font size=3> </font><font size=2 face="Arial"><br>
 &nbsp; &nbsp; &nbsp; Webster NY, 14580-9701</font><font size=3> </font>
<p><font size=2 face="Tahoma">-----Original Message-----<b><br>
From:</b> Harry Lewis [mailto:harryl@us.ibm.com]<b><br>
Sent:</b> Wednesday, October 02, 2002 11:57 PM<b><br>
To:</b> McDonald, Ira<b><br>
Cc:</b> sm@pwg.org<b><br>
Subject:</b> RE: SM&gt; Job &quot;Actual&quot; attributes</font><font size=3><br>
</font><font size=2 face="sans-serif"><br>
<br>
I'm fine with &quot;chosen&quot; vs. &quot;actual&quot;... not as concerned
about the name as the concept. In this case, actual might differ from requested
due to something like a PDL override (so &quot;chosen&quot; seems to fit)
or it COULD differ due to some circumstance (like the job was aborted prior
to all copies completing) in which case &quot;actual&quot; seems more apropos.
<br>
---------------------------------------------- <br>
Harry Lewis <br>
IBM Printing Systems <br>
---------------------------------------------- </font><font size=3><br>
</font>
<table width=100%>
<tr valign=top>
<td width=2%>
<td width=45%><font size=1 face="sans-serif"><b>&quot;McDonald, Ira&quot;
&lt;imcdonald@sharplabs.com&gt;</b></font><font size=3> </font>
<p><font size=1 face="sans-serif">10/02/2002 07:30 PM</font><font size=3>
</font>
<td width=51%><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font><font size=1 face="sans-serif"><br>
 &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;Harry Lewis/Boulder/IBM@IBMUS,
sm@pwg.org</font><font size=3> </font><font size=1 face="sans-serif"><br>
 &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;</font><font size=3>
</font><font size=1 face="sans-serif"><br>
 &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;RE: SM&gt; Job
&quot;Actual&quot; attributes</font><font size=3> </font><font size=1 face="Arial"><br>
<br>
 &nbsp; &nbsp; &nbsp;</font></table>
<br><font size=3><br>
</font><font size=2><tt><br>
<br>
Hi Harry,<br>
<br>
For what it's worth...<br>
<br>
Printer MIB used (from DPA I think...) the terminology of<br>
'Declared' or 'Requested' (for the input) and 'Chosen'<br>
(for what you're calling 'Actual' below).<br>
<br>
Cheers,<br>
- Ira McDonald<br>
<br>
-----Original Message-----<br>
From: Harry Lewis [mailto:harryl@us.ibm.com]<br>
Sent: Wednesday, October 02, 2002 5:56 PM<br>
To: sm@pwg.org<br>
Subject: SM&gt; Job &quot;Actual&quot; attributes<br>
<br>
<br>
<br>
In IPP, PWG Semantic Model and PSI we have Job Template attributes with<br>
&quot;sister&quot; (supported, default and ready) Printer Description attributes.
When<br>
discussing the purpose of a &quot;Job Ticket&quot; in the semantic model,
we often<br>
refer to Job Template attributes as the &quot;job ticket&quot; as these
carry<br>
production intent. By definition, when queried, Job Template attributes
must<br>
return the value associated with each attribute during submission. Thus,<br>
there is no way to query a job (or document) and learn WHAT ACTUALLY<br>
HAPPENED w.r.t. any particular attributed (ex. copies). This is covered
by<br>
the JDF job ticket but we have said JDF is too workflow oriented for<br>
(initial) inclusion into the PWG Semantic Model. <br>
<br>
I would like to propose a solution - the addition of a group of Job<br>
Description attributes referred to as &quot;-actual&quot;. These could
be extensions<br>
to the group of Job Progress attributes or a separate grouping of Job Actual<br>
(or &quot;Job Completion&quot;) attributes. I know, in IPP proper, we don't
have the<br>
notion of job &quot;history&quot; (the job &quot;disappears&quot; as soon
as it has completed)<br>
so &quot;actuals&quot; would not be very useful. But in the semantic model
and PSI<br>
we're trying to overcome this. To the extent that we are reluctant to<br>
embrace a full fledged job ticket, the addition of &quot;-actual&quot;
attributes<br>
should go a long way toward providing much of the essential JT functionality<br>
that was previously missing for non-produciton environments. <br>
<br>
For example: <br>
<br>
+===================+======================+<br>
| Job Template &nbsp; &nbsp; &nbsp;|Job Description:Actual|<br>
| &nbsp; Attribute &nbsp; &nbsp; &nbsp; | &nbsp; Value Attribute &nbsp;
&nbsp;|<br>
+===================+======================+<br>
| copies &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;| copies-actual &nbsp;
&nbsp; &nbsp; &nbsp;|<br>
| (integer (1:MAX)) | (integer (1:MAX)) &nbsp; &nbsp;|<br>
+-------------------+----------------------+<br>
| finishings &nbsp; &nbsp; &nbsp; &nbsp;| finishings-actual &nbsp; &nbsp;|<br>
|(1setOf type2 enum)|(1setOf type2 enum) &nbsp; |<br>
+-------------------+----------------------+<br>
| sides &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | sides-actual &nbsp;
&nbsp; &nbsp; &nbsp; |<br>
| (type2 keyword) &nbsp; | (type2 keyword) &nbsp; &nbsp; &nbsp;|<br>
+-------------------+----------------------+<br>
| number-up &nbsp; &nbsp; &nbsp; &nbsp; | number-up-actual &nbsp; &nbsp;
|<br>
| (integer (1:MAX)) | (integer (1:MAX)) &nbsp; &nbsp;|<br>
+-------------------+----------------------+<br>
| orientation- &nbsp; &nbsp; &nbsp;|orientation-requested-|<br>
| &nbsp;requested &nbsp; &nbsp; &nbsp; &nbsp;| &nbsp;actual &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|<br>
| &nbsp; (type2 enum) &nbsp; &nbsp;| &nbsp;(type2 enum) &nbsp; &nbsp; &nbsp;
&nbsp;|<br>
+-------------------+----------------------+<br>
| media &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | media-actual &nbsp;
&nbsp; &nbsp; &nbsp; |<br>
| (type3 keyword | &nbsp;| (type3 keyword | &nbsp; &nbsp; |<br>
| &nbsp; &nbsp;name) &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;| &nbsp; &nbsp;name)
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br>
+-------------------+----------------------+<br>
| printer-resolution| printer-resolution- &nbsp;|<br>
| (resolution) &nbsp; &nbsp; &nbsp;| &nbsp;actual &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; |<br>
| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | (resolution)
&nbsp; &nbsp; &nbsp; &nbsp; |<br>
+-------------------+----------------------+<br>
| print-quality &nbsp; &nbsp; | print-quality-actual |<br>
| (type2 enum) &nbsp; &nbsp; &nbsp;| (type2 enum) &nbsp; &nbsp; &nbsp;
&nbsp; |<br>
+-------------------+----------------------+<br>
<br>
---------------------------------------------- <br>
Harry Lewis <br>
IBM Printing Systems <br>
---------------------------------------------- </tt></font><font size=3><br>
</font>
<br>