rfc1486.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 787 行 · 第 1/2 页


RFC 1486           An Experiment in Remote Printing            July 1993


3.1.  Infrastructure

   The domain "tpc.int." is being populated in order to provide the MX-
   based infrastructure for routing to a remote printer server.  In
   order to facilitate distributed operations, this domain is divided
   into a zone for each IDDD country code.  Sites participating in the
   experiment contact the appropriate zone administrator in order to be
   listed, by examining the SOA resource record associated with the
   zone.  For example, a site in the Netherlands (IDDD country code 31)
   would contact the zone administrator for the domain "1.3.tpc.int." in
   order to be listed, e.g.,

        % dig 1.3.tpc.int. soa

   Each zone administrator has a simple set of procedures for listing a
   participant.  For example, in the US (IDDD country code 1),
   participating sites send an "exchange file" to the administrator,
   which indicates the prefixes that the site wishes to list.  The zone
   administrator for the domain "1.tpc.int." merges the exchange files
   from all participating sites to create a zone for each area code.
   These zones are then replicated using the normal DNS zone transfer
   procedures.

3.1.1.  Zones

   It should be noted that zones under "tpc.int" are created on the
   basis of IDDD country codes and area codes; they are not created 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.  In
   contrast, for countries with a smaller numbering plan, only a single
   zone, for the whole country would be allocated.  For example, if Fiji
   (IDDD country code 679), were to join the experiment, then it is
   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 present in a zone can have an arbitrary level of
   precision.  For example, the North American Numbering Plan (IDDD
   country code 1) is structured by a 3-digit area code, followed by a
   3-digit exchange prefix, followed by a 4-digit station number.  As
   such, one might expect that MX records in this zone would be similar
   to

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






Rose & Malamud                                                  [Page 8]

RFC 1486           An Experiment in Remote Printing            July 1993


   which accessed any printer with a telephone number prefix of

        +1 415

   (i.e., allowing access to any printer in area code 415), or might be
   similar to

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

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

   However, the level of precision is arbitrary.  For example, if all of
   the printers in an organization had a telephone number prefix of

        +1 415 96

   then an MX record such as

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

   could be used.

3.2.  Accounting and Privacy

   There is no accounting nor settlement in the experiment; however,
   participating sites may implement access control to prevent abuse.
   Records may be kept for auditing purposes; however, the privacy of a
   participant's printing should be honored.  As such, any auditing
   should contain at most this information:

   o    the date the message was received;

   o    the "From" and "Message-ID" fields;

   o    the size of the body;

   o    the identity (telephone number) of the printer;

   o    any telephony-related information, such as call duration;
        and,

   o    any G3-related information, such recipient ID.

3.3.  Mailing list

   There is a mailing list for the experiment.  Interested readers
   should send a note to:



Rose & Malamud                                                  [Page 9]

RFC 1486           An Experiment in Remote Printing            July 1993


        [e-mail]

   and ask to subscribe to the

        [e-mail]

   list.

3.4.  Prototype Implementation

   A prototype implementation is openly available.  The MIME
   instructions for retrieval 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="[e-mail]"

        Content-Type: application/octet-stream; type="tar";
                x-conversions="x-compress"
        Content-ID: <[e-mail]>

        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: <[e-mail]>

        ------- =_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.






Rose & Malamud                                                 [Page 10]

RFC 1486           An Experiment in Remote Printing            July 1993


4.  Future Issues

   The experiment in remote printing described herein does not address
   several issues, 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.

   Initially, the experiment will not address these issues.  However,
   subsequent work might consider these issues in detail.

5.  Security Considerations

   Internet mail may be subject to monitoring by third parties, and in
   particular, message relays.

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, 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.






Rose & Malamud                                                 [Page 11]

RFC 1486           An Experiment in Remote Printing            July 1993


   [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: [phone]
   Fax:   [phone]
   EMail: [e-mail]


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

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]

























Rose & Malamud                                                 [Page 12]

RFC 1486           An Experiment in Remote Printing            July 1993


Appendix A.  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

Appendix B.  Uniform Addressing

   A user may choose to include several recipients in a message, one or
   more of which may be recipients reached via remote printing.
   However, the message format accepted by a remote printer server
   contains only a single recipient.

   There are three solutions to this problem: first, during composition,
   a "smart" user agent can determine that one or more remote printing
   recipients are present, and submit the appropriate messages.  This
   has the disadvantage that the submission for the e-mail recipients
   does not contain any information about the remote-printing
   recipients.

   A second solution is to use the alternative syntax for recipient
   addressing described in Section 2.4 -- however, this minimizes useful
   information available when constructing the cover sheet.

   A third solution is for a site participating as a client to offer a
   remote printing recipient exploder server to its users.  Each remote
   printing recipient is assigned a mailbox relative to the exploder,
   and, as such, appears as an "ordinary" e-mail address.  Using this
   strategy, the user agent has no knowledge of which recipients are
   accessible via e-mail or remote-printing -- the user simply specifies
   a collection of mailbox recipients.  Those recipients which are
   accessible via remote-printing are automatically routed to the
   exploder.  For each recipient in the envelope, a local database is



Rose & Malamud                                                 [Page 13]

RFC 1486           An Experiment in Remote Printing            July 1993


   consulted to retrieve addressing information for the recipient, and a
   message is submitted to the appropriate remote printer server.

For example, if the original message submitted was:

        To: [e-mail]
        cc: Arlington Hewes <[e-mail]>
        From: "John Q. Public" <[e-mail]>
        Date: Sun, 11 Apr 1993 20:34:12 -0800
        Subject: Comments on "An Experiment in Remote Printing"
        Message-ID: <[e-mail]>
        MIME-Version: 1.0
        Content-Type: text/plain; charset=us-ascii

        Here are my comments on your draft.
         ...

   then the first recipient, "[e-mail]", would be routed
   to an remote printing exploder, which would submit the message shown
   in the example in Section 2.3.  The second recipient,
   "[e-mail]", would receive the message shown here.
   Note that a reply by this recipient could include the remote printing
   recipient.




























Rose & Malamud                                                 [Page 14]