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"> - 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.
"... users should be able to modify a document object after the job
is submitted...". 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 "feature"
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>"Hastings, Tom N" <hastings@cp10.es.xerox.com></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"> </font>
<br><font size=1 face="sans-serif"> To:
sm@pwg.org</font>
<br><font size=1 face="sans-serif"> cc:
ps@pwg.org, ipp@pwg.org</font>
<br><font size=1 face="sans-serif"> Subject:
IPP> 4 significant proposed increases
in conformance requirements for the
IPP Document object spec</font></table>
<br>
<br>
<br><font size=2><tt>Attendees: 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. However,
because<br>
of their significance, we agreed to post these changes to the DL for a
two<br>
week comment period. Objectsion and comments on these changes are
due by<br>
Friday, May 2, end of business. 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. We resolved all of the issues and did the page by page
review<br>
up to page 42 Table 7. 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. 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>
"reference-uri-schemes-supported" (1setOf uriScheme) Printer
Description<br>
attribute from OPTIONAL to REQUIRED for a Printer to support. We
agreed<br>
that a conforming implementation MAY have an empty list for the<br>
"reference-uri-schemes-supported" Printer Description attribute.<br>
<br>
Reason: PSI requires this operation (and has no OPTIONAL attributes).<br>
Optional operations are much less likely to get support by clients. 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. Optional operations
are much<br>
less likely to get support by users clients. 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. 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" value (see [ippsave] section 8.1)
for the<br>
"pdl-overrides-supported" Printer Description attribute (REQUIRED
in<br>
[rfc2911] section 4.4.28) to augment 'not-attempted', and 'attempted'<br>
values. Also add a REQUIRED "pdl-override-attributes-guaranteed"
(1setOf<br>
type2 keyword) Printer Description attribute. 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. The<br>
values of this attribute returned in the Get-Printer-Attributes response
MAY<br>
be colored by the "document-format" operation attribute supplied
by the<br>
client in the request, if the Printer's guarrantee depends on the document<br>
format. A conforming Printer MAY return 'none' as the value. <br>
<br>
Reason: 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. 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. Also this extension is analoguous
to our<br>
addition of "job-mandatory-attributes" to give a finer granularity
to<br>
"ipp-attribute-fidelity" (boolean) operation attribute. <br>
<br>
<br>
Please send comments by Friday, May 2, 2003.<br>
<br>
Thanks,<br>
Tom<br>
<br>
</tt></font>
<br>