RFC1568 日本語訳

Network Working Group                                           A. Gwinn
Request for Comments: 1568                 Southern Methodist University
Category: Informational                                     January 1994

Gwinnがコメントのために要求するワーキンググループA.をネットワークでつないでください: 1568年の南部のメソジスト教派の大学カテゴリ: 情報の1994年1月

             Simple Network Paging Protocol - Version 1(b)

簡単なネットワークページングプロトコル--バージョン1(b)

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Abstract

要約

   This RFC suggests a simple way for delivering both alphanumeric and
   numeric pages (one-way) to radio paging terminals.  Gateways
   supporting this protocol, as well as SMTP, have been in use for
   several months in one nationwide paging firm.  One other paging firm
   is in the process of adopting it.

このRFCは英数字の、そして、数値の両方のページ(一方向)をラジオページング端末に提供するための簡単な方法を勧めます。 このプロトコルをサポートするゲートウェイ、およびSMTPは1つの全国的なページング会社における数カ月使用中です。 それを採用することの途中に他の1つのページング会社があります。

   Earlier versions of this specification were reviewed by IESG members
   and the IETF's "822 Extensions" Working Group.  They preferred an
   alternate strategy, as discussed under "Relationship to Other IETF
   Work", below.

この仕様の以前のバージョンはIESGメンバーとIETFの「822の拡大」の作業部会によって見直されました。 彼らは以下の「他のIETF仕事との関係」の下で議論するように代替の戦略を好みました。

1. Introduction

1. 序論

   Beepers are as much a part of computer nerdom as X-terminals
   (perhaps, unfortunately, more).  The intent of Simple Network Paging
   Protocol (SNPP) is to provide a standard whereby pages can be
   delivered to individual paging terminals.  The most obvious benefit
   is the elimination of the need for modems to produce alphanumeric
   pages, and the added ease of delivery of pages to terminals in other
   cities or countries.  Additionally, automatic page delivery should be
   somewhat more simplified.

ポケベルはコンピュータnerdomのXターミナル(恐らく残念ながらより多くの)と同じくらい多くの部分です。 Simple Network Pagingプロトコル(SNPP)の意図は個々のページング端末にページを提供できる規格を提供することです。 最も明白な利益は、モデムが英数字のページを生産する必要性の除去と、他の都市か国の端末へのページの配送の加えられた容易さです。 さらに、自動ページ配送はいくらか簡易型であるべきです。

2. System Philosophy

2. システム哲学

   Radio paging is somewhat taken for granted, because of the wide
   availability and wide use of paging products.  However, the actual
   delivery of the page, and the process used (especially in wider area
   paging) is somewhat complicated.  When a user initiates a page, by
   dialing a number on a telephone, or entering an alphanumeric page
   through some input device, the page must ultimately be delivered to
   some paging terminal, somewhere.  In most cases, this delivery is
   made using TAP (Telocator Alphanumeric input Protocol, also known as
   IXO).  This protocol can be a somewhat convoluted, and complicated

ラジオページングはページング製品の広い有用性と広い使用でいくらか当然のことと思われます。 しかしながら、使用される(特により広い領域ページングで)ページ、およびプロセスの実際の配送はそうです。いくらか複雑です。 ユーザが結局1ページを開始するとき、電話の上で番号にダイヤルするか、またはある入力装置を通して英数字のページに入ることによって、どこかのあるページング端末にページを提供しなければなりません。 多くの場合、TAP(また、IXOとして知られているTelocator Alphanumeric入力プロトコル)を使用することでこの配送をします。 aがいくらか複雑であって、複雑であったなら、このプロトコルはそうすることができます。

Gwinn                                                           [Page 1]

RFC 1568                  SNPP - Version 1(b)               January 1994

Gwinn[1ページ]RFC1568SNPP--バージョン1(b)1994年1月

   protocol using older style ASCII control characters and a non-
   standard checksumming routine to assist in validating the data.  One
   note: even though the TAP protocol allows for a password for sending
   simple pages, they are rarely used (especially in commercial
   markets), and therefore support for them has not been implemented in
   this version of the protocol.

