RFC 1486

RFC 1486: An Experiment in Remote Printing 🖨️💖

Okay bestie, this header is giving 1993 archive energy and I am obsessed 😭 Here's the title block tea:

• Title: An Experiment in Remote Printing
• Authors: M. Rose (Dover Beach Consulting, Inc.) and C. Malamud (Internet Multicasting Service) 👯
• Working group: Network Working Group
• Status: Experimental Protocol (the Status of this Memo section spells it out) 🧪
• Date: July 1993 📅
• Obsoletes / Updates: the header doesn't list anything this one obsoletes or updates, so it's not stepping on anybody's toes 💅

Status of this Memo 📜

This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard. Discussion and suggestions for improvement are requested, so bring your thoughts 💭 For the standardization state and status of this protocol, check the current edition of the "IAB Official Protocol Standards." And distribution of this memo is unlimited 🦋

Table of Contents 🧚

1. Introduction ..........................................    1
   1.1 The Advantage of a General-Purpose Infrastructure.....    2
2. Procedure .............................................    2
   2.1 Naming, Addressing, and Routing ......................    3
   2.2 The application/remote-printing Content-Type .........    4
   2.3 Usage Example ........................................    5
   2.4 Remote Printing without MIME .........................    6
3. The Experiment ........................................    7
   3.1 Infrastructure .......................................    8
   3.1.1 Zones ..............................................    8
   3.1.2 MX records .........................................    8
   3.2 Accounting and Privacy ...............................    9
   3.3 Mailing list .........................................    9
   3.4 Prototype Implementation .............................   10
4. Future Issues .........................................   11
5. Security Considerations ...............................   11
6. Acknowledgements ......................................   11
7. References ............................................   11
8. Authors' Addresses.....................................   12
A.  The image/tiff Content-Type ..........................   13
B.  Uniform Addressing ...................................   13

1. Introduction ✨

Email is honestly the preferred option for third-party communication 💌, but sometimes you might need to print info in hard-copy form at a remote location 📄 The remote output device could be a standard line printer, a printer with multiple fonts and faces, a printer that can reproduce graphics, or a facsimile device 📠 Remote output may also come with info that identifies the intended recipient.

This memo describes a technique for "remote printing" using the Internet mail infrastructure 🌐 It focuses on the case where remote printers are connected to the international telephone network. And on top of that, it describes an experiment in remote printing 🧪

1.1. The Advantage of a General-Purpose Infrastructure 💜

The remote printing experiment is all about "outreach," which basically means integrating the e-mail and facsimile communities 🤝 Easy access for remote printing recipients boosts enterprise-wide access, no matter what kind of institution you are (commercial, educational, or government) or how big you are (global, regional, or local).

This outreach approach lets an organization make it easier for the "outside world" to talk to the people inside who use facsimile but not e-mail. Think the sales person, the university registrar, or the (elected) official 🏛️ How easy it is to use the Internet mail infrastructure for this is (yet) another example of the power of a general-purpose infrastructure ⚡

2. Procedure 🎀

When information needs to be printed remotely, the user application builds an RFC 822 [1] message. That message has a "Message-ID" field and "multipart/mixed" content [2] with two parts 💌 Part one is an "application/remote-printing" content-type, and part two is an arbitrary content-type that matches the information being printed. The message then gets sent to the remote printer server's electronic mail address ✉️

Heads up: not every content-type has a natural printing representation, like "audio" or "video" 🔊🚫 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

A few things to note 👀

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.
3. With the "application/postscript" content-type, the remote printer server should evaluate the contents in a safe execution environment.
4. With the "multipart" content-type, the subordinate contents will be processed recursively. For a "multipart/mixed" or "multipart/digest" content, each subordinate content will start on a new page, whilst for a "multipart/parallel" content, all subordinate contents will, if possible, start on the same page. And obviously, when processing a "multipart/alternative" content, only one subordinate content will be printed 🔁

When the remote printer server finishes its processing, a message is returned to the originator saying either success or failure 🎉

