rfc1486.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 787 行 · 第 1/2 页
TXT
787 行
Network Working Group M. Rose
Request for Comments: 1486 Dover Beach Consulting, Inc.
C. Malamud
Internet Multicasting Service
July 1993
An Experiment in Remote Printing
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 "IAB Official Protocol Standards" for the
standardization state and status of this protocol. 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
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
Rose & Malamud [Page 1]
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 [Page 2]
RFC 1486 An Experiment in Remote Printing July 1993
(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.
When the remote printer server finishes its processing, a message is
returned to the originator, indicating either success or failure.
2.1. 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. This number is used to
construct 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
That is, the local-part of the remote printer server's address is
ALWAYS "remote-printer", and the domain-part is constructed by
reversing the telephone number, converting each digit to a domain-
label, and being placed under "tpc.int."
The message is 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.
Rose & Malamud [Page 3]
RFC 1486 An Experiment in Remote Printing July 1993
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.
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 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)
Rose & Malamud [Page 4]
RFC 1486 An Experiment in Remote Printing July 1993
Note that the value of the "Email" field is an RFC 822 mailbox
address.
2.3. Usage Example
Suppose someone wished to send the author some comments on this memo
using this facility. The message constructed might look 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--
Rose & Malamud [Page 5]
RFC 1486 An Experiment in Remote Printing July 1993
2.4. Remote Printing without MIME
If the originator's user agent doesn't support MIME, (e.g., the
originator accesses the Internet mail infrastructure via a gateway in
another mail dominion), then it is still possible for remote printing
to occur, albeit in a more limited fashion. Specifically, because a
"application/remote-printing" content is not present, cover sheet
information must be derived from some other source; and, the message
body will be treated as a "text/plain" content.
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, an alternative syntax is used for
recipient addressing, in which the local-part of the remote printer
server's address consists of "remote-printer" followed by an RFC 822
atom, e.g.,
remote-printer.Arlington_Hewes/Room_403@0.1.5.2.8.6.9.5.1.4.1.tpc.int
This mailbox syntax is purposefully restricted in the interests of
pragmatism.
The atom following "remote-printer" is considered an opaque string
for use in recipient identification when generating a cover sheet.
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 generating a cover sheet using this opaque string, the remote
printer server will interpret an underscore character ("_") as a
Rose & Malamud [Page 6]
RFC 1486 An Experiment in Remote Printing July 1993
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
used in the example above might appear on the cover sheet as
To: Arlington Hewes
Room 403
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.
Note that by using the alternative syntax for recipient addressing,
it is completely legal to send non- textual messages in which the
cover sheet information is automatically derived -- simply by
including "MIME-Version:" and "Content-Type:" headers in the message,
but omitting the initial "application/remote-printing" content, e.g.,
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
%!
Note that by using the alternative syntax for recipient addressing,
remote printing and e-mail recipients can be identified in the same
message.
3. The Experiment
In order to gain experience with this style of remote printing, an
experiment is underway.
Rose & Malamud [Page 7]
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?