attachment-0001


<br><font size=2 face="Arial">1. Help me out as to where PSI states this
it is mandatory to support modification of a Document object after the
job is submitted.</font><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif">2. &nbsp;I support healthy alignment
with FSG and I've been pushing for a job ticket interface to PSI. It's
just... every time I ask for a show of hands regarding actual support for
PDL-override the response is always lackluster.</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;McDonald, Ira&quot; &lt;imcdonald@sharplabs.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">04/18/2003 12: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;Hastings,
Tom N&quot; &lt;hastings@cp10.es.xerox.com&gt;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc:
&nbsp; &nbsp; &nbsp; &nbsp;ipp@pwg.org, ps@pwg.org, sm@pwg.org</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject:
&nbsp; &nbsp; &nbsp; &nbsp;RE: SM&gt; Re: IPP&gt; 4 significant
proposed increases in conformance &nbsp; &nbsp; &nbsp; &nbsp; requirements
for the IPP Document object spec</font></table>
<br>
<br>
<br><font size=2><tt>Hi Harry,<br>
<br>
(1) PSI has ALREADY made all of the equivalent WSDL methods REQUIRED.<br>
I'm merely suggesting equivalent functionality for the IPP Document<br>
object implementors. &nbsp;And yes it _is_ like IPPv2 - the Document <br>
object is the main thing missing from IPP/1.1. &nbsp;But this is just<br>
and extension. &nbsp;We're not mandating that all IPP/1.1 implementations<br>
support the Document object and operations.<br>
<br>
(2) The FSG expects to (using PAPI/1.0 API) convert any job ticket<br>
instructions to IPP job stream instructions. &nbsp;The job ticket support<br>
of PDL override is useless in the Free Standards Linux environment<br>
without the correspond IPP attributes.<br>
<br>
Cheers,<br>
- Ira<br>
<br>
<br>
<br>
-----Original Message-----<br>
From: Harry Lewis [mailto:harryl@us.ibm.com]<br>
Sent: Friday, April 18, 2003 12:16 PM<br>
To: Hastings, Tom N<br>
Cc: ipp@pwg.org; ps@pwg.org; sm@pwg.org<br>
Subject: SM&gt; Re: IPP&gt; 4 significant proposed increases in conformance<br>
requirements for the IPP Document object spec<br>
<br>
<br>
<br>
I'm afraid we are <br>
<br>
1. Over complicating the Document Object <br>
 &nbsp;- This is really beginning to look like IPPv2 <br>
2. Risking lackluster adoption based on unnecessary mandatory operations
<br>
<br>
Look at the premise behind (2), below. &quot;... users should be able to
modify a<br>
document object after the job is submitted...&quot;. This might be something
nice<br>
for some users but there are simpler alternatives (such as canceling the
job<br>
and resubmitting it).... that don't require an architectural mandate. <br>
<br>
As for (4) guaranteeing pdl-override... I've always been opposed to the<br>
concept of pdl-override... it's premise being that we can't keep ourselves<br>
from generating Postscript with embedded production instructions and even
if<br>
we could there is a mass of Postscript (still) being used for interchange.<br>
This was not true when me made the error of specifying pdl-override in
IPP<br>
and it is less true today. Separating content from production instruction<br>
via the use of a job ticket has always been the goal. That goal is now<br>
within reach. I think, then, it is time to consider deprecating<br>
pdl-override...certainly not elevating the &quot;feature&quot; by mandating
further<br>
complexity. <br>
---------------------------------------------- <br>
Harry Lewis <br>
IBM Printing Systems <br>
---------------------------------------------- <br>
<br>
<br>
&quot;Hastings, Tom N&quot; &lt;hastings@cp10.es.xerox.com&gt; <br>
Sent by: owner-ipp@pwg.org <br>
04/17/2003 03:00 PM &nbsp; &nbsp; &nbsp; &nbsp; <br>
 &nbsp; &nbsp; &nbsp; &nbsp;To: &nbsp; &nbsp; &nbsp; &nbsp;sm@pwg.org <br>
 &nbsp; &nbsp; &nbsp; &nbsp;cc: &nbsp; &nbsp; &nbsp; &nbsp;ps@pwg.org,
ipp@pwg.org <br>
 &nbsp; &nbsp; &nbsp; &nbsp;Subject: &nbsp; &nbsp; &nbsp; &nbsp;IPP&gt;