2.1. Naming, Addressing, and Routing 🗺️

A printer is identified by a telephone number that corresponds to a G3-facsimile device connected to the international telephone network, e.g.,

+1 415 968 2510

Here "+1" indicates the IDDD country code, and the remaining string is a telephone number within that country 🌍 This number is used to build the address of a remote printer server, which forms the recipient address for the message, e.g.,

remote-printer@0.1.5.2.8.6.9.5.1.4.1.tpc.int

So the local-part of the remote printer server's address is ALWAYS "remote-printer" (no exceptions, bestie 🙅). The domain-part is built by reversing the telephone number, converting each digit to a domain-label, and placing everything under "tpc.int." 🔁

The message gets routed in exactly the same fashion as all other electronic mail, i.e., using the MX algorithm [3]. Since a remote printer server might be able to access many printers, the wildcarding facilities of the DNS [4,5] are used accordingly 🃏 For example, if a remote printer server residing at "dbc.mtview.ca.us" was willing to access any printer with a telephone number prefix of

+1 415 968

then this resource record might be present:

*.8.6.9.5.1.4.1.tpc.int.    IN MX 10 dbc.mtview.ca.us.

And if several remote printer servers were willing to access any printer in that prefix, multiple MX resource records would be present 🧩

Heads up though: the presence of a wildcard RR that matches a remote printer server's address does not imply that the corresponding telephone number is valid. And even if it is valid, it doesn't mean a G3-facsimile device is connected at that phone number 📞🚫

2.2. The application/remote-printing Content-Type 💅

1. MIME type name: application
2. MIME subtype name: remote-printing
3. Required parameters: none
4. Optional parameters: none
5. Encoding considerations: 7bit preferred
6. Security considerations: none

The "application/remote-printing" content-type holds the originator and recipient info used when generating a cover sheet ✨ Using the ABNF notation of RFC 822, the syntax for this content is:

<content>         ::=  <recipient-info> CRLF
                       <originator-info>
                       [CRLF <cover-info>]

<recipient-info>  ::=   "Recipient"    ":" <value> CRLF
                       <address-info>
<originator-info> ::=   "Originator"   ":" <value> CRLF
                       <address-info>

<address-info>    ::=  ["Title"        ":" <value> CRLF]
                       ["Department"   ":" <value> CRLF]
                       ["Organization" ":" <value> CRLF]
                       ["Mailstop"     ":" <value> CRLF]
                       ["Address"      ":" <value> CRLF]
                       ["Telephone"    ":" <value> CRLF]
                        "Facsimile"    ":" <value> CRLF
                       ["Email"        ":" <value> CRLF]
<value>           ::=  *text
                       [CRLF LWSP-char     <value>     ]

<cover-info>      ::= *(*text CRLF)

Note that the value of the "Email" field is an RFC 822 mailbox address 💖

2.3. Usage Example 💌

Suppose someone wanted to send the author some comments on this memo using this facility 🫶 The message might look something like this:

To: remote-printer@0.1.5.2.8.6.9.5.1.4.1.tpc.int
From: "John Q. Public" <jpublic@tpd.org>
Date: Sun, 11 Apr 1993 20:34:13 -0800
Subject: Comments on "An Experiment in Remote Printing"
Message-ID: <19930411203413000.456@tpd.org>
MIME-Version: 1.0
Content-Type: multipart/mixed;
        boundary="----- =_aaaaaaaaaa0"

------- =_aaaaaaaaaa0
Content-Type: application/remote-printing

Recipient:    Marshall Rose
Title:        Principal
Organization: Dover Beach Consulting, Inc.
Address:      420 Whisman Court
              Mountain View, CA  94043-2186
              US
Telephone:    +1 415 968 1052
Facsimile:    +1 415 968 2510

Originator:   John Q. Public
Organization: The Public Domain
Telephone:    +1 801 555 1234
Facsimile:    +1 801 555 6789
EMail:        "John Q. Public" <jpublic@tpd.org>

Any text appearing here would go on the cover-sheet.

------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"

Here are my comments on your draft.

 ...

