attachment-0001
<br><font size=2 face="sans-serif">At least at one point, there was also
the notion of QUALDOCs as a "driverless" paradigm. No need to
reopen the debate... just embellishing the stated history. </font>
<br>
<br><font size=2 face="sans-serif">I don't see the black/white - either/or
that Tom portrays (if Sender doesn't query "media-ready", then
the IPPFAX protocol is an Electronic Document Transfer Protocol... if Sender
cares for certain that the document was correctly imaged then having Sender
query "media-ready" makes sense...). </font>
<br>
<br><font size=2 face="sans-serif">Scaling is a FEATURE intended to facilitate
a wider range of compatibility. We should allow this to work IPPFAX will
be most useful if we enable SYSTEMS that perform the desired function.
The PERCEPTION of a sheet going in the scanner and simultaneously coming
out on a remote printer is, of course, just that... a PERCEPTION. </font>
<br><font size=2 face="sans-serif">----------------------------------------------
<br>
Harry Lewis <br>
Chairman - IEEE-ISTO Printer Working Group<br>
http://www.pwg.org<br>
IBM Printing Systems <br>
http://www.ibm.com/printers<br>
303-924-5337<br>
---------------------------------------------- </font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>"Wagner,William"
<WWagner@NetSilicon.com></b> </font>
<br><font size=1 face="sans-serif">Sent by: owner-ifx@pwg.org</font>
<p><font size=1 face="sans-serif">06/05/2003 06:40 PM</font>
<td width=59%>
<table width=100%>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td valign=top><font size=1 face="sans-serif">"Hastings, Tom N"
<hastings@cp10.es.xerox.com>, "Gail Songer" <gail.songer@peerless.com></font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td valign=top><font size=1 face="sans-serif"><ifx@pwg.org></font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td valign=top><font size=1 face="sans-serif">RE: IFX> Media-Ready [and
is IPPFAX a Device Protocol or an Electronic Document Exchange Protocol?]</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2><tt>Although I have no strong feelings on this, I recall
several thoughts from "the early days" of this activity. Granted
that much has happened since and these ideas may no longer be germain,
some vestage may explain why the medi-ready requirement existed.<br>
<br>
1. It was called QualDocs, not FAX. It was not intended to replicate facsimile,
but was to implement peoples perception of FAX (a reliable, secure, sure
way to "send a document over the wire" ) without the defficiencies
of existing FAX ( speed, quality, flexibility). The fact that traditional
fax is not necesarily reliable nor secure nor sure did not mean that QualDocs
could have the same problems. The notion was that FAX was well established
and prevalent and that there would need to be a compelling advanage to
QualDocs for it to be accepted.<br>
<br>
2. The "sure" perception was that as an input sheet is being
scanned in the scanner, a facsimile of that sheet is comming out of
the receiver. This perception would be addressed by determining whether
there was proper media ready, and signalling when the last sheet was correctly
printed. Presumably, if the tranmission would be stored rather than printed,
the user would be notified, would have the option of cancelling and would
have the option to ask for an asynchronous notification when the document
was printed.<br>
<br>
Bill Wagner<br>
<br>
-----Original Message----- <br>
From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] <br>
Sent: Thu 6/5/2003 7:50 PM <br>
To: Gail Songer <br>
Cc: ifx@pwg.org <br>
Subject: RE: IFX> Media-Ready [and is IPPFAX a Device Protocol or an
Electronic Document Exchange Protocol?]<br>
<br>
<br>
Gail,<br>
<br>
Sounds like there is growing consensus to get rid of the "media-ready"
Receiver attribute in IPPFAX and get rid of the RECOMMENDATION that the
Sender query it. This makes IPPFAX even simpler.<br>
<br>
Also with the choice media type, there is yet another reason for the Sender
not to query the Receiver's "media-ready" attribute. The
Sender can assume that the choice a4 or letter is supported for IPPFAX
and doesn't even have to query the Receiver's "media-supported"
attribute. <br>
<br>
Tom<br>
<br>
-----Original
Message-----<br>
From:
Gail Songer [mailto:gail.songer@peerless.com]<br>
Sent:
Thursday, June 05, 2003 08:12<br>
To:
Hastings, Tom N<br>
Cc:
ifx@pwg.org<br>
Subject:
RE: IFX> Media-Ready [and is IPPFAX a Device Protocol or an Electronic
Document Exchange Protocol?]<br>
<br>
<br>
<br>
Hi
Tom,<br>
<br>
<br>
<br>
I’ve
been mulling this topic and I believe that media-ready was required because
we were going to require the client to format the job based on the size
of the paper that could be printed (sender makes right).<br>
<br>
<br>
<br>
However,
now that we allow scaling and that we are focusing repositories, maybe
this requirement can be lifted.<br>
<br>
<br>
<br>
Gail
Songer<br>
<br>
Peerless
Systems Corp<br>
<br>
gsonger@peerless.com<br>
<br>
<br>
<br>
-----Original
Message-----<br>
From:
Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] <br>
Sent:
Friday, May 30, 2003 3:06 PM<br>
To:
Gail Songer<br>
Cc:
ifx@pwg.org<br>
Subject:
RE: IFX> Media-Ready [and is IPPFAX a Device Protocol or an Electronic
Document Exchange Protocol?]<br>
<br>
<br>
<br>
Gail,<br>
<br>
<br>
<br>
I
suspect that the reason that the IPPFAX spec says that the Receiver MUST
support "media-ready" was because the spec says that the IPPFAX
Sender SHOULD query the "media-ready" Printer attribute. <br>
<br>
<br>
<br>
I
also think that the mind set of IPPFAX had been a single Device, so that
the fan-out to multiple devices wasn't even a consideration in being difficult
to reflect the "media-ready" value(s) correctly. For example,
the statement in the Introduction:<br>
<br>
<br>
<br>
"The
target market for an IPPFAX receiver is a midrange imaging device that
can support the minimum memory requirements that are required by the data
format PDF/is, but the image format is structured in such a way that the
Receiver is not required to include a disk or other permanent storage."<br>
<br>
<br>
<br>
On
the other hand, the definition of Receiver is:<br>
<br>
<br>
<br>
"Receiver
The Printer object that accepts IPPFAX protocol operations and receives
the Document sent by the Sender. A Receiver offers the IPPFAX Print
Service (by definition)."<br>
<br>
<br>
<br>
So
the real question is:<br>
<br>
<br>
<br>
OK
that the IPPFAX Sender not bother with querying "media-ready",
but should send the IPPFAX PDF/is document whether the media is ready or
not? <br>
<br>
<br>
<br>
If
the Sender doesn't query "media-ready", then the IPPFAX protocol
is an Electronic Document Transfer Protocol, i.e., get the bits from the
Sender to the Receiver, rather than get the Quality Document Successfully
Printed onto Paper Service. The mind set of the WG does shift from
one paradigm to the other from time to time (and from place to place within
the IPPFAX Protocol spec itself).<br>
<br>
<br>
<br>
As
another example of this vacilation between defining a Device Protocol versus
an Electronic Document Exchange Service, is the idea that the IPPGET notification
is going to indicate whether the paper got printed OK. To me that
means we are talking about getting the document successfully transferred
to paper. Therefore, with that mind set, having the Sender query
the "media-ready" makes a lot of sense if the Sending User cares
about knowing for certain that the document was correctly imaged onto paper.<br>
<br>
<br>
<br>
Tom<br>
<br>
<br>
<br>
-----Original Message-----<br>
From:
Gail Songer [mailto:gail.songer@peerless.com]<br>
Sent:
Friday, May 30, 2003 06:32<br>
To:
ifx@pwg.org<br>
Subject:
IFX> Media-Ready<br>
<br>
At Wednesday’s telecom, we discovered that Media-Ready was Required
in one spot and optional in another. Ira was of the opinion that
it should be PROHIBIED.<br>
<br>
<br>
<br>
Does anyone else have opinion (or remember why it was “Required”?)<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
Gail Songer<br>
<br>
Peerless Systems Corp<br>
<br>
gsonger@peerless.com<br>
<br>
<br>
<br>
<br>
</tt></font>
<br>