RFC 1486 (rfc1486) - Page 2 of 14

An Experiment in Remote Printing

RFC 1486           An Experiment in Remote Printing            July 1993


   multiple fonts and faces, a printer that can reproduce graphics, or a
   facsimile device.  Remote output may be accompanied by information
   that identifies the intended recipient.  This memo describes a
   technique for "remote printing" using the Internet mail
   infrastructure.  In particular, this memo focuses on the case in
   which remote printers are connected to the international telephone
   network.  Furthermore, it describes an experiment in remote printing.

1.1.  The Advantage of a General-Purpose Infrastructure

   The experiment in remote printing is about "outreach"; specifically,
   integrating the e-mail and facsimile communities.  By providing easy
   access to remote printing recipients, enterprise-wide access is
   enhanced, regardless of kind of institution (e.g., commercial,
   educational, or government), or the size of institution (e.g.,
   global, regional, or local).  This approach at outreach allows an
   organization to make it easier for the "outside world" to communicate
   with the personnel in the organization who are users of facsimile but
   not e-mail; e.g., the sales person, the university registrar, or the
   (elected) official.  The ease in which the Internet mail
   infrastructure can be used to provide this facility is (yet) another
   example of the power of a general-purpose infrastructure.

2.  Procedure

   When information is to be remotely printed, the user application
   constructs an RFC 822 [1] message, containing a "Message-ID" field
   along with a "multipart/mixed" content [2] having two parts, the
   first being a "application/remote-printing" content-type, and the
   second being an arbitrary content-type corresponding to the
   information to be printed.  The message is then sent to the remote
   printer server's electronic mail address.

   It should be noted that not all content-types have a natural printing
   representation, e.g., an "audio" or "video" content.  For this
   reason, the second part of the "multipart/mixed" content should be
   one of the following:

      text/plain, message/rfc822, application/postscript image/tiff
      (defined in Appendix A), any multipart

   Note that:

   (1)  With the "text/plain" content-type, not all character sets may
        be available for printing.

   (2)  With the "message" content-type, the subordinate content will be
        processed recursively.



Rose & Malamud