At 03:16 AM 12/29/96 -0500, Keith Moore wrote:
Raymond:
>> For true "internet-printing" I think the decoupled scenario will
>> flourish, including the submission to Kinkos. Time will tell...
Keith:
>While I have no reason to doubt this, where do you think the market
>for such a service will come from?
It's nice to get such an open question. I have previously written white
papers on this topic, and as usual, I do indeed have some opinion. (Please
note that I use "Kinkos" below in most cases as a general name of copy
shops...)
As was mentioned by Beau Vrolyk of Xerox at the last IOC'96 conference in
S.D., "Kinko-net" is being established as we speak. I just looked at the
kinkos web site, and could see nothing showing there yet. However, since
Kinkos is nearly 100% Xerox copiers and other equipment, I'm sure Xerox has
some interest in helping Kinkos provide such as service. I don't have any
other inside information about this service, and maybe someone from Xerox
can provide additional details. However, we may have some problem in
getting cooperation since it is a competitive business. Unless cooperation
is somehow obilgitory, I doubt you will get information before the release
of such a service.
But let's consider what is actually needed by the customer of such a
service and at what level the interaction should take place. This is
actually fairly easy to determine. Just go down to your local copy-shop and
look at their job-submission form. It talks of the _desired result_ as seen
from the customer's eyes. It does _not_ reveal the internal intricacies of
their operation. Consider the following:
Used in Job Submission Not Used in Job Submission
---------------------- --------------------------
Paper Size Paper Tray #
Paper Type (bond, etc)
Paper Color
Holes punched Paper with holes vs. drilling
stapled, where Auto stapling vs. Manual
simplex vs. duplex double-sided copying vs. manual flipping
sides of original printer interpreter language
(jobs are scanned from originals, usually)
binding type binder device used
Customer Name, etc.
Customer Account #
Customer Credit Card, etc.
Submitter Name, etc.
Contact Telephone #
Delivery Name, etc.
Desired Completion time State of job queues
So, I will imagine that Kinkos will set up a cgi script-based submission
process to collect this information. If the Desired completion time is not
attainable, Kinkos will have to "negotiate" with the customer to reach a
mutually agreeable time for completion. This is a commitment on the part of
Kinkos, not just an estimate. If you arrive for pickup at the scheduled
time, they had better have the documents done or their customer will be lost.
Now, INTERNAL to the Copy Shop, they will submit these jobs in various ways
to their equipment and manage queues and the like. The configuration of
their equipment and the use of their resources is rarely (if ever) revealed
to the customer. The sort of submission envisioned by the ipp protocol
would certainly be a good thing to use here.
Also in Beau Vrolyk's presentation, he discussed the Doc-Tek printer. Most
printer people will know what these are... About 20' long, with computer
input (plus fork-lifts of paper) at one side and bound books being emitted
from the other. These are now accepting faxes, and results in a very
high-end MFP device. Indeed, all the hardcopy features mentioned above
would be sweet in such a submission process (despite your factual point
that these don't exist in most of the installed based of fax devices.)
Let's look at another application for true internet printing, where you are
at least getting out onto the public infrastructure. Consider a large
corporation, such as Safeway/Vons grocery stores. They have about 3000
store locations last time I checked. Let's say that they want to send a new
employee manual to each of the locations. At headquarters, the manual is
designed, and the various "hints" that are needed to completely reproduce
the booklet. (I still claim these should be designed as a MIME object, so I
will use that here). Headquarters sends each of the branches the employee
manual using SMTP and MIME. Using a distribution list of the 3000 stores is
quite handy in this case. The information sent is proposed as follows, each
in its own MIME media-type object:
content
content-descriptor
hardcopy production hints
job ticket
content:
--------
This is the same content as would be sent to a print queue for printing.
content-descriptor:
-------------------
This may be as simple as a media-type name. There are some other
meta-information that applies to the content itself which may be useful,
such as filename, creation date, author, copyright information, etc.
hardcopy production hints:
--------------------------
when the document is designed, the designer decides exactly how the
document should be produced. The various binding, paper type, and other
information I partially listed above would be applicable (see
ftp://ftp.mfpa.org/tdf_004.txt for more). These are "Hints" for the most
part since a given store location may wish to
1) view the document on screen
2) produce the document on the local printer
3) forward the submission to kinkos (gee, wouldn't be nice if the same
format was used for submission??)
4) not reproduce the document exactly as designed, but get something out
anyway.
job ticket:
-----------
These are primarily composed of the same attributes as the Production
Hints, but apply only for a single submission. Such things as #copies and
overrides to the production hints would be appropriate here.
I just don't think the ipp control paradigm makes much sense for this
application. Does Safeway headquarters really care about the state of the
queues of the various copiers in the 3000 store branches? Or worse yet, at
the specific Copy shop in the vicinity of the store?
Admittedly, Safeway may be better off hiring an offset printer to do this
work since 3000*(number of employees at each store) is large enough to be
significant. I'm sure however, that if the example is broken, we could come
up with a reasonable example that would make this point.
The problem with the IPP point of view is _scale_. It doesn't scale up to a
one-to-many situation. It is a highly-coupled protocol which is quite
appropriate for internal printing, but, I claim, worth little for the big
picture....
See ftp://ftp.mfpa.org/jobs_wp.w (Word 2.0 format) for the white paper I
mentioned on this topic.
Regards,
-Raymond
/***********************************************************************
** Raymond Lutz Voice: 619-447-3246
** Director R & D, Cognisys, Inc. Fax: 619-447-6872
** EC Chair, MFPA MFPA: 1-800-603-MFPA
** 1010 Old Chase Ave., Suite B mailto:raylutz at cognisys.com
** El Cajon (San Diego Co.), CA 92020 USA http://www.cognisys.com
** http://www.mfpa.org
***********************************************************************/