4 significant proposed increases in conformance<br>
requirements for &nbsp; &nbsp; &nbsp; &nbsp; the IPP Document object spec<br>
<br>
<br>
<br>
Attendees: &nbsp;Harry Lewis, Bob Taylor, Dave Hall, Lee Farrell, Gail
Songer,<br>
Ira McDonald, Peter Zehler, Tom Hastings (did I miss anyone?)<br>
<br>
At today's PWG Semantic Model telecon we did a page by page review of the<br>
IPP Document Object Spec in preparation for Last Call:<br>
<br>
ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030407.pdf.zip<br>
<br>
This mail note contains several significant changes in Printer conformance<br>
requirements that we agreed to for the indicated reasons. &nbsp;However,
because<br>
of their significance, we agreed to post these changes to the DL for a
two<br>
week comment period. &nbsp;Objectsion and comments on these changes are
due by<br>
Friday, May 2, end of business. &nbsp;Silence will be interpreted as approval,
so<br>
if you object, please send email.<br>
<br>
The other less significant agreements will be posted in a separate mail
note<br>
as minutes. &nbsp;We resolved all of the issues and did the page by page
review<br>
up to page 42 Table 7. &nbsp;We will continue the page by page at another
two<br>
hour telecon next Thursday, April 24, same time: 1-3 PM EDT (10-12 PDT)
with<br>
the same version of the specification. &nbsp;Same call-in number and HP
webex.<br>
<br>
Agreed to significant conformance requirements changes:<br>
<br>
<br>
1. Change the Send-URI operation and the corresponding<br>
&quot;reference-uri-schemes-supported&quot; (1setOf uriScheme) Printer
Description<br>
attribute from OPTIONAL to REQUIRED for a Printer to support. &nbsp;We
agreed<br>
that a conforming implementation MAY have an empty list for the<br>
&quot;reference-uri-schemes-supported&quot; Printer Description attribute.<br>
<br>
Reason: &nbsp;PSI requires this operation (and has no OPTIONAL attributes).<br>
Optional operations are much less likely to get support by clients. &nbsp;It
is<br>
best practice for an OPTIONAL extension specification (such as this spec)
to<br>
have no OPTIONAL operations, so that user clients will receive the same<br>
level of service from all Printer implementations that support this<br>
extension.<br>
<br>
<br>
2. Change the Set-Document-Attributes operation from OPTIIOAL to REQUIRED<br>
for a Printer to support.<br>
<br>
Reason: This is the Document object spec and users should be able to modify<br>
a Document object after the job is submitted. &nbsp;Optional operations
are much<br>
less likely to get support by users clients. &nbsp;It is best practice
for an<br>
OPTIONAL extension specification (such as this spec) to have no OPTIONAL<br>
operations, so that user clients will receive the same level of service
from<br>
all Printer implementations that support this extension.<br>
<br>
<br>
3. Change the Set-Job-Attributes operation from OPTIONAL to RECOMMENDED
for<br>
a Printer to support.<br>
<br>
Reason: To go along with the change in the conformance requirements for
the<br>
Set-Document-Attributes operation. &nbsp;However, don't REQUIRE<br>
Set-Job-Attributes, since most of the interesting attributes are document<br>
attributes, not job attributes.<br>
<br>
<br>
4. Add an OPTIONAL 'guaranteed&quot; value (see [ippsave] section 8.1)
for the<br>
&quot;pdl-overrides-supported&quot; Printer Description attribute (REQUIRED
in<br>
[rfc2911] section 4.4.28) to augment 'not-attempted', and 'attempted'<br>
values. &nbsp;Also add a REQUIRED &quot;pdl-override-attributes-guaranteed&quot;
(1setOf<br>
type2 keyword) Printer Description attribute. &nbsp;The values indicate
those Job<br>
Template and Document Template attributes for which the Printer guarrantees<br>
success in overriding the corresponding instruction in the PDL data. &nbsp;The<br>
values of this attribute returned in the Get-Printer-Attributes response
MAY<br>
be colored by the &quot;document-format&quot; operation attribute supplied
by the<br>
client in the request, if the Printer's guarrantee depends on the document<br>
format. &nbsp;A conforming Printer MAY return 'none' as the value. &nbsp;<br>
<br>
Reason: &nbsp;The IPPFAX needs the ability for the Printer to indicate
which Job<br>
Template and Document Template attributes the Printer is able to guarantee<br>
success in overriding the PDL. &nbsp;Waiting for the Production Printing
Set2<br>
[ippsave] to be updated does meet the schedule for IPPFAX which is also<br>
trying to go out to last call. &nbsp;Also this extension is analoguous
to our<br>
addition of &quot;job-mandatory-attributes&quot; to give a finer granularity
to<br>
&quot;ipp-attribute-fidelity&quot; (boolean) operation attribute. &nbsp;<br>
<br>
<br>
Please send comments by Friday, May 2, 2003.<br>
<br>
Thanks,<br>
Tom<br>
</tt></font>
<br>