|
|
Close Help | ||||||||||||||
Also See RFC documents relating to the Principles of Operation for the tpc.int Subdomain:
See also:
The experiment is a project in outreach: to integrate the e-mail and facsimile communities. Working together, many sites cooperatively provide "remote printing" access to the international telephone network. This allows people to send faxes via e-mail. The general-purpose Internet e-mail infrastructure takes care of all the routing, delivering the message to the appropriate remote printer gateway in a manner totally transparent to the user.
We believe that 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 to outreach allows an organization to make it easier for the "outside world" to communicate with personnel in the organization who are users of facsimile but not e-mail, such as 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. Of course, as the experiment progresses, some of the things we'll be studying are economic and policy models that deal with issues such as accounting and settlement.
There's a mailing list. Send a note to majordomo@info.tpc.int containing only the following text in the body: subscribe tpc-rp
Send mail to tpcfaq@info.tpc.int We will quickly dispatch our current version to you.
Is this simple enough?
To: remote-printer.Arlington_Hewes/Room_403@14159682510.iddd.tpc.int
or
To: remote-printer.Arlington_Hewes/Room_403@0.1.5.2.8.6.9.5.1.4.1.tpc.int
This will get automatically routed to a remote printer server, which will transmit a facsimile to the recipient. When the transmission completes, a message will be sent back to you.
Let's look at the strings on either side of the '@'-sign.
The left-hand part identifies the kind of access (remote-printer) along with the identity of the recipient (Arlington_Hewes/Room_403).
Because some mailers have difficulty dealing with addresses that contain spaces, etc., you should be very careful as to what characters you use to identify the recipient. It safest to use upper and lower case letters, digits, and two special characters ('_' and '/').
When a cover sheet is generated, the '_' will turn into a space and the '/' will turn into an end-of-line sequence. So, given the address above, the cover sheet might start with
Please deliver this facsimile to: Arlington Hewes Room 403
The right-hand part identifies the telephone number of the remote-printer. It must be an international telephone number. Telephone numbers are usually written like this:
+code-number
where "code" identifies the country and "number" is the telephone number within the country, e.g.
+1-415 968 2510
For those interested in telephonic trivia, the maximum number of digits is 15. In order to get the Internet e-mail infrastructure to automatically route messages, the punctuation characters are stripped out, e.g.,
14159682510
and then the string is inverted and turned into an Internet domain name, e.g.,
0.1.5.2.8.6.9.5.1.4.1.tpc.int
Note that the telephone number should not include any international access codes. Here's why: if, from the US, I wanted to call someone in Tokyo (+81-33-...), I would dial something starting with "0118133" The first three digits (011) is the international access code for the US. If I were to call that same number from FR, I would dial something starting with "198133". The first two digits (19) is the international access code for FR. In contrast, the tail of the domain name for Tokyo is always
3.3.1.8.tpc.int
regardless of where in the world you are sending your mail. This approach allows us to map from the Internet naming scheme onto the entire international telephone network. And, as you might expect, you can mix remote-printing and e-mail recipients in the same message, e.g.,
To: remote-printer.Arlington_Hewes/Room_403@0.1.5.2.8.6.9.5.1.4.1.tpc.int
cc: mrose@dbc.mtview.ca.us (Marshall Rose)
In fact, the replies generated by the e-mail recipients can even go to the remote-printing recipients.
Get real. The official kick-off of the experiment was 16 July 1993. At that time, service was operational for:
In addition, we expect the following countries to come on-line soon:
Many enterprises, such as companies, universities, and government R&D centers, are also coming on-line. The basic idea is that each participating site registers a "cell" indicating the portion of the international telephone number space that they are willing to provide access to. A cell can be a continent, a campus, abuilding, or a single phone number.
Well, we call them cells. The idea is that there are really four kinds of participating sites:
A neighborhood site is run by someone who provides access to any facsimile machine in its "local calling area". The idea being that metered access to this area is fairly inexpensive, and the site is willing to provide access as a part of their community spirit. Access to Silicon Valley is provided by several neighborhood sites. The interesting thing to note is that neighborhood sites may choose to shrink or expand their cell, depending on factors such as demand and cost.
A regional site is basically just a large neighborhood site, usually providing access to an entire country or a large part of a country, such as an area code. The continent of Australia is an example of a regional site.
An enterprise site is run by a company that provides access solely to its own facsimile machines. They register exactly those telephone prefixes which apply to their enterprise. The University of Michigan is an example of this. Of course, a geographically-disperse enterprise such as a multi-national company could also do this.
A personal site is run by someone who provides access to exactly one facsimile machine, usually one that resides on their desktop. In this case, when the remote printer server gets the message, it will just deliver it to the owner of the desktop -- via e-mail.
Note that there can be overlapping remote printer servers for a given area. A personal site, for example, might be in the area served by a neighborhood site. Since the Internet domain name system always favors the longest match, the smaller site gets precedence for its own traffic
If you're a guru, you just use your standard DNS lookup tools. If you don't know what the DNS is, there's a command-line tool available:
% rpvalidate +1-415-968-2510 accessible
The section below on "Is there software available?" will tell you where to find the rpvalidate command. Of course, you can always just send the message and see if it bounces, which is a pretty good indication that there is no service for that number yet. You can also send mail to tpccover@info.tpc.int, and you'll get back a list of the current coverage areas.
Use MIME
MIME is the Internet-standards track technology for multi-media messaging. Remote printer servers support, at a minimum, the following MIME content types:
So, you might send something like the following:
To: remote-printer.Arlington_Hewes/Room_403@0.1.5.2.8.6.9.5.1.4.1.tpc.int
MIME-Version: 1.0
Content-Type: application/postscript
%!
...
You want a lot of things don't you? A MIME content-type has been defined for this. It's called application/remote-printing. Here's an example:
Content-Type: application/remote-printing
Recipient: Darren Nickerson
Organization: University of Oxford
Department: New Chemistry Lab
Telephone: +44 1865 275975
Facsimile: +44 1865 271503
Email: darren.nickerson@balliol.oxford.ac.uk
Originator: Mr. Arlington Hewes
Organization: The Phone Company - International
Department: Administration
Telephone: +44 1234 123456
Facsimile: +44 1234 123457
Email: tpcadmin@info.tpc.int
Any text appearing here would go on the cover-sheet.
To use this mechanism, the top-level content in your message must be multipart/mixed, and the very first content in that must be application/remote-printing. Also, if you use this, then the left-hand part of the recipient's address should just be "remote-printer".
Yes. See the section below on " Is there software available?"
You need four things:
You also need to agree to operate the cell in a fashion consistent with the policies associated with the tpc.int subdomain. A list of this software can be located at the URL http://www.tpc.int/devel_corner.html
Yes. See RFC 1529, "An Experiment in Remote Printing". It's available at the usual RFC repositories. In the future, there will probably be several documents, including one on policy.
The tpc.int subdomain is structured as a cooperative of the remote printer servers around the world. Policy for the subdomain is made in the time-honored tradition of hoping that things will run well enough on their own. In cases where additional guidance is necessary, a Board of Arbitration and Conciliation considers situations brought to it by the members and issues written opinions. Initially policy was set by the two people who started the experiment, Carl Malamud of the Internet Multicasting Service, a non-profit organization, and Marshall Rose of Dover Beach Consulting, Inc. (Rose spends half of his time on openly available projects, of which this is one.) Now however, the task has fallen on the shoulders of Darren Nickerson, a PhD student in Oxford, England.
Ultimately, it's all about maintaining basic principles for the subdomain such as: functionality, fairness, cost recovery, performance, efficiency, security, and legality.
An indictment by a federal grand jury. Just kidding. Ha, ha. They're doing research on how to integrate special-purpose devices like G3 facsimile printers into the fabric of a general-purpose infrastructure like the global Internet compute rnetwork. Neither Malamud nor Rose will profit from the project, though they sincerely hope that operators in the tpc.int subdomain are able to recoup their costs, save consumers money, and maybe even make a healthy profit.
Well, gee. . . he's not sure. His interest was piqued by the possibility of subverting large telco corporations, and after setting up his own cell in Oxford, he decided to take a larger role in the development of the tpc.int subdomain for the good of the many. Let's see what the kid can do.
No. For now, there's one simple rule:
It is perfectly acceptable to deny access on the basis of originator identity, but it is not acceptable to deny access on the basis of recipient identity
The reason for this is simple: if a site finds that some originator is acting in an abusive manner, then the site can deny access. But, when a site registers a cell, it agrees to provide access to every telephone number in that cell. Of course, it can always register a smaller cell.
There are strict rules as to the kind of auditing information which a remote printer server may keep. Basically, this information is necessary for debugging purposes, e.g., if you send a message and don't get a completion or failure acknowledgement later on, the site providing access may need to check into it. Also, there are strict rules guaranteeing that the contents of a fax are secure and will not be monitored by the remote printer server operators.
That would be Mr. Arlington Hewes ( tpcadmin@info.tpc.int). Mr. Hewes is a busy man, so before sending a note to this mailbox, please consider whether the general discussion list (tpc-rp@info.tpc.int) mentioned earlier might not be a more appropriate forum.
Not really. Technically, just about any computer on the Internet could run a remote printer server. However, we recommend that the computer have IP-connectivity, since this tends to make the service faster than with systems connected with polling mechanisms like UUCP. Still, the tpc.int subdomain is not picky and if you can provide service for an area that would otherwise not have it, welcome aboard! The more important requirement is that you have fax spooling software available for your computer.
Yes. An openly available implementation can be found on
site: ftp.tpc.int
area: /tpc
file: rp.tar.Z
Be sure to retrieve it in BINARY mode, eh?
In addition, if you're running Innosoft's PMDF software for OpenVMS, then you can contact them at service@innosoft.com for the details. Also, if you're a vendor who adds support for remote-printing to your software, we want to hear from you.
It contains pointers to existing openly available software along with some "glue" software for BSD-derived UNIX systems.
For sites that want to run remote printer servers, there is support for both the openly available HylaFAX package and the Bristol Group's IsoFax product.
For sites that want to use remote printing, there are some scripts, primarily for MH users. If you are willing to contribute to the openly available software package, we'd love to hear from you. For example, we'd love to see Mac clients, a Z-mail macro, or a new LISP interpreter/mail agent written entirely in sendmail rewrite rules.
Go rent the film "The President's Analyst", from Paramount Pictures, 1967.
Go read Thomas Pynchon's "The Crying of Lot 49", Harpers and Row (New York, 1986).
Return to Remote Printing
Home Page
Written and copyrighted © by Mr. Arlington Hewes tpcadmin@info.tpc.int
Converted into html by shipley@dis.org
v1.5