attachment-0001


<br><font size=2 face="sans-serif">I'm afraid we are</font>
<br>
<br><font size=2 face="sans-serif">1. Over complicating the Document Object
</font>
<br><font size=2 face="sans-serif">&nbsp; - This is really beginning to
look like IPPv2</font>
<br><font size=2 face="sans-serif">2. Risking lackluster adoption based
on unnecessary mandatory operations</font>
<br>
<br><font size=2 face="sans-serif">Look at the premise behind (2), below.
&quot;... users should be able to modify a document object after the job
is submitted...&quot;. This might be something nice for some users but
there are simpler alternatives (such as canceling the job and resubmitting
it).... that don't require an architectural mandate. </font>
<br>
<br><font size=2 face="sans-serif">As for (4) guaranteeing pdl-override...
I've always been opposed to the concept of pdl-override... it's premise
being that we can't keep ourselves from generating Postscript with embedded
production instructions and even if we could there is a mass of Postscript
(still) being used for interchange. This was not true when me made the
error of specifying pdl-override in IPP and it is less true today. Separating
content from production instruction via the use of a job ticket has always
been the goal. That goal is now within reach. I think, then, it is time
to consider deprecating pdl-override...certainly not elevating the &quot;feature&quot;
by mandating further complexity. </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-ipp@pwg.org</font>
<p><font size=1 face="sans-serif">04/17/2003 03:00 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;sm@pwg.org</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc:
&nbsp; &nbsp; &nbsp; &nbsp;ps@pwg.org, ipp@pwg.org</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject:
&nbsp; &nbsp; &nbsp; &nbsp;IPP&gt; 4 significant proposed increases
in conformance requirements for &nbsp; &nbsp; &nbsp; &nbsp; the
IPP Document object spec</font></table>
<br>
<br>
<br><font size=2><tt>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>
<br>
</tt></font>
<br>