RFC1486 日本語訳

Network Working Group                                            M. Rose
Request for Comments: 1486                  Dover Beach Consulting, Inc.
                                                              C. Malamud
                                           Internet Multicasting Service
                                                               July 1993

コメントを求めるワーキンググループM.バラ要求をネットワークでつないでください: Inc.C.マラマッドインターネット同報通信1993年7月に相談する1486ドーヴァービーチ

                    An Experiment in Remote Printing

リモート印刷における実験

Status of this Memo

この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.

このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはインターネット標準を指定しません。 議論と改善提案は要求されています。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。

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. 序論… 1 1.1 汎用インフラストラクチャの利点… 2 2. 手順… 2 2.1 命名、アドレシング、およびルート設定… 3 2.2 リモートアプリケーション/印刷コンテントタイプ… 4 2.3使用例… 5 2.4 MIMEのないリモート印刷… 6 3. 実験… 7 3.1インフラストラクチャ… 8 3.1 .1のゾーン… 8 3.1 .2 MXは記録します… 8 3.2の会計とプライバシー… 9 3.3メーリングリスト… 9 3.4プロトタイプ実装… 10 4. 将来の問題… 11 5. セキュリティ問題… 11 6. 承認… 11 7. 参照… 11 8. 作者のアドレス… 12 A. イメージ/いさかいコンテントタイプ… 13 B.ユニフォームアドレシング… 13

1.  Introduction

1. 序論

   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

リモート印刷1993年7月のローズと1実験あたりマラマッド[1ページ]RFC1486

   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

1.1. 汎用インフラストラクチャの利点

   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

2. 手順

   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.

情報が離れて印刷されることであるときに、ユーザアプリケーションはRFC822[1]メッセージを構成します、2つの部品を持ちながら「複合か混ぜられた」内容[2]に伴う「Message ID」分野を含んでいて、1日による「リモートアプリケーション/印刷」content typeと、印刷されるために情報に対応する任意のcontent typeである秒であり。 そして、リモートプリンタサーバの電子メールアドレスにメッセージを送ります。

   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:

すべてのcontent typeには自然な印刷表現、例えば「オーディオ」か「ビデオ」内容があるというわけではないことに注意されるべきです。 この理由で、「複合か混ぜられた」内容の第二部は以下の1つであるべきです:

      text/plain, message/rfc822, application/postscript image/tiff
      (defined in Appendix A), any multipart

テキスト/平野、メッセージ/rfc822、いくらかアプリケーション/追伸イメージ/いさかい(Appendix Aでは、定義される)、複合

   Note that:

以下のことに注意してください。

   (1)  With the "text/plain" content-type, not all character sets may
        be available for printing.

すべての文字集合ではなく、「テキスト/明瞭な」content typeがある(1)は印刷に利用可能であるかもしれません。

   (2)  With the "message" content-type, the subordinate content will be
        processed recursively.

(2) 「メッセージ」content typeで、下位の内容は再帰的に処理されるでしょう。

Rose & Malamud                                                  [Page 2]

RFC 1486           An Experiment in Remote Printing            July 1993

リモート印刷1993年7月のローズと1実験あたりマラマッド[2ページ]RFC1486

   (3)  With the "application/postscript" content-type, the remote
        printer server should evaluate the contents in a safe execution
        environment.

(3) 「アプリケーション/追伸」content typeで、リモートプリンタサーバは安全な実行環境におけるコンテンツを評価するべきです。

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

(4) 「複合」のcontent typeで、下位のコンテンツは再帰的に処理されるでしょう: 「複合か混ぜられる」か「複合/ダイジェスト」内容に関しては、それぞれの下位の内容は新しいページに始まるでしょう、すべての下位のコンテンツができれば「複合か平行な」内容に関して同じページに始まるでしょうが。 「複合か代替」の内容を処理するとき、当然、1つの下位の内容だけが印刷されるでしょう。

   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