データを有効にするのを助けるのにより古いスタイルASCII制御文字と非標準のchecksummingルーチンを使用することで、議定書を作ってください。 1つの注意: TAPプロトコルは送付簡単なページパスワードを考慮しますが、それらはめったに使用されません、そして、(特に商業市場で)したがって、それらのサポートはプロトコルのこのバージョンで実装されていません。

   Even though TAP is widely used throughout the industry, there are
   plans on the table to move to a more flexible "standard" protocol
   (the proposal for which is actually more convoluted than most
   Internet RFC's).  However, acknowledging the complexity and
   flexibility of the current protocols (or the lack thereof), the final
   user function is quite simple: to deliver a page from point-of-origin
   to someone's beeper.  That is the simple, real-time function that
   this protocol attempts to address.  Validation of the paging
   information is left completely up to the TAP/IXO paging terminal,
   making an SNPP gateway a direct "shim" between a paging terminal and
   the Internet.

TAPは産業中で広く使用されますが、プランが、よりフレキシブルな「標準」のプロトコル(どれが実際にそうであるかに、RFCほとんどのインターネットのより複雑な提案)に動かすテーブルにあります。 しかしながら、現在のプロトコル(または、それの不足)の複雑さと柔軟性を承認して、最終的なユーザ機能はかなり簡単です: 原産地からだれかのポケベルまでの1ページを提供するために。 それはこのプロトコルが扱うのを試みる簡単で、リアルタイムの機能です。 ページング情報の合法化は完全にTAP/IXOページング端末に任せられます、ページング端末とインターネットの間でSNPPゲートウェイをダイレクト「詰め物」にして。

3. Why not just use Email and SMTP?

3. なぜただメールとSMTPを使用しませんか?

   Email, while quite reliable, is not always timely.  A good example of
   this is deferred messaging when a gateway is down. Suppose Mary Ghoti
   (fish@hugecompany.org) sends a message to Zaphod Beeblebrox's beeper
   (5551212@pager.pagingcompany.com). Hugecompany's gateway to the
   Internet is down causing Mary's message to be deferred.  Mary,
   however, is not notified of this delay because her message has not
   actually failed to reach its destination.  Three hours later, the
   link is restored, and (as soon as sendmail wakes up) the message is
   sent.  Obviously, if Mary's page concerned a meeting that was
   supposed to happen 2 hours ago, there will be some minor
   administrative details to work out between Mary and Zaphod!

かなり信頼できますが、メールはいつもタイムリーであるというわけではありません。 ゲートウェイが下がっているとき、この好例は延期されたメッセージングです。 メアリGhoti( fish@hugecompany.org )がZaphod Beeblebroxのポケベル( 5551212@pager.pagingcompany.com )にメッセージを送ると仮定してください。 インターネットへのHugecompanyのゲートウェイはメアリの延期されるべきメッセージを引き起こすのにおいて下がっています。 彼女のメッセージが実際に必ず目的地に到着したので、しかしながら、メアリはこの遅れについて通知されません。 3時間後に、リンクを返します、そして、(sendmailが目覚めるとすぐに)メッセージを送ります。 明らかに、メアリのページは2時間前に起こるべきであったミーティングに関係があったなら、メアリとZaphodで詰めるいくつかの小さい方の管理細部があるでしょう!

   On the other hand, if Mary had used her SNPP client (or simply
   telnetted to the SNPP gateway), she would have immediately discovered
   the network problem.  She would have decided to invoke plan "B" and
   call Zaphod's pager on the telephone, ringing him that way.

他方では、メアリが彼女のSNPPクライアント(または、単に、SNPPゲートウェイに、telnettedした)を使用したなら、彼女はすぐに、ネットワーク問題を発見したでしょうに。 そのように彼に電話をして、彼女は、プラン「B」を呼び出して、電話でZaphodのポケットベルと呼ぶと決めたでしょう。

   The obvious difference here is not page delivery, but the immediate
   notification of a problem that affects your message.  Standard email
   and SMTP, while quite reliable in most cases, cannot be positively
   guaranteed between all nodes at all times, making it less desirable
   for emergency or urgent paging.  The other consideration is the
   relative simplicity of the SNPP protocol for manual Telnet sessions
   versus someone trying to manually hack a mail message into a gateway.

ここの明白な違いはページ配送ではなく、あなたのメッセージに影響する問題が即座の通知です。 標準のメールとSMTP、多くの場合、かなり信頼できる間、すべてのノードの間で明確にいつも保証できるというわけではありません、それを非常時望ましくないのも、それほど緊急でないページングにして。 もう片方の考慮は手動のTelnetセッションのためのSNPPプロトコル対手動でメール・メッセージをゲートウェイにハックしようとするだれかの相対的な簡単さです。

Gwinn                                                           [Page 2]

RFC 1568                  SNPP - Version 1(b)               January 1994

Gwinn[2ページ]RFC1568SNPP--バージョン1(b)1994年1月

4. The Future of SNPP

4. SNPPの未来

   While the current form of the SNPP protocol is designed for use with
   TAP/IXO, it is intended to provide a porting base for use with the
   newer TME (TDP) protocol.  In addition, future releases of SNPP will
   allow for multiple recipient messages with individual "envelope"
   options and specifications as allowed by TME.  For example, the
   protocol should allow the user to specify delivery of an urgent
   message to Zaphod in Denver, while carbon-copying Mary in Des Moines
   at a lower priority.

SNPPプロトコルの現在のフォームはTAP/IXOとの使用のために設計されていますが、より新しいTME(TDP)プロトコルを使用のためのポーティングベースに提供するのは意図しています。 さらに、TMEによって許容されているようにSNPPの今後のリリースは個々の「封筒」オプションと仕様がある複数の受取人メッセージを考慮するでしょう。 例えば、ユーザはデンバーでプロトコルで急報の配送をZaphodに指定できるべきです、低優先度におけるデモインにおける炭素をコピーするメアリである間。

5. The Protocol

5. プロトコル

   The SNPP protocol is a sequence of commands and replies, and is based
   on the philosophy of many other Internet protocols currently in use.
   SNPP has six input commands (the first 4 characters of each are
   significant) that solicit various server responses falling into three
   categories: (1) successful, (2) failed-but-continue, and (3) failed-
   with-connection-terminated.  The first character of every server
   response code is a digit indicating the category of response: '2xx',
   '5xx', and '4xx' respectfully.  The text portion of the response
   following the code may be altered to suit individual applications.

SNPPプロトコルは、コマンドと回答の系列であり、現在使用中の他の多くのインターネットプロトコルの哲学に基づいています。 SNPPには、3つのカテゴリになる様々なサーバ応答に請求する6つの入力コマンド(それぞれの最初の4つのキャラクタが重要である)があります: (1) (2) うまくいって、しかし、失敗されて、続いてください。そうすれば、(3)は接続と共に終えられた状態で失敗しました。 あらゆるサーバ応答コードの最初のキャラクタは応答のカテゴリを示すケタです: '2xx'、'5xx'、および'4xx'、謹んで。 コードに従う応答のテキスト部分は、個々のアプリケーションに合うように変更されるかもしれません。

   The session interaction is actually quite simple (hence the name).
   The client initiates the connection with the listening server.  Upon
   opening the connection, the server issues a greeting followed by "250
   READY" (indicating the willingness of the server to accept SNPP
   commands).  The client passes pager ID information, and a message,
   then issues a "SEND" command.  The server then feeds the information
   to the TAP paging terminal, gathers a response, and reports the
   success or failure to the client.

