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. 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>"McDonald, Ira" <imcdonald@sharplabs.com></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"> </font>
<br><font size=1 face="sans-serif"> To:
Harry Lewis/Boulder/IBM@IBMUS, "Hastings,
Tom N" <hastings@cp10.es.xerox.com></font>
<br><font size=1 face="sans-serif"> cc:
ipp@pwg.org, ps@pwg.org, sm@pwg.org</font>
<br><font size=1 face="sans-serif"> Subject:
RE: SM> Re: IPP> 4 significant
proposed increases in conformance 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. And yes it _is_ like IPPv2 - the Document <br>
object is the main thing missing from IPP/1.1. But this is just<br>
and extension. 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. 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> Re: IPP> 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>
- 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. "... users should be able to
modify a<br>
document object after the job is submitted...". 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 "feature" by mandating
further<br>
complexity. <br>
---------------------------------------------- <br>
Harry Lewis <br>
IBM Printing Systems <br>
---------------------------------------------- <br>
<br>
<br>
"Hastings, Tom N" <hastings@cp10.es.xerox.com> <br>
Sent by: owner-ipp@pwg.org <br>
04/17/2003 03:00 PM <br>
To: sm@pwg.org <br>
cc: ps@pwg.org,
ipp@pwg.org <br>
Subject: IPP>
4 significant proposed increases in conformance<br>
requirements for the IPP Document object spec<br>
<br>
<br>
<br>
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>
</tt></font>
<br>