2.1. 命名、アドレシング、およびルート設定

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

プリンタは例えば国際電話ネットワークに接続されたG3-ファクシミリデバイスに対応する電話番号によって特定されます。

        +1 415 968 2510

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

その国の中の「+1」をIDDD国名略号を示して、残っているストリングが電話番号であるところ。 この数は、例えばメッセージのための受取人アドレスを形成するリモートプリンタサーバのアドレスを構成するのに使用されます。

        remote-printer@0.1.5.2.8.6.9.5.1.4.1.tpc.int

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

すなわち、リモートプリンタサーバのアドレスの地方の部分はALWAYS「リモートプリンタ」です、そして、ドメイン部分は電話番号を逆にすることによって、構成されます、各ケタをドメインラベルに変換して、"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

すなわち、メッセージは、MXアルゴリズム[3]を使用しながら、まさに他のすべての電子メールと同じファッションで発送されます。 リモートプリンタサーバが多くのプリンタにアクセスできるかもしれないので、DNS[4、5]のwildcarding施設はそれに従って、使用されます。 例えば、リモートプリンタサーバであるなら、住んでいて、電話番号接頭語があるどんなプリンタにもアクセスする望みが"dbc.mtview.ca.us"にありました。

        +1 415 968

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

*.8.6.9.5.1.4.1.tpc.int。 IN MX10dbc.mtview.ca.us。

Rose & Malamud                                                  [Page 3]

RFC 1486           An Experiment in Remote Printing            July 1993

リモート印刷1993年7月のローズと1実験あたりマラマッド[3ページ]RFC1486

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

当然、いくつかのリモートプリンタサーバが、その接頭語で何かプリンタにアクセスしても構わないと思っているなら、複数のMXリソース記録が存在しているでしょうに。

   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.

リモートプリンタサーバのアドレスに合っているRRがそうしないワイルドカードの存在が、または、有効ですが、対応する電話番号が有効であり、G3-ファクシミリデバイスが電話番号で接続されるのを含意することに注意されるべきです。

2.2.  The application/remote-printing Content-Type

2.2. リモートアプリケーション/印刷コンテントタイプ

   (1)  MIME type name: application

(1) MIMEの種類名: アプリケーション

   (2)  MIME subtype name: remote-printing

(2) MIME「副-タイプ」は以下を命名します。 リモート印刷

   (3)  Required parameters: none

(3) 必要なパラメタ: なし

   (4)  Optional parameters: none

(4)の任意のパラメタ: なし

   (5)  Encoding considerations: 7bit preferred

(5) 問題をコード化します: 好まれた7ビット

   (6)  Security considerations: none

(6) セキュリティ問題: なし

   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 typeは表紙を生成するとき使用される創始者と受取人情報を含んでいます。 RFC822のABNF記法を使用して、この内容のための構文は以下の通りです。

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

<内容>:、:= <受取人インフォメーション>CRLF<創始者インフォメーション>。[CRLF<カバーインフォメーション>]

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

<受取人インフォメーション>:、:= 「「受取人」」:、」 <値の>CRLF<アドレスインフォメーション><創始者インフォメーション>:、:= 「「創始者」」:、」 <値の>CRLF<アドレスインフォメーション>。

        <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>     ]

<アドレスインフォメーション>:、:= 「[」 : 」 「タイトル」<値の>CRLF] [」 : 」 「部」<値の>CRLF] [」 : 」 「組織」<値の>CRLF] [「Mailstop」 」 : 」 <値の>CRLF] [」 : 」 「アドレス」<値の>CRLF][」 : 」 「電話」<値の>CRLF]「ファクシミリ」」:、」 「<値の>CRLF[」 : 」 「メール」<値の>CRLF]<値の>:、:= *テキスト[CRLF LWSP-炭の<値の>]

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

<カバーインフォメーション>:、:= *(*テキストCRLF)

Rose & Malamud                                                  [Page 4]

RFC 1486           An Experiment in Remote Printing            July 1993

