summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1528.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1528.txt')
-rw-r--r--doc/rfc/rfc1528.txt675
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc1528.txt b/doc/rfc/rfc1528.txt
new file mode 100644
index 0000000..c53e4ba
--- /dev/null
+++ b/doc/rfc/rfc1528.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group C. Malamud
+Request for Comments: 1528 Internet Multicasting Service
+Obsoletes: 1486 M. Rose
+Category: Experimental Dover Beach Consulting, Inc.
+ October 1993
+
+
+ Principles of Operation for the TPC.INT Subdomain:
+ Remote Printing -- Technical Procedures
+
+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. Please refer to the
+ current edition of the "Internet Official Protocol Standards" for the
+ standardization state and status of this protocol. Distribution of
+ this memo is unlimited.
+
+Table of Contents
+
+ 1. Introduction .......................................... 2
+ 2. Naming, Addressing, and Routing ....................... 2
+ 2.1 Addressing ........................................... 2
+ 2.2 Routing .............................................. 3
+ 3. Procedure ............................................. 3
+ 3.1 Content-Types ........................................ 4
+ 3.2 Generating a Cover-Sheet ............................. 4
+ 3.3 Return Receipt ....................................... 6
+ 4. Usage Examples ........................................ 6
+ 4.1 Explicit Cover Sheet ................................. 6
+ 4.2 Implicit Cover Sheet ................................. 7
+ 4.3 Minimal, Text-only ................................... 7
+ 5. Prototype Implementation .............................. 7
+ 6. Future Issues ......................................... 9
+ 7. Security Considerations ............................... 9
+ 8. Acknowledgements ...................................... 9
+ 9. References ............................................ 9
+ 10. Authors' Addresses .................................. 10
+ A. The application/remote-printing Content-Type ......... 11
+ B. The image/tiff Content-Type .......................... 12
+
+1. Introduction
+
+ Although electronic mail is preferable as a means of third-party
+ communication, in some cases it may be necessary to print
+ information, in hard-copy form, at a remote location. The remote
+ output device may consist of a standard line printer, a printer with
+
+
+
+Malamud & Rose [Page 1]
+
+RFC 1528 Remote Printing -- Technical Procedures October 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.
+
+2. Naming, Addressing, and Routing
+
+ A printer is identified by a telephone number which corresponds to a
+ G3-facsimile device connected to the international telephone network,
+ e.g.,
+
+ +1 415 968 2510
+
+ where "+1" indicates the IDDD country code, and the remaining string
+ is a telephone number within that country.
+
+2.1 Addressing
+
+ This number is used to construct the address of a remote printer
+ server, which forms the recipient address for the message, e.g.,
+ either
+
+ remote-printer@0.1.5.2.8.6.9.5.1.4.1.tpc.int
+
+ or
+
+ remote-printer.ATOM@0.1.5.2.8.6.9.5.1.4.1.tpc.int
+
+ where "ATOM" is an (optional) RFC 822 atom [1], an opaque string for
+ use in recipient identification when generating a cover-sheet, and
+ the domain-part is constructed by reversing the telephone number,
+ converting each digit to a domain-label, and being placed under
+ "tpc.int."
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Malamud & Rose [Page 2]
+
+RFC 1528 Remote Printing -- Technical Procedures October 1993
+
+
+ Note that the mailbox syntax is purposefully restricted in the
+ interests of pragmatism. 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)>
+ / "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+"
+ / "-" / "/" / "=" / "?" / "^" / "_" / "`" / "{"
+ / "|" / "}" / "~"
+
+ Finally, note that some Internet mail software (especially gateways
+ from outside the Internet) impose stringent limitations on the size
+ of a mailbox-string. Thus, originating user agents should take care
+ in limiting the local-part to no more than 70 or so characters.
+
+2.2 Routing
+
+ The message is routed in exactly the same fashion as all other
+ electronic mail, i.e., using the MX algorithm [2]. Since a remote
+ printer server might be able to access many printers, the wildcarding
+ facilities of the DNS [3,4] 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.
+
+ Naturally, if several remote printer servers were willing to access
+ any printer in that prefix, multiple MX resource records would be
+ present.
+
+ It should be noted that the presence of a wildcard RR which matches a
+ remote printer server's address does not imply that the corresponding
+ telephone number is valid, or, if valid, that a G3-facsimile device
+ is connected at the phone number.
+
+3. Procedure
+
+ When information is to be remotely printed, the user application
+ constructs an RFC 822 message, containing a "Message-ID" field.
+
+
+
+
+
+Malamud & Rose [Page 3]
+
+RFC 1528 Remote Printing -- Technical Procedures October 1993
+
+
+ If the local-part of the address does not contain an opaque string
+ for use in recipient identification, then the body must consist
+ "multipart/mixed" content [5] having at two parts, the first being a
+ "application/remote-printing" content-type (defined in Appendix A),
+ which will be used to generate a cover-sheet, and the second being an
+ arbitrary content-type corresponding to the information to be
+ printed. If the local-part of the address does contain an opaque
+ string for use in recipient identification, then the body consists of
+ an arbitrary content-type corresponding to the information to be
+ printed.
+
+ Regardless, the message is then sent to the remote printer server's
+ electronic mail address.
+
+3.1 Content-Types
+
+ 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 B), 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.
+
+ (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. Naturally, when processing a "multipart/alternative"
+ content, only one subordinate content will be printed.
+
+3.2 Generating a Cover-Sheet
+
+ If the "application/remote-printing" content-type is present,
+ this contains all the information necessary to generate a
+
+
+
+Malamud & Rose [Page 4]
+
+RFC 1528 Remote Printing -- Technical Procedures October 1993
+
+
+ cover-sheet. Otherwise, the cover-sheet must be generated
+ based on other information available.
+
+ Typically, a cover sheet consists of three sections:
+
+ o information identifying the originator;
+
+ o information identifying the recipient; and,
+
+ o additional information supplied by the remote printer
+ server.
+
+ To identify the originator, the remote printer server will use the
+ message headers, usually by stripping any trace headers (i.e.,
+ "Received" and "Return-Path") and then re-ordering the remaining
+ headers starting with the "From" header.
+
+ To identify the recipient, the opaque string from the local- part of
+ the remote printer server's address is consulted. For example, if
+ the remote printer server's address is
+
+ remote-printer.Arlington_Hewes/Room_403@0.1.5.2.8.6.9.5.1.4.1.tpc.int
+
+ then the opaque string
+
+ Arlington_Hewes/Room_403
+
+ is consulted. lp When generating a cover-sheet using this opaque
+ string, the remote printer server will interpret an underscore
+ character ("_") as a space, and a solidus character ("/") as an end-
+ of-line sequence. A remote printer server will interpret two
+ consecutive underscore characters in the opaque string as a single
+ underscore, and two consecutive solidus characters as a single
+ solidus. So, the opaque string,
+
+ Arlington_Hewes/Room_403
+
+ might appear on the cover-sheet as
+
+ To: Arlington Hewes
+ Room 403
+
+
+
+
+
+
+
+
+
+
+Malamud & Rose [Page 5]
+
+RFC 1528 Remote Printing -- Technical Procedures October 1993
+
+
+3.3 Return Receipt
+
+ When the remote printer server finishes its processing, a message is
+ returned to the originator, indicating either success (i.e., the
+ message was successfully sent to the facsimile device), or failure,
+ with an explanation (e.g., after several repeated attempts, there was
+ no answer).
+
+4. Usage Examples
+
+4.1 Explicit Cover Sheet
+
+ To: remote-printer@0.1.5.2.8.6.9.5.1.4.1.tpc.int
+ From: Carl Malamud <carl@malamud.com>
+ Date: Thu, 22 Jul 1993 08:38:00 -0800
+ Subject: First example
+ Message-ID: <19930722163800.1@malamud.com>
+ MIME-Version: 1.0
+ Content-Type: multipart/mixed;
+ boundary="----- =_aaaaaaaaaa0"
+
+ ------- =_aaaaaaaaaa0
+ Content-Type: application/remote-printing
+
+ Recipient: Arlington Hewes
+ Telephone: +1 415 968 1052
+ Facsimile: +1 415 968 2510
+
+ Originator: Carl Malamud
+ Organization: Internet Multicasting Service
+ Address: Suite 1155, The National Press Building
+ Washington, DC 20045
+ US
+ Telephone: +1 202 628 2044
+ Facsimile: +1 202 628 2042
+ EMail: carl@malamud.com
+
+ Any text appearing here would go on the cover-sheet.
+
+ ------- =_aaaaaaaaaa0
+ Content-Type: text/plain; charset="us-ascii"
+
+ Here are my comments...
+
+ ------- =_aaaaaaaaaa0--
+
+
+
+
+
+
+Malamud & Rose [Page 6]
+
+RFC 1528 Remote Printing -- Technical Procedures October 1993
+
+
+4.2 Implicit Cover Sheet
+
+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: Thu, 22 Jul 1993 08:38:00 -0800
+Subject: Second example
+Message-ID: <19930722163800.2@malamud.com>
+MIME-Version: 1.0
+Content-Type: application/postscript
+
+%!
+
+Note that in this latter example, both remote printing and e-mail
+recipients can be identified in the same message.
+
+4.3 Minimal, Text-only
+
+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: Thu, 22 Jul 1993 08:38:00 -0800
+Subject: Third example
+Message-ID: <19930722163800.3@malamud.com>
+
+ Here are my comments...
+
+5. Prototype Implementation
+
+ A prototype implementation is openly available. The MIME
+ instructions for retrieval are:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Malamud & Rose [Page 7]
+
+RFC 1528 Remote Printing -- Technical Procedures October 1993
+
+
+ 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 contains software for UNIX-based systems, and was
+ developed and tested under SunOS, with an openly-available facsimile
+ package (Sam Leffler's FlexFAX package), and contains information for
+ sites acting as either client or server participants, and zone
+ administrators.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Malamud & Rose [Page 8]
+
+RFC 1528 Remote Printing -- Technical Procedures October 1993
+
+
+6. Future Issues
+
+ Note that several issues are not addressed, e.g.,
+
+ o determining which content-types and character sets are
+ supported by a remote printer server;
+
+ o introduction of authentication, integrity, privacy,
+ authorization, and accounting services;
+
+ o preferential selection of a remote printer server; and,
+
+ o aggregation of multiple print recipients in a single
+ message.
+
+ Subsequent work might consider these issues in detail.
+
+7. Security Considerations
+
+ Internet mail may be subject to monitoring by third parties, and in
+ particular, message relays.
+
+8. Acknowledgements
+
+ This document is based on RFC 1486, "An Experiment in Remote
+ Printing".
+
+9. References
+
+ [1] Crocker, D., "Standard for the Format of ARPA Internet Text
+ Messages", STD 11, RFC 822, UDEL, August 1982.
+
+ [2] Partridge, C., "Mail Routing and the Domain System" STD 14, RFC
+ 974, CSNET CIC BBN, January 1986.
+
+ [3] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
+ 13, RFC 1034, USC/Information Sciences Institute, November 1987).
+
+ [4] Mockapetris, P., "Domain Names -- Implementation and
+ Specification", STD 13, RFC 1035, USC/Information Sciences
+ Institute, November 1987.
+
+ [5] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail
+ Extensions) Part One: Mechanisms for Specifying and Describing
+ the Format of Internet Message Bodies", RFC 1521, Bellcore,
+ Innosoft, September 1993.
+
+
+
+
+
+Malamud & Rose [Page 9]
+
+RFC 1528 Remote Printing -- Technical Procedures October 1993
+
+
+10. Authors' Addresses
+
+ 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
+
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Malamud & Rose [Page 10]
+
+RFC 1528 Remote Printing -- Technical Procedures October 1993
+
+
+Appendix A. 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
+
+ (7) Specification:
+
+ The "application/remote-printing" content-type contains originator
+ and recipient information 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.
+
+
+
+
+
+
+
+Malamud & Rose [Page 11]
+
+RFC 1528 Remote Printing -- Technical Procedures October 1993
+
+
+Appendix B. The image/tiff Content-Type
+
+ (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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Malamud & Rose [Page 12]
+ \ No newline at end of file