------- =_aaaaaaaaaa0--

2.4. Remote Printing without MIME 🎀

Okay so what if the sender's mail program doesn't do MIME? 🥺 Like, if they're getting onto Internet mail through a gateway in another mail dominion, remote printing can still happen, just in a more limited way 💅. Since there's no application/remote-printing content, the cover sheet info has to come from some other source, and the message body gets treated as text/plain 📝.

Typically a cover sheet has three sections:

• information identifying the originator;
• information identifying the recipient; and,
• additional information supplied by the remote printer server.

To figure out the originator, the remote printer server looks at the message headers. It strips the trace headers (aka Received and Return-Path) and then reorders the rest, starting with From 🧾.

For the recipient, there's an alternative addressing syntax. The local-part of the remote printer server's address is remote-printer followed by an RFC 822 atom, like this:

remote-printer.Arlington_Hewes/Room_403@0.1.5.2.8.6.9.5.1.4.1.tpc.int

This mailbox syntax is intentionally restricted, because pragmatism is everything 🫶.

The atom after remote-printer is treated as an opaque string when the server makes the cover sheet, so it's basically just used for recipient identification 🔍.

To paraphrase RFC 822, an atom is defined as:

atom    = 1*atomchar

atomchar=   <any upper or lowercase alphabetic character (A-Z a-z)>
          / <any digit (0-9)>
          / "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+"
          / "-" / "/" / "=" / "?" / "^" / "_" / "`" / "{"
          / "|" / "}" / "~"

When the remote printer server builds a cover sheet from that opaque string, an underscore (_) turns into a space, and a solidus (/) turns into an end-of-line sequence ✨. Two underscores in a row become one underscore, and two solidus characters in a row become one solidus. So the opaque string

Arlington_Hewes/Room_403

from the example above might show up on the cover sheet like this:

To: Arlington Hewes
    Room 403

Heads up 🚨: some Internet mail software (especially gateways from outside the Internet) is super strict about how big a mailbox-string can be. So originating user agents should take care in limiting the local-part to no more than 70 or so characters 🙈.

Also, using the alternative addressing syntax means it's totally legal to send non-textual messages where the cover sheet info gets derived automatically 🤯. You just include MIME-Version: and Content-Type: headers in the message, but leave out the initial application/remote-printing content. Here's an example:

To: remote-printer.Arlington_Hewes/Room_403@0.1.5.2.8.6.9.5.1.4.1.tpc.int
cc: Marshall Rose <mrose@dbc.mtview.ca.us>
From: Carl Malamud <carl@malamud.com>
Date: Sun, 18 Jul 1993 09:14:13 -0500
Subject: proposal for enhancement
Message-ID: <19930718141413000.123@malamud.com>
MIME-Version: 1.0
Content-Type: application/postcript

%!

And because of that alternative addressing syntax, remote printing and e-mail recipients can be identified in the same message 💌✨.

---

3. The Experiment 🧪

To get some real-world experience with this style of remote printing, there's an experiment going on right now 👀.

3.1. Infrastructure 🏗️

The domain tpc.int. is being populated to provide the MX-based infrastructure for routing to a remote printer server 🗺️. To keep things distributed, the domain is split into a zone for each IDDD country code. Sites taking part in the experiment contact the right zone administrator to get listed, and they find that person by checking the SOA resource record for the zone. For example, a site in the Netherlands (IDDD country code 31) would contact the zone administrator for 1.3.tpc.int. to get listed, and they could look it up with:

% dig 1.3.tpc.int. soa

Each zone administrator has their own simple procedure for listing a participant 📋. For example, in the US (IDDD country code 1), participating sites send an "exchange file" to the administrator. That file lists the prefixes the site wants listed. The zone administrator for 1.tpc.int. merges the exchange files from every participating site to create a zone for each area code. Those zones then get replicated using the normal DNS zone transfer procedures 🔁.

3.1.1. Zones 🍓

