here follows the revised PWG Charter text, rewritten by Scott Isaacson from
Novell in a form that is more understandandable to anybody who was not
present in the New Orleans PWG meeting. We will keep on polishing the text
in our weekly phone conferences until everybody is happy. I am cross posting
this also to the IETF Fax group to clear up any possible misunderstandings
caused by our previous, rather unfinished, version.
PWG Charter 4.0
Internet Printing Project (ipp)
Carl-Uno Manros <manros at cp10.es.xerox.com>
Applications Area Director(s):
Keith Moore <moore at cs.utk.edu>
Harald Alvestrand <Harald.T.Alvestrand at uninett.no>
General Discussion: ipp at pwg.org
To Subscribe: majordomo at pwg.org
in body: subscribe ipp
Scott Isaacson <scott_isaacson at novell.com>
Description of Working Group:
Internet printing involves using Internet technologies and services
to find networked resources such as printers and share documents and
then printing using those resources. This working group will define
a new application level distributed printing protocol as well as
naming and service registration mechanisms. The protocol can be used
in a global, distributed environment where print service users
(clients, applications, drivers, etc.) cooperate and interact with
print service providers (servers, printers, gateways, etc.). Guiding
principles for the working group include:
- platform independence,
- leverage existing technology,
- support all types of output devices (not just printers),
- keep it simple enough to embed in network attached printers,
- hide printing complexity and implementation details, and
- support all existing page description languages (including HTML).
There are several roles in which humans act with respect to a given
printer. These roles include: User, Operator, and Administrator.
For example, Users submit jobs and then manage their own jobs.
Operators monitor printer status and control and manage all jobs at
the printer. Administrators create the printer instances and control
the authorization of other Users and Operators. The working group
will generally limit its scope to include only User functionality,
however, there may be a need to define some basic Operator
functionality as well.
Users want to find and locate printers to which they are authorized
to print. They want to search for printers using a standard Web
browser. They search for printers based on name, geographic
location, and other device related capabilities and attributes.
Users also need a way to limit the scope or context of their
searches. This includes support for searching for print devices both
inside and outside their organizational fire walls.
NOTE: Throughout this document, the term browser specifically means
an Internet Web Browser (HTML, HTTP, Netscape, Internet Explorer,
Mosaic, etc.). The term does not include MIB browsers or other
browsers specific to a proprietary product or technology.
Once users find printers, they want to be able to 'install' the
printer into the native, desktop operating system on which they are
running. This installation process includes installing any device
specific components that are needed (e.g., the correct printer
driver). This allows printing from any application (e.g.,
spreadsheet, word processor, browser, etc.). Users also want to
print by reference. This means that instead of submitting a print
job that contains the entire document contents, a job can be
submitted that contains only a reference to some existing document or
set of documents. This reference is resolved prior to actually
printing the document(s).
Users want to set certain print job parameters at the time the job is
submitted (e.g., number of copies, priority, job defaults, etc.).
The underlying protocol must support job-to-printer capability
matching. This involves knowing both printer attributes and job
attributes as well as having the ability to reason about
relationships between the values of these attributes. This is useful
for rejecting print jobs that can not be printed (at submission time
rather than at print time) as well as automatically locating a
printer that is capable of printing a certain job. Once a print job
has been submitted and is being processed, users need to be able to
cancel their own print jobs.
Users want to verify both the characteristics and status of both jobs
and print devices by using a browser. When checking the status of a
device, users want to know how many jobs are being processed by the
device as well as how many jobs are 'in front of' a given job. Users
also want to be able either to turn on or turn off job and device
status reporting. The working group will define a set of printing
related events and also specify the notification methods that can be
The working group shall leverage existing (and emerging) technologies
for: authentication, authorization, privacy, and commercial
The working group must define solutions that do not preclude the
notion of multi-tiered configurations consisting of both logical and
physical printers. Also, the new job submission protocol must not
preclude submitting jobs to any type of output device (e.g., fax,
printer, gateway). Also, the working group shall define
extensibility paths so that similar extensions will interoperate and
proprietary, dissimilar extensions will never conflict. The working
group will not undertake defining a standard API set for Internet
printing, but will support redirection from current print subsystems
and interfaces as well as support direct programmatic implementations
by vertical applications.
The working group shall encourage and solicit the input and
participation from all printing related individuals and companies.
For example, the working group will not only encourage participation
by experts from printer vendors, but representatives from browsers,
client desktop operating systems, network operating systems, Internet
service providers, Page Description Languages (PDLs), and commercial
service bureaus. Also, the working group shall coordinate its
activities with other printing-related standards bodies.
The working group will not re-invent nor concern itself with the
- how operating systems 'temporarily' install printers
- command line tools and interfaces
- input devices such as scanners and fax-in
- nested HTML documents
This working group may define work that will replace RFC 1179 'Line
Printer Daemon Protocol' LPR/LPD was designed a long time ago with
line printers in mind. It does not fit with current page oriented
printing technologies. Most printer vendors have made their own
proprietary extensions which are mutually incompatible. The
specifications out of this working group must enhance RFC 1179 in the
- Useful yet practical mechanisms for interoperability and
- Support for the more complex, multiple content, multiple document,
page oriented languages and printers of today
- Support for the new Internet and Web technologies of today
This effort will be developed and prototyped within a 6 month period
since there has been considerable prior work done in this area. This
prior body of work includes:
- ISO/IEC 10175 Document Printing Application (DPA) parts 1 and 3.
- POSIX System Administration - Part 4 (POSIX 1378.4)
- X/Open, 'A Printing System Interoperability Specification(PSIS)'
- RFC 1759, Printer MIB
Goals and Milestones:
Weekly teleconference - Wednesdays, starting November 13, 1997
Mailing list - up and working
November 22, 1996 - issue Internet-Draft document to IETF
December 12, 1996 - attend BOF in IETF meeting in San Jose
End December, 1996 or earlier - have IETF WG created
April 1997 meeting of IETF - final polishing of specification
April 1997 meeting of IETF - demo of prototype(s)
May 1997 - First RFC(s) ready for publishing
(further milestones between January - April 1997 to be added)
No Current Internet-Drafts.
Request For Comments:
RFC Stat Published Title
------- -- ---------- -----------------------------------------
RFC1759 PS Mar 95 Printer MIB
701 S. Aviation Blvd.
El Segundo, CA 90245, USA
E-mail: manros at cp10.es.xerox.com