セッション相互作用は実際にかなり簡単です(したがって、名前)。 クライアントが聴取サーバとの関係を開始する、接続、挨拶が調査したサーバ問題を「250は準備する」開きます(サーバがSNPPコマンドを受け入れる意欲を示します)。 クライアントは、ポケットベルID情報、およびメッセージを通過して、次に、「発信」コマンドを発行します。 サーバは、クライアントに次に、TAPページング端末に情報を提供して、応答を集めて、成否を報告します。

6.1 A Typical Successful Connection

6.1 典型的なうまくいっている接続

           Client                         Server

クライアントサーバ

   Open Connection            -->
                              <--  220 SNPP Gateway Ready
   PAGE 5551212               -->
                              <--  250 OK
   MESS Your network is hosed -->
                              <--  250 OK
   SEND                       -->
                              <--  250 Page Sent
   QUIT                       -->
                              <--  221 OK, Goodbye

開いているConnection--><--220SNPPゲートウェイReady5551212ページ--><--250OK MESS Yourネットワークはホースで水をかけられた(><)250OK SEND(><)250ページです。Sent QUIT--><--221が承認する、Goodbye

Gwinn                                                           [Page 3]

RFC 1568                  SNPP - Version 1(b)               January 1994

Gwinn[3ページ]RFC1568SNPP--バージョン1(b)1994年1月