Zones under tpc.int are created based on IDDD country codes and area codes, not for each subdomain 🌍. For example, in the US and Canada (IDDD country code 1), no more than one zone is allocated for each area code. But for countries with a smaller numbering plan, only a single zone for the whole country would be allocated. For instance, if Fiji (IDDD country code 679) joined the experiment, it's likely that a single zone would be added to the DNS, i.e., 9.7.6.tpc.int. 🏝️.

3.1.2. MX records 📬

The MX records in a zone can have an arbitrary level of precision 🎯. For example, the North American Numbering Plan (IDDD country code 1) is structured as a 3-digit area code, followed by a 3-digit exchange prefix, followed by a 4-digit station number. So you might expect the MX records in this zone to look something like this:

*.5.1.4.1.tpc.int.          IN MX 10 dbc.mtview.ca.us.

That one gets you access to any printer with a telephone number prefix of

+1 415

(i.e., access to any printer in area code 415). Or it might look more like this:

*.8.6.9.5.1.4.1.tpc.int.    IN MX 10 dbc.mtview.ca.us.

(i.e., access to any printer in area code 415, exchange prefix 968).

But the level of precision is totally up to you 🤷‍♀️. For example, if all the printers in an organization had a telephone number prefix of

+1 415 96

then an MX record like this one could be used:

*.6.9.5.1.4.1.tpc.int.    IN MX 10 dbc.mtview.ca.us.

3.2. Accounting and Privacy 🔒

There's no accounting or settlement in the experiment 💸. However, participating sites may implement access control to prevent abuse 🛡️. Records may be kept for auditing purposes, but the privacy of a participant's printing should be honored 🫣. So any auditing should contain at most this information:

• the date the message was received;
• the "From" and "Message-ID" fields;
• the size of the body;
• the identity (telephone number) of the printer;
• any telephony-related information, such as call duration; and,
• any G3-related information, such recipient ID.

3.3. Mailing list 📨

There's a mailing list for the experiment. If you're interested, send a note to:

tpc-rp-request@aarnet.edu.au

and ask to subscribe to the

tpc-rp@aarnet.edu.au

list 💜.

3.4. Prototype Implementation 🛠️

A prototype implementation is openly available 🎉. The MIME instructions for retrieving it are:

MIME-Version: 1.0
Content-Type: multipart/alternative;
        boundary="----- =_aaaaaaaaaa0"
Content-Description:  pointers to ftp and e-mail access

------- =_aaaaaaaaaa0
Content-Type: message/external-body;
        access-type="mail-server";
        server="archive-server@ftp.ics.uci.edu"

Content-Type: application/octet-stream; type="tar";
        x-conversions="x-compress"
Content-ID: <4599.735726126.1@dbc.mtview.ca.us>

mimesend mrose/tpc/rp.tar.Z

------- =_aaaaaaaaaa0
Content-Type: message/external-body;
        access-type="anon-ftp"; name="rp.tar.Z";
        directory="mrose/tpc"; site="ftp.ics.uci.edu"

Content-Type: application/octet-stream; type="tar";
        x-conversions="x-compress"
Content-ID: <4599.735726126.2@dbc.mtview.ca.us>

------- =_aaaaaaaaaa0--