リモート印刷1993年7月のローズと1実験あたりマラマッド[4ページ]RFC1486

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

「メール」分野の値がRFC822メールボックスアドレスであることに注意してください。

2.3.  Usage Example

2.3. 使用例

   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"

To: remote-printer@0.1.5.2.8.6.9.5.1.4.1.tpc.int From: 「ジョンQ.公衆、「 <jpublic@tpd.org 、gt;、日付:、」 Sun、1993年4月11日の20:34:13 -0800Subject: 「リモート印刷における実験」Message IDのコメント: <19930411203413000.456@tpd.org>MIMEバージョン: 1.0コンテントタイプ: 複合か混ぜられる。 「境界=」----- =_aaaaaaaaaa0"

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

------- =_aaaaaaaaaa0コンテントタイプ: リモートアプリケーション/印刷

        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

受取人: マーシャルバラタイトル: 主要な組織: ドーヴァービーチコンサルティングInc.アドレス: 420 Whisman法廷カリフォルニア94043-2186マウンテンビュー(米国)に電話をします: +1 1052年の415 968ファクシミリ: +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>

創始者: ジョンのQ.公共団体: 公共の場電話: +1 1234年の801 555ファクシミリ: +1 6789年の801 555メール: 「ジョンQ.公衆、「 <jpublic@tpd.org 、gt;、」

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

ここに現れるどんなテキストも表紙に続くでしょう。

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

------- =_aaaaaaaaaa0コンテントタイプ: テキスト/平野。 charsetが等しい、「私たち、-、ASCII、」

        Here are my comments on your draft.

ここに、あなたの草稿の私のコメントがあります。

         ...

...

        ------- =_aaaaaaaaaa0--

------- =_aaaaaaaaaa0--

Rose & Malamud                                                  [Page 5]

RFC 1486           An Experiment in Remote Printing            July 1993

リモート印刷1993年7月のローズと1実験あたりマラマッド[5ページ]RFC1486

2.4.  Remote Printing without MIME

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

創始者のユーザエージェントがMIMEをサポートしないなら、(例えば、別のもののゲートウェイを通したインターネット・メールインフラストラクチャが統治権を郵送する創始者アクセス)であり、それにしても、リモート印刷が、より限られたファッションで現れるのは、まだ可能です。 明確に、「リモートアプリケーション/印刷」内容が存在していないので、ある他のソースから表紙情報を得なければなりません。 そして、メッセージ本体は「テキスト/明瞭な」内容として扱われるでしょう。

   Typically, a cover sheet consists of three sections:

通常、表紙は3つのセクションから成ります:

   o    information identifying the originator;

o 創始者を特定する情報。

   o    information identifying the recipient; and,

o 受取人を特定する情報。 そして

   o    additional information supplied by the remote printer server.

o リモートプリンタサーバによって提供された追加情報。

   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.

創始者を特定するのに、リモートプリンタサーバはメッセージヘッダーを使用するでしょう、通常、どんな跡のヘッダー(すなわち、「受け取っ」て「リターンパス」)も裸にして、次に、“From"ヘッダーから始める残っているヘッダーを再注文することによって。

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

受取人を特定するのに、代替の構文は受取人アドレシングに使用されます。(リモートプリンタサーバのアドレスの地方の部分はRFC822原子が例えばあとに続いた「リモートプリンタ」からそれで成ります)。

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

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:

RFC822について言い換えるために、原子は以下と定義されます。

    atom    = 1*atomchar

原子=1*atomchar

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