6.2 Commands

6.2 コマンド

6.2.1 PAGEr <Pager ID>

6.2.1 ポケットベル<Pager ID>。

   The PAGEr command sets the pager ID (PID) number, for the
   transaction, into the gateway.  The PID used must reside in the TAP
   terminal (and there is where it should be validated).  Limited
   validation may optionally be done on the server (such as all numeric,
   and ID length), or it can all be done by the TAP terminal at the time
   the page is sent.  Duplicating the PAGEr command before SENDing the
   message should produce an "503 ERROR, Already Entered" message, and
   allow the user to continue.

PAGErコマンドはトランザクションのポケットベルID(PID)番号をゲートウェイに設定します。 そして、使用されるPIDがTAP端末に住んでいなければならない、(有効にされて、それがどこであるべきであることがあるか、) サーバ(すべての数値や、IDの長さなどの)で任意に株式会社合法化をするかもしれませんか、またはページを送るとき、TAP端末はそれがすべてできます。 SENDingの前にPAGErコマンドをコピーして、メッセージは、「既に入られた503誤り」メッセージを出して、ユーザが続くのを許容するべきです。

   In the future, a series of PAGEr commands may be specified to allow
   for multiple recipients of the same message.  Right now, however,
   TAP/IXO only validates the PID at the time the message is accepted by
   the paging terminal.  This makes "pre" validation of PID's currently
   difficult.

将来、一連のPAGErコマンドが、同じメッセージの複数の受取人を考慮するために指定されるかもしれません。 しかしながら、たった今、ページング端末でメッセージを受け入れるとき、TAP/IXOはPIDを有効にするだけです。 これが作る、「前、」 合法化、PIDは現在、難しいです。

6.2.2 MESSage <Alpha or Numeric Message>

6.2.2 メッセージ<アルファーか数値メッセージ>。

   The MESSage command sets the numeric or alphanumeric message for the
   transaction, into the gateway.  Limited validation of the message may
   be done on the SNPP server (such as length), but type-of-message
   validation should be done by the TAP/IXO paging terminal.
   Duplicating the MESSage command before SENDing the message should
   produce an "503 ERROR, Already Entered" message, and allow the user
   to continue.

MESSageコマンドはトランザクションへの数値の、または、英数字のメッセージをゲートウェイに設定します。 SNPPサーバ(長さなどの)でメッセージの株式会社合法化をするかもしれませんが、TAP/IXOページング端末はメッセージのタイプ合法化をするべきです。 SENDingの前にMESSageコマンドをコピーして、メッセージは、「既に入られた503誤り」メッセージを出して、ユーザが続くのを許容するべきです。

6.2.3 RESEt

6.2.3 リセット

   The RESEt command clears the PAGEr and MESSage fields, and allows the
   client to start over.  This is provided, primarily, as a means to
   reset accidentally entered information during a manual session. Upon
   a successful reset, the server should respond "250 RESET OK".

RESEtコマンドは、PAGErとMESSage分野をきれいにして、クライアントがやり直すのを許容します。手動のセッションの間に偶然入力された情報をリセットする手段として主としてこれを前提とします。 うまくいっているリセットのときに、サーバは「250リセットOK」を反応させるべきです。

6.2.4 SEND

6.2.4 発信してください。

   The SEND command processes the page to the TAP terminal.  Prior to
   processing, the PAGEr and MESSage fields should be checked for the
   existence of information.  Should one of these required fields be
   missing, the server should respond "503 Error, Incomplete
   Information" and allow the user to continue.  Assuming all of the
   fields are filled in, the SNPP server should format and send the page
   to the TAP terminal, and await a response.  Upon receiving a reply,
   the server should respond as follows:

SENDコマンドはTAP端末にページを処理します。 処理の前に、PAGErとMESSage分野は情報の存在がないかどうかチェックされるべきです。 これらの必須項目の1つがなくなるなら、サーバは、「503誤り、不完全情報」について応答して、ユーザが続くのを許容するべきです。 分野のすべてが記入されると仮定する場合、SNPPサーバは、TAP端末にページをフォーマットして、送って、応答を待つべきです。 回答を受け取ると、サーバは以下の通り反応するべきです:

Gwinn                                                           [Page 4]

RFC 1568                  SNPP - Version 1(b)               January 1994

Gwinn[4ページ]RFC1568SNPP--バージョン1(b)1994年1月

    250 Page Sent         - successful delivery
    554 Failed, <reason>  - unsuccessful, and gives a reason

250は、失敗していた状態でSent(うまくいっている配送554Failed、<理由>)を呼び出して、理由をあげます。

   Or, in the case of an illegal or non-existent pager ID, or some other
   administrative reason for rejecting the page, the server should
   respond:

または、不法であるか実在しないポケットベルIDに関するケース、またはページを拒絶するある他の管理理由では、サーバは反応するべきです:

    550 Failed, Illegal Pager ID (or other explanation)

550 失敗して、不法なPager ID(または、他の説明)

   After processing a SEND command, the server should remain online to
   allow the client to enter another page.

SENDコマンドを処理した後に、サーバはクライアントがもう1ページに入るのを許可するためにオンラインのままで残るべきです。

6.2.5 QUIT

6.2.5 やめてください。

   The QUIT command terminates the current session.  The server should
   respond "221 OK, Goodbye" and close the connection.

QUITコマンドは現在のセッションを終えます。 サーバは、「221OK、さようなら」を反応させて、接続を終えるべきです。

6.2.6 HELP

6.2.6 ヘルプ

   The HELP command (optional) displays a screen of information about
   commands that are valid on the SNPP server.  This is primarily to
   assist manual users of the gateway.  Each line of the HELP screen
   (responses) are preceded by a code "214".  At the end of the HELP
   sequence, a "250 OK" is issued.

HELPコマンド(任意の)はSNPPサーバで有効なコマンドの情報のスクリーンを表示します。これは、主としてゲートウェイの手動のユーザを補助するためのものです。 コード「214」はヘルプスクリーン(応答)の各行に先行します。 ヘルプ系列の終わりでは、「250OK」は発行されます。

6.3 Illegal Commands

6.3 不法なコマンド

   Should the client issue an illegal command, the server should respond
   "421 ERROR, Goodbye" and close the connection immediately.
   Optionally, the server may respond "502 Command Error, try again"
   should it be desirable to leave the connection open.

クライアントが不正コマンドを発行するなら、サーバは、「421誤り、さようなら」を反応させて、すぐに、接続を終えるべきです。 任意に、それが接続を開いた状態でおくのにおいて望ましいはずであるなら、サーバは「502Command Error、再試行してください」を反応させるかもしれません。

6.4 Timeouts

6.4 タイムアウト

   The SNPP server can, optionally, have an inactivity timeout
   implemented.  At the expiration of the allotted time, the server
   responds "421 Timeout, Goodbye" and closes the connection.

SNPPサーバで、任意に不活発タイムアウトを実装することができます。 割り当てられた現代の満了のときに、サーバは、「421タイムアウト、さようなら」を反応させて、接続を終えます。

6.5 Rigidity of Command Structure

6.5 命令系統の剛性

   The commands from client to server should remain constant.  However,
   since the first character of the response indicates success or
   failure, the text of the server responses could be altered should one
   desire.  The following is a hunk of C code that is used currently in
   an SNPP gateway.  The only response that has not been discussed is
   "421 SERVER DOWN, Goodbye" and is used when the gateway is
   administratively down, or when there are communication problems with
   the TAP/IXO paging terminal.

クライアントからサーバまでのコマンドは一定のままで残るべきです。 しかしながら、応答の最初のキャラクタが成否を示すのでサーバ応答のテキストを変更できた、望むべきですか? ↓これは現在SNPPゲートウェイで使用されるCコードの塊です。 ゲートウェイが行政上下がっているか、またはTAP/IXOページング端末に関する意思疎通の問題があるとき、議論していない唯一の応答が、「421サーバ下である、さようなら」であり、使用されています。

