Subject: IPP> Article on IPP written by Adina Levin of CAPV

From: "Steve Zilles" <[email-masked]>
Date: Fri, 05 Sep 1997 10:56:06 PDT

FYI, here is the text of the article on IPP written by Adina Levin of
CAPV. She was gracious enough to send a copy for distribution to the
PWG/IPP mailing list.
        Steve Zilles

------- Forwarded Message
Steve, thanks for the kind words. Here's the boilerplate and the article,
for distribution to the members of the Printer Working Group.

- - ASL

This article is excerpted from the Weekly Analysis electronic mail
publication of the Document Software Strategies consulting service of CAP
Ventures. This is a regular, weekly service for our clients. If you have
questions or comments about the article, or for more information about CAP
Ventures and the Document Software Service, call Adina Levin at
617-871-9000 x 145, or e-mail at [email-masked].

- ----------------------------------------------------------------------
   Adina Levin ...
- ----------------------------------------------------------------------

                     Internet Printing Protocol:
                  The Promise of Internet Printing

Yesterday Jim Hamilton, of the Print on Demand group of CAP
Ventures, and I attended a briefing on the Internet Printing
Protocol. The result of a year's worth of negotiations among
industry powerhouses including Adobe, Hewlett-Packard, IBM,
Microsoft, Netscape, Novell, Sun, and Xerox, the draft standard
defines the method of sending a print job over the Internet.

This standard is going to be a key nexus over the next 5 years at
the intersection between document software and hardcopy output,
enabling and accelerating opportunities for document delivery and on-
demand printing software and services.

WHAT IS THE INTERNET PRINTING PROTOCOL?

In the simplest terms, the Internet printing protocol is a protocol
that enables printing over the Internet.  It combines and supersedes
early non-standard work on Internet printing by HP and Microsoft
(Simple Web Printing), Novell (LDPA), IBM (HPPP) and probably Adobe
(Web-Ready Printing).

Internet printing can work in one of three ways. 1) The user can
print as usual through the operating system, but is able to access
printers that are on Internet, not just on the local area network.
2) The user can send a print-formatted file (such as a PostScript or
PDF file) to a printer. 3) The user can send a URL, and the printer
will fetch the document and print it.

The IPP defines a list of printer capabilities, and print job
submission and feedback commands. It uses a client-server
architecture. The client, which can be a web browser or desktop
client can submit, query, or cancel a print job, and query the
status of a printer. The server can be implemented inside a network-
connected printer, or at the print-server or network-server level.
The server identifies the printer or printers with a unique URL, and
a database of each printers capabilities (color, duplex). The server
can then accept print requests from the Internet, perform simple
negotiations (I cannot print that document since I am not a color
printer), and provide feedback about status (I am processing a job,
I have a paper jam.)  The IPP uses HTTP 1.1 for the negotiation
between client and server.

The standard was developed by the Printer Working Group
(www.pwg.org), an alliance of printer, print networking, and
infrastructure software vendors. It is not formally part of the IETF
but is commissioned by the IETF to develop this standard.

WHAT IS IT GOOD FOR?

The Internet Printing Protocol adds an important  level of
infrastructure capability that makes some network printing tasks
much easier to do.  In the 8 years or so that I've been following
this market, there have been numerous ill-fated schemes for managing
printers on networks, starting with closed-system utopias from
Digital Equipment, to LAN/WAN based solutions proposed by Novell, to
international standards-based systems that tried to abstract and
define every printer feature in the universe. These early solutions
based on closed systems or international standards languished; one
reason is that in order to develop working print management
software, you needed to write low-level networking code that had
little value to the printer vendor or infrastructure vendor. In
reality, network print management solutions were based on a single
printer vendor's products or a single network environment.

With IP as a universal network, enterprise-wide printer management
becomes much easier. Printers become visible on the corporate
intranet; users and administrators can see that the printers are
working, measure usage,  and conduct software upgrades. These
capabilities will be quickly implemented by vendors of network
printers, such as Hewlett-Packard, Lexmark, and Tektronix.

But if printer management were the whole story, this article would
not be that interesting. Customers will appreciate enterprise-wide,
network-independent, printer-independent network print management
when it is available, but they will probably expect it for free.

Internet printing has some more interesting applications that will
create or facilitate profitable business opportunities that builds
on the IPP base.

1) Internet printing will be extremely useful for distributed on-
demand production printing. It will become much easier to send
printed documents to corporate branch offices in London, Tokyo, and
Singapore. This kind of distributed printing has been slow to take
off because of the work required to tie together the pieces of a
heterogeneous network.  With the Internet as a universal network,
users will be able to print to the corners of far-flung
organizations. Companies that make various types of print server
products, such as TR Systems, NEPS, EFI, and Dazel, are likely to
integrate this quickly.