atomcharは少しもより上に<と等しい、またはどんなケタ(0-9)>/“!"にも英字(A-Z a-z)>/<を小文字で印刷します。 / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "/" / "=" / "?" / "^" / "_" / "`" / "{" / "|" / "}" / "~"

   When generating a cover sheet using this opaque string, the remote
   printer server will interpret an underscore character ("_") as a

この不透明なストリングを使用することで表紙を生成するとき、リモートプリンタサーバはaとして強調キャラクタ("_")を解釈するでしょう。

Rose & Malamud                                                  [Page 6]

RFC 1486           An Experiment in Remote Printing            July 1993

リモート印刷1993年7月のローズと1実験あたりマラマッド[6ページ]RFC1486

   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,

スペース、および行末系列としてのソリドゥスキャラクタ(「/」)。 リモートプリンタサーバは不透明なストリングのただ一つの強調としての2つの連続した強調キャラクタ、およびただ一つのソリドゥスとしての2つの連続したソリドゥスキャラクタを解釈するでしょう。 したがって、不透明なものは結びます。

        Arlington_Hewes/Room_403

アーリントン_ヒューズ/余地の_403

   used in the example above might appear on the cover sheet as

上が表紙の上に現れるかもしれない例で、使用されます。

        To: Arlington Hewes
            Room 403

To: アーリントンヒューズ部屋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.

何らかのインターネット・メールソフトウェア(インターネットの外からの特にゲートウェイ)がメールボックスストリングのサイズに厳しい制限を課すことに注意してください。 したがって、ユーザエージェントを溯源するのに地方の部分をおよそ70未満のキャラクタに制限する際に注意するべきです。

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

受取人アドレシングに代替の構文を使用することによって、単に包含することによって表紙情報が自動的に引き出される非原文のメッセージを送るのが完全に法的であることに注意してください、「MIMEバージョン:」 そして、「コンテントタイプ:」 例えば、ヘッダーしかし、メッセージ、省略における初期の「リモートアプリケーション/印刷」含有量

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

To: remote-printer.Arlington_Hewes/Room_403@0.1.5.2.8.6.9.5.1.4.1.tpc.int cc: マーシャル Rose <mrose@dbc.mtview.ca.us 、gt;、From: カール Malamud <carl@malamud.com 、gt;、日付: Sun、1993年7月18日の09:14:13 -0500Subject: エンハンスMessage-IDのための提案: <19930718141413000.123@malamud.com>MIMEバージョン: 1.0コンテントタイプ: アプリケーション/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

3. 実験

   In order to gain experience with this style of remote printing, an
   experiment is underway.

このスタイルのリモート印刷と共に経験を積むために、実験は進行中です。

Rose & Malamud                                                  [Page 7]

RFC 1486           An Experiment in Remote Printing            July 1993

リモート印刷1993年7月のローズと1実験あたりマラマッド[7ページ]RFC1486

3.1.  Infrastructure

3.1. インフラストラクチャ

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

リモートプリンタサーバへのルーティングにMXのベースのインフラストラクチャを提供するために居住されるのは、そうです。ドメイン"tpc.int" 分配された操作を容易にして、このドメインはそれぞれのIDDD国名略号のためにゾーンに分割されます。 実験に参加するサイトは記載されているために適切なゾーンの管理者に連絡します、ゾーンに関連しているSOAリソース記録を調べることによって。 例えば、オランダ(IDDD国名略号31)のサイトがドメイン"1.3.tpc.int"へゾーンの管理者に連絡するだろう、例えば記載されています。

        % dig 1.3.tpc.int. soa

%は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.

それぞれのゾーンの管理者には、関係者を記載するための簡単なセットの手順があります。 例えば、米国(IDDD国名略号1)に参加して、サイトは「交換ファイル」を管理者に送ります。(その管理者は、サイトが記載したがっている接頭語を示します)。 ゾーンの管理者、ドメイン"1.tpc.int" 各市外局番のためにゾーンを作成するためにすべて参加しているサイトからの交換ファイルを合併します。 そして、これらのゾーンは、正常なDNSゾーン転送手順を用いることで模写されます。

3.1.1.  Zones

3.1.1. ゾーン

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

"tpc.int"の下のゾーンがIDDD国名略号と市外局番に基づいて作成されることに注意されるべきです。 それらは各サブドメインのために作成されません。 例えば、アメリカとカナダ(IDDD国名略号1)では、各市外局番のために1つ未満のゾーンを割り当てます。 対照的に、より小さい付番プランがある国に関して、全の国に、ただ一つの唯一のゾーンはそうでしょう。割り当てる。 例えば、フィジー(IDDD国名略号679)であるなら、次に、実験に参加するために、すなわち、DNS、"9.7.6.tpc.int"にただ一つのゾーンが加えられそうであるだろうということでした。

3.1.2.  MX records

3.1.2. MX記録

   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

ゾーンの現在のMX記録は任意のレベルの精度を持つことができます。 例えば、北米のNumbering Plan(IDDD国名略号1)は4ケタのステーション番号があとに続いた3ケタの交換接頭語があとに続いた3ケタの市外局番によって構造化されます。 そういうものとして、人は、このゾーンでのそのMX記録が同様であると予想するかもしれません。

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

*.5.1.4.1.tpc.int。 IN MX10dbc.mtview.ca.us。

Rose & Malamud                                                  [Page 8]

RFC 1486           An Experiment in Remote Printing            July 1993

リモート印刷1993年7月のローズと1実験あたりマラマッド[8ページ]RFC1486

   which accessed any printer with a telephone number prefix of

どれ、電話番号接頭語があるどんなプリンタにもアクセスするか。

        +1 415

+1 415

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

(すなわち、許容は、市外局番415)でどんなプリンタにもアクセスするか、または同様であるかもしれません。

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

*.8.6.9.5.1.4.1.tpc.int。 IN MX10dbc.mtview.ca.us。

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

(すなわち、市外局番415でどんなプリンタへのアクセスも許して、接頭語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

+1 415 96

   then an MX record such as

MXが記録するその時

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

*.6.9.5.1.4.1.tpc.int。 IN MX10dbc.mtview.ca.us。

   could be used.

使用できました。

3.2.  Accounting and Privacy

3.2. 会計とプライバシー

   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 メッセージが受け取られた日付。

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

o “From"と「Message ID」分野。

   o    the size of the body;

o ボディーのサイズ。

   o    the identity (telephone number) of the printer;

o プリンタのアイデンティティ(電話番号)。

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

o 通話時間などの電話関連のどんな情報も。 そして

   o    any G3-related information, such recipient ID.

o G3関連の情報、どんなそのような受取人ID。

3.3.  Mailing list

3.3. メーリングリスト

   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

リモート印刷1993年7月のローズと1実験あたりマラマッド[9ページ]RFC1486

        tpc-rp-request@aarnet.edu.au

tpc-rp-request@aarnet.edu.au

   and ask to subscribe to the

そして、加入するように頼みます。

        tpc-rp@aarnet.edu.au

tpc-rp@aarnet.edu.au

   list.

記載してください。

3.4.  Prototype Implementation

3.4. プロトタイプ実装

   A prototype implementation is openly available.  The MIME
   instructions for retrieval are:

プロトタイプ実装はオープンに利用可能です。 検索のためのMIME指示は以下の通りです。

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

MIMEバージョン: 1.0コンテントタイプ: 複合/代替手段。 「境界=」----- =_aaaaaaaaaa0" Content-記述: ftpへの指針とメールアクセス

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

------- =_aaaaaaaaaa0コンテントタイプ: 外部のメッセージ/ボディー。 アクセス型は「メールサーバ」と等しいです。 サーバ=" 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>

コンテントタイプ: 八重奏アプリケーション/ストリーム。 =「タール」をタイプしてください。 x-変換は「x-湿布」コンテントIDと等しいです: <4599.735726126.1@dbc.mtview.ca.us>。

        mimesend mrose/tpc/rp.tar.Z

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"

------- =_aaaaaaaaaa0コンテントタイプ: 外部のメッセージ/ボディー。 アクセス型=は「やがて、ftpします」。 "rp.tar.Z"と=を命名してください。 ディレクトリは"mrose/tpc"と等しいです。 サイト="ftp.ics.uci.edu"

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

コンテントタイプ: 八重奏アプリケーション/ストリーム。 =「タール」をタイプしてください。 x-変換は「x-湿布」コンテントIDと等しいです: <4599.735726126.2@dbc.mtview.ca.us>。

        ------- =_aaaaaaaaaa0--

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

このパッケージは、UNIXベースのシステムのためにソフトウェアを入れてあて、SunOSの下でオープンに利用可能なファクシミリパッケージ(サム・レフラーのFlexFAXパッケージ)で開発されて、テストされて、サーバ関係者と、クライアントかゾーンの管理者のどちらかとして務めるサイトに情報を含んでいます。

Rose & Malamud                                                 [Page 10]

RFC 1486           An Experiment in Remote Printing            July 1993

リモート印刷1993年7月のローズと1実験あたりマラマッド[10ページ]RFC1486

4.  Future Issues

4. 将来の問題

   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 どのcontent typeを決定するか、そして、文字集合はリモートプリンタサーバによってサポートされます。

   o    introduction of authentication, integrity, privacy,
        authorization, and accounting services;

o 認証であって、保全であって、プライバシーの、そして、承認の、そして、会計サービスの導入。

   o    preferential selection of a remote printer server; and,

o リモートプリンタサーバの優先の選択。 そして

   o    aggregation of multiple print recipients in a single
        message.

o ただ一つのメッセージの複数の印刷受取人の集合。

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

初めは、実験はこれらの問題を扱わないでしょう。 しかしながら、その後の仕事は詳細にこれらの問題を考えるかもしれません。

5.  Security Considerations

5. セキュリティ問題

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

インターネット・メールは第三者、および特にメッセージでリレーをモニターするのを受けることがあるかもしれません。

6.  Acknowledgements

6. 承認

   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.

インターネットMulticasting Serviceのカール・マラマッドは実験のデザインの実質的なコメントを提供しました。 また、パドゥーのダグラスComer(RIPEのダニエルKarrenberg、SGIのサム・レフラー、ARPAのポールMockapetris)はコメントを提供しました。

7.  References

7. 参照

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

[1] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、UDEL、1982年8月。

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

[2] Borenstein(N.、および解放されたN.)は「以下をまねます」。 「インターネットメッセージ本体の形式を指定して、説明するためのメカニズム」、RFC1341、Bellcore、Innosoft、1992年6月。

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

[3] ヤマウズラ、C.が「ルート設定とドメインシステムを郵送する」、RFC974、CSNET CIC BBN、8月1982日

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

[4]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、科学が設けるUSC/情報、11月1987日

Rose & Malamud                                                 [Page 11]

RFC 1486           An Experiment in Remote Printing            July 1993

リモート印刷1993年7月のローズと1実験あたりマラマッド[11ページ]RFC1486

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

[5]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、科学が設けるUSC/情報、11月1987日

8.  Authors' Addresses

8. 作者のアドレス

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

Inc.420Whisman法廷カリフォルニア94043-2186マウンテンビュー(米国)に相談するマーシャル・T.バラドーヴァービーチ

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

以下に電話をしてください。 +1 415 968、1052Fax: +1 2510年の415 968メール: mrose@dbc.mtview.ca.us

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

カールマラマッドインターネット同報通信スイート1155、ナショナル・プレスビルワシントン、DC20045米国

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

以下に電話をしてください。 +1 202 628-2044Fax: +1 2042年の202 628メール: carl@malamud.com

Rose & Malamud                                                 [Page 12]

RFC 1486           An Experiment in Remote Printing            July 1993

リモート印刷1993年7月のローズと1実験あたりマラマッド[12ページ]RFC1486

Appendix A.  The image/tiff Content-Type

付録A.はイメージ/いさかいコンテントタイプです。

   (1)  MIME type name: image

(1) MIMEの種類名: イメージ

   (2)  MIME subtype name: tiff

(2) MIME「副-タイプ」は以下を命名します。 いさかい

   (3)  Required parameters: none

(3) 必要なパラメタ: なし

   (4)  Optional parameters: none

(4)の任意のパラメタ: なし

   (5)  Encoding considerations: base64

(5) 問題をコード化します: base64

   (6)  Security considerations: none

(6) セキュリティ問題: なし

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

(7) 広められた仕様: TIFFのクラスF以下で定義されて、

      Tag Image File Format (TIFF) revision 6.0

タグImage File Format(TIFF)改正6.0

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

最初に、開発者の机のアルダス社411のAve。 南Suite200シアトル、ワシントン98104 206-622-5500

Appendix B.  Uniform Addressing

付録B.ユニフォームアドレシング

   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.

ユーザは、それの1つ以上がリモート印刷で連絡された受取人であるかもしれないメッセージの数人の受取人を含んでいるのを選ぶかもしれません。 しかしながら、リモートプリンタサーバによって受け入れられたメッセージ・フォーマットは独身の受取人だけを含みます。

   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.

この問題への3つの解決があります: まず最初に、「賢い」ユーザエージェントは、構成の間、1人以上のリモート印刷受取人が出席していると決心して、適切なメッセージを提出できます。 これで、メール受取人のための服従がする不都合はリモート印刷受取人の少しの情報も含みません。

   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.

2番目のソリューションはセクション2.4で説明された受取人アドレシングに代替の構文を使用することです--しかしながら、表紙を組み立てるとき、これは利用可能な役に立つ情報を最小にします。

   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

リモート印刷受取人発破器サーバをユーザに提供するためにクライアントとして参加するサイトには3番目のソリューションがあります。 それぞれのリモート印刷受取人は、メールボックスが発破器に比例して割り当てられて、「普通」のEメールアドレスとしてそういうものとして現れます。 ユーザエージェントには、この戦略を使用して、受取人がメールかリモート印刷でアクセスしやすい知識が全くありません--ユーザは単にメールボックス受取人の収集を指定します。 それらのリモート印刷でアクセスしやすい受取人は自動的に発破器に発送されます。 封筒の各受取人に関しては、ローカルのデータベースはそうです。

Rose & Malamud                                                 [Page 13]

RFC 1486           An Experiment in Remote Printing            July 1993

リモート印刷1993年7月のローズと1実験あたりマラマッド[13ページ]RFC1486

   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: 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

To: mrose@rpexplode.tpd.org cc: アーリントン Hewes <tpcadmin@dbc.mtview.ca.us 、gt;、From: 「ジョンQ.公衆、「 <jpublic@tpd.org 、gt;、日付:、」 Sun、1993年4月11日の20:34:12 -0800Subject: 「リモート印刷における実験」Message IDのコメント: <19930411203412000.123@tpd.org>MIMEバージョン: 1.0コンテントタイプ: テキスト/平野。 charsetが私たちと等しい、-、ASCII

        Here are my comments on your draft.
         ...

ここに、あなたの草稿の私のコメントがあります。 ...

   then the first recipient, "mrose@rpexplode.tpd.org", would be routed
   to an remote printing exploder, which would submit the message shown
   in the example in Section 2.3.  The second recipient,
   "tpcadmin@dbc.mtview.ca.us", would receive the message shown here.
   Note that a reply by this recipient could include the remote printing
   recipient.

そして、最初の受取人" mrose@rpexplode.tpd.org "はリモート印刷発破器に発送されるでしょう。(それは、セクション2.3の例に示されたメッセージを提出するでしょう)。 2番目の受取人" tpcadmin@dbc.mtview.ca.us "はここに示されたメッセージを受け取るでしょう。 この受取人による回答がリモート印刷受取人を含むかもしれないことに注意してください。

Rose & Malamud                                                 [Page 14]

ローズとマラマッド[14ページ]