This package has software for UNIX-based systems. It was developed and tested under SunOS, with an openly-available facsimile package (Sam Leffler's FlexFAX package) 📠. It includes info for sites acting as either client or server participants, and for zone administrators 🧑‍💻✨.

---

4. Future Issues 🔮

The experiment in remote printing described here doesn't address several issues, e.g.,

• determining which content-types and character sets are supported by a remote printer server;
• introduction of authentication, integrity, privacy, authorization, and accounting services;
• preferential selection of a remote printer server; and,
• aggregation of multiple print recipients in a single message.

Initially, the experiment won't address these issues 🙅‍♀️. However, subsequent work might consider them in detail 🧠.

5. Security Considerations 🚨

Internet mail may be subject to monitoring by third parties, and in particular, message relays. Seriously, bestie, this is the part to take to heart 😭🔐. Anyone in the path of the mail could potentially be watching it go by.

6. Acknowledgements 🫶

Carl Malamud of the Internet Multicasting Service provided substantive comments on the design of the experiment 👏. Douglas Comer of Purdue, Daniel Karrenberg of RIPE, Sam Leffler of SGI, and Paul Mockapetris of ARPA also provided comments 🌸.

7. References 📚

[1] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August, 1982.

[2] Borenstein, N., and N. Freed, "MIME: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1341, Bellcore, Innosoft, June 1992.

[3] Partridge, C., "Mail Routing and the Domain System", RFC 974, CSNET CIC BBN, August 1982.

[4] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD 13, RFC 1034, USC/Information Sciences Institute, November 1987.

[5] Mockapetris, P., "Domain Names -- Implementation and Specification", STD 13, RFC 1035, USC/Information Sciences Institute, November 1987.

8. Authors' Addresses 💖

Marshall T. Rose
Dover Beach Consulting, Inc.
420 Whisman Court
Mountain View, CA  94043-2186
US

Phone: +1 415 968 1052
Fax:   +1 415 968 2510
EMail: mrose@dbc.mtview.ca.us


Carl Malamud
Internet Multicasting Service
Suite 1155, The National Press Building
Washington, DC 20045
US

Phone: +1 202 628-2044
Fax:   +1 202 628 2042
EMail: carl@malamud.com

Appendix A. The image/tiff Content-Type 🦋

Here's the registration template for image/tiff 🌈:

(1)  MIME type name: image

(2)  MIME subtype name: tiff

(3)  Required parameters: none

(4)  Optional parameters: none

(5)  Encoding considerations: base64

(6)  Security considerations: none

(7)  Published specification: TIFF class F, as defined in:

   Tag Image File Format (TIFF) revision 6.0

     Developer's Desk Aldus Corporation 411 First Ave. South Suite
     200 Seattle, WA  98104 206-622-5500

Appendix B. Uniform Addressing 🎀

okay so a user can totally cram a bunch of recipients into one message 💌, and some of them might be remote printing recipients 🖨️✨. but here's the tea 🫖: the message format a remote printer server accepts only holds one recipient. 💀

there are three ways to solve this, and ngl the third one is iconic 👑

1. the smart user agent move 🧠: while the user is composing, a "smart" user agent can spot that one or more remote printing recipients are in the mix and then submit the right messages. the downside is that the submission for the email recipients has zero info about the remote-printing recipients 🙃
2. the alternative syntax 🎭: use the alternative recipient addressing syntax from Section 2.4. however, this minimizes the useful info available when building the cover sheet, so it's giving "not it" 😬
3. the exploder era 🧚: a site acting as a client offers its users a remote printing recipient exploder server. each remote printing recipient gets a mailbox relative to the exploder, so it looks like an "ordinary" email address 💅 the user agent has no clue which recipients are email and which are remote printing. the user just lists a bunch of mailbox recipients, and the ones reachable by remote printing get automatically routed to the exploder 💖 then, for each recipient in the envelope, a local database is checked for that recipient's addressing info, and a message is submitted to the appropriate remote printer server 🌈

---

here's an example. say the original message submitted was:

        To: mrose@rpexplode.tpd.org
        cc: Arlington Hewes <tpcadmin@dbc.mtview.ca.us>
        From: "John Q. Public" <jpublic@tpd.org>
        Date: Sun, 11 Apr 1993 20:34:12 -0800
        Subject: Comments on "An Experiment in Remote Printing"
        Message-ID: <19930411203412000.123@tpd.org>
        MIME-Version: 1.0
        Content-Type: text/plain; charset=us-ascii

        Here are my comments on your draft.
         ...

so the first recipient, mrose@rpexplode.tpd.org, gets routed to a remote printing exploder 🖨️➡️🧚, which then submits the message shown in the example in Section 2.3. meanwhile the second recipient, tpcadmin@dbc.mtview.ca.us, receives the message shown above 📬 and here's the juicy bit 🍓: a reply from this recipient could include the remote printing recipient, so the whole thread stays connected 🫶✨