Vendors and users wishing to implement distributed on-demand
printing will still need to cope with complex device negotiation
issues. IPP has built in a basic level of device specification - is
the device color or monochrome, US letter-size or A4? IPP also
includes a basic level of  negotiation - print it only the way that
I want, or print the job as best you can. The real world is much
more complicated, particularly in a production environment. IPP
alone can't specify that yellow paper goes in paper tray 3. However,
the IPP leaves the way open for vendor or user-level extensions to
the standard. Successful distributed printing may also require a
certain level of process co-ordination and discipline. Even if a
site's IPP application states that the yellow paper goes in paper
tray 3, humans must make sure that orange paper doesn't get put into
paper tray 3 by mistake.

2) The second, related example in the production printing
environment is remote job submission to for-profit printers. There
are networks of for-profit printers that have begun to do this
already, including networks of for-profit print chains: Kinkos and
Sir Speedy; networks of independent printers: PagePath, WEPN, IPN;
and networks of large, multi-location commercial printers: Uarco
Impressions, Standard Register StanFast.

These networks provide software that allows an end user to find the
printer in the desired geographical area with the desired
capabilities, to fill out the requirements of the job and payment
information, and to submit the print file. The Internet printing
protocol will not replace the services and networks that exist. The
Internet printing protocol does not include all of the features you
would need in a job ticketing system - it just includes a basic
method of identifying a printer and sending a print job. Moreover,
networks of printers will provide a variety of value-added services
and customer service capabilities that distinguish them, above and
beyond basic job ticketing. The Internet printing protocol is likely
to make remote job submission easier, and will popularize the
process of remote printing in general.

3) The previous two examples involved "push" printing. The customer
has the document in hand, and would like to print it at a location
far away. Another potentially valuable application is just-in-time
printing from a database of print files. This is "pull" printing,
and it would work in the following manner: an organization would
create a database of print files - sales collateral, or brochures,
or CAP Ventures published reports. A sales person or customer would
be able to locate the file, or the URL of the file, and send that to
a local printer.  The user would be able to order and print the
documents where and when they were needed.

4) The previous three examples dealt with production printing - the
printing of documents designed to be distributed to multiple people
in some formal way. Internet printing will also be useful in the day-
to-day business world. Ordinary users will be able to use Internet
printing to print a document to some printer someplace else.

The big challenges here are discovery and security. How can I find
one small printer  in the great wide world?  And how can I make sure
random people aren't sending me junk prints, in addition to junk
faxes and spam e-mails? The IPP standard does not specify any
particular security method. Instead, it allows infrastructure
software developers and user organizations to use the security
methods they have in place. Solving the discovery problem will
require additional development at the network infrastructure level,
using LDAP and other standards, to build software for resource
discovery. In the mean time, people will have to give out their
printer's URL deliberately, in the same way that they give out their
fax number. Another problem is print drivers. IPP can generate a
feedback message about the driver needed to print to a distant
printer. This process sounds awkward and is likely to give MIS staff
headaches.

Companies in the fax business should be afraid, since remote
printing avoids telephone charges and creates a clean, original
document rather than a fuzzy bitmapped fax. However, it will take
some time before IPP printing capability is anywhere near as common
as faxing.

5) The promise of remote printing adds hardcopy output into the
matrix of electronic document delivery solutions. After all, it will
enable users to deliver formatted electronic documents to a remote
location. Electronic document delivery can be tied into specific
horizontal or vertical applications, in extranet electronic
commerce, financial publishing, health care, and so on. Providers of
electronic delivery products and services, from Tumbleweed to
Diffusion to Adobe, are likely to add support for remote printing to
the capabilities of their products.

WHAT IT WILL TAKE TO MAKE THIS A REALITY

None of these scenarios will happen overnight. A number of steps
need to happen first, starting with finalization and adoption of the
IPP standard. The draft standard is expected to be finalized over
the next few months and submitted to IETF by the end of the year,
and approved by IETF, probably early next year.

Next, IPP capability needs to be added to infrastructure software
(Microsoft, Novell, Sun, Netscape). Depending on the decisions of
infrastructure software providers, IPP will be included as a free
add-on, or part of a next-generation revision of network software.
The infrastructure software upgrade cycle will add another six
months to several years to reach a critical mass of deployment,
depending on how aggressive the software vendors are and how popular
the feature is among users.

IPP can also be built into a network printer itself, and it probably
will be, starting as early as late `98. Many network printers, and
most printers in the production environment, are software-
upgradable, so upgrades can happen fairly quickly. It is important
to note that it won't be necessary to upgrade the installed base of
printers to take advantage of IPP. The IPP intelligence can live at
the level of the print server or network print service. This is very
important for the potential speed of proliferation. If you needed to
replace existing printers, it would take many years to make a small
dent in the installed base of existing LaserJets.

CONCLUSION

IPP won't happen overnight, and there are many problems that the
Internet printing protocol won't solve by itself. That said, we
believe that IPP will serve as a critical enabling technology that
will make many kinds of network printing applications easier to
build, will create or facilitate opportunities for network printing
and document delivery systems, and will set the stage for more rapid
adoption of useful network printing applications.

                                        -- Adina Levin

------- End of Forwarded Message