Gwinn                                                           [Page 5]

RFC 1568                  SNPP - Version 1(b)               January 1994

Gwinn[5ページ]RFC1568SNPP--バージョン1(b)1994年1月

   /* SNPP Client Commands */

/*SNPPクライアントコマンド*/

   #define PAGER        "PAGE"
   #define MESSAGE      "MESS"
   #define SEND         "SEND"
   #define QUIT         "QUIT"
   #define RESET        "RESE"
   #define HELP         "HELP"

##、が定義する「混乱」が"RESE"#が定義するやめられて、#、が定義する「発信してください」#、が定義する「やめてください」リセットに助け「助け」を送るという#、が定義するPAGER「ページ」メッセージを定義してください。

   /* Responses from SNPP server to client */

SNPPサーバからクライアント*/までの/*応答

   #define SNPP_OK      "250 OK"
   #define SNPP_RESET   "250 Reset OK"
   #define SNPP_SENT    "250 Page Sent"
   #define SNPP_BADPIN  "550 Failed,"
   #define SNPP_NOTSENT "554 Failed,"
   #define SNPP_ENTERR  "503 Error, Already Entered"
   #define SNPP_ERRINC  "503 Error, Incomplete Info"
   #define SNPP_OKCLOS  "221 OK, Goodbye"
   #define SNPP_TIMEOUT "421 Timeout, Goodbye"
   #define SNPP_ERRCLOS "421 ERROR, Goodbye"
   #define SNPP_DOWN    "421 SERVER DOWN, Goodbye"

#定義..OK..OK..定義..リセット..リセット..OK..定義..送る..ページ..発信..定義..失敗..定義..失敗..定義..誤り..既に..入る..定義..誤り..不完全..インフォメーション..定義..さよなら..定義..タイムアウト..タイムアウト..さよなら..定義..誤り..さよなら..定義..サーバ..下..さよなら

7. Revision History

7. 改訂履歴

   Originally, when proposed, the author employed POP2 style
   result/response codes.  The Internet community suggested that this
   '+' and '-' style theory be altered to provide numeric response codes
   -- similar to those used in other services such as SMTP.  The
   protocol has been altered to this specification from the first
   proposed draft.

元々、作者は提案されるとPOP2スタイル結果/応答コードを使いました。 インターネットコミュニティは、この'+'と'--'スタイル理論が数値応答コードを提供するために変更されるのを示しました--SMTPなどの他のサービスに使用されるものと同様です。 プロトコルは最初の提案された草稿からこの仕様に変更されました。

   When a bad pager ID message (IXO/TAP administrative failure was
   received from the paging terminal, a 554 series (general failure) was
   returned.  This has been changed to a 550 failure code allowing a
   distinction to be made.

悪いポケットベルIDであるときには通信してください。ページング端末からIXO/TAPの管理故障を受け取りました、(一般的な失敗)が返された554のシリーズ。(区別をするのを許容しながら、これは550失敗コードに変わりました。

8. Relationship to Other IETF Work

8. 他のIETF仕事との関係

   The strategy of this specification, and many of its details, were
   reviewed by an IETF Working Group and three IESG members.  They
   concluded that an approach using the existing email infrastructure
   was preferable, due in large measure to the very high costs of
   deploying a new protocol and the advantages of using the Internet's
   most widely-distributed applications protocol infrastructure.  Most
   reviewers felt that no new protocol was needed at all because the
   special "deliver immediately or fail" requirements of SNPP could be
   accomplished by careful configuration of clients and servers.  The

この仕様の戦略、および詳細の多くがIETF作業部会と3人のIESGメンバーによって再検討されました。 彼らは、既存のメールインフラストラクチャを使用するアプローチが望ましいと結論を下しました、よほど新しいプロトコルを配布する非常に高いコストに当然であり、インターネットの広く最も分配されたアプリケーションを使用する利点はインフラストラクチャについて議定書の中で述べます。 ほとんどの評論家が、新しいプロトコルはクライアントとサーバの慎重な構成で「至急、配送するか、または失敗してください」というSNPPの特別な要件を達成できたので全く必要でなかったと感じました。 The

Gwinn                                                           [Page 6]

RFC 1568                  SNPP - Version 1(b)               January 1994

Gwinn[6ページ]RFC1568SNPP--バージョン1(b)1994年1月

   experimental network printing protocol [3] was identified as an
   example of an existing infrastructure approach to an existing
   problem.  Other reviewers believed that a case could be made for new
   protocol details to identify paging clients and servers to each other
   and negotiate details of the transactions, but that it would be
   sensible to handle those details as extensions to SMTP [1,2] rather
   than deploying a new protocol structure.

実験的なネットワーク印刷プロトコル[3]は既存の問題への既存のインフラストラクチャアプローチに関する例として特定されました。 他の評論家は、新しいプロトコルの詳細のためにページングクライアントとサーバを互いに特定して、弁護がトランザクションの詳細を交渉するのをすることができましたが、新しいプロトコル構造を配布するより拡大としてむしろSMTP[1、2]にそれらの詳細を扱うのは分別があると信じていました。

   The author, while recognizing these positions, believes that there is
   merit in a separate protocol to isolate details of TAP/IXO and its
   evolving successors from users and, indeed, from mail-based
   approaches that might reach systems that would act as SMTP/MIME [4]
   to SNPP gateways.  Such systems and gateways are, indeed, undergoing
   design and development concurrent with this work.  See the section
   "Why not just use Email and SMTP?" for additional discussion of the
   author's view of the classical electronic email approach.

作者は、これらの位置を認識している間、ユーザと、そして、本当に、SMTP/MIME[4]としてSNPPゲートウェイに作動するシステムに達するかもしれないメールベースのアプローチからTAP/IXOの細部と後継者を発展するのを隔離するために別々のプロトコルには長所があると信じています。 本当に、そのようなシステムとゲートウェイはこの仕事による同時発生のデザインと開発を受けています。 作者の古典的な電子メールアプローチの視点の追加議論に関して「なぜただメールとSMTPを使用しませんか?」というセクションを見てください。

9. References

9. 参照

   [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
       USC/Information Sciences Institute, August 1982.

[1] ポステル、J.、「簡単なメール転送プロトコル」、STD10、RFC821、科学が1982年8月に設けるUSC/情報。

   [2] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker,
       "SMTP Service Extensions", United Nations University, Innosoft,
       Dover Beach Consulting, Inc., Network Management Associates,
       Inc., The Branch Office, February 1993.

Klensin(J.)が解放した[2]、Inc.、ネットワークマネージメントに相談する国連大学、Innosoft、ドーヴァーが無能にするN.、ローズ、M.、Stefferud、E.、およびD.クロッカー、「SMTPサービス拡張子」がInc.を関連づけます、支店、1993年2月。

   [3] Rose, M., and C. Malamud, "An Experiment in Remote Printing", RFC
       1486, Dover Beach Consulting, Inc., Internet Multicasting
       Service, July 1993.

[3] Inc.に相談して、RFC1486、ローズ、M.とC.マラマッド、「リモート印刷における実験」ドーヴァーは浜に乗り上げます、インターネット同報通信、1993年7月。

   [4] 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.

[4] Borenstein、N.、およびN.フリード、「パート1をまねてください(マルチパーパスインターネットメールエクステンション)」 「インターネットメッセージ本体の形式を指定して、説明するためのメカニズム」、RFC1521、Bellcore、Innosoft、1993年9月。

Gwinn                                                           [Page 7]

RFC 1568                  SNPP - Version 1(b)               January 1994

Gwinn[7ページ]RFC1568SNPP--バージョン1(b)1994年1月

10.  Security Considerations

10. セキュリティ問題

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

11. Author's Address

11. 作者のアドレス

   R. Allen Gwinn, Jr.
   Associate Director, Computing Services
   Business Information Center
   Southern Methodist University
   Dallas, TX  75275

R.アレンGwinn、Jr.次長コンピューターサービス企業情報はダラス、南部のメソジスト教派の大学テキサス 75275を中心に置きます。

   Phone:  214/768-3186
   EMail:  allen@mail.cox.smu.edu or allen@sulaco.lonestar.org

以下に電話をしてください。 214/768-3186 メールしてください: allen@mail.cox.smu.edu かallen@sulaco.lonestar.org

Gwinn                                                           [Page 8]

Gwinn[8ページ]