RFC1645 日本語訳

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

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

               Simple Network Paging Protocol - Version 2

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

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 for nationwide paging and messaging.  In addition,
   email filters and SNPP client software for Unix and Windows are
   available at no cost.  Please contact the author for more
   information.

このRFCは英数字の、そして、数値の両方のページ(一方向)をラジオページング端末に提供するための簡単な方法を勧めます。 全国的なページングとメッセージングに、このプロトコルをサポートするゲートウェイ、およびSMTPは数カ月使用中です。 さらに、UnixとWindowsのためのメールフィルタとSNPPクライアントソフトウェアは無料で利用可能です。 詳しい情報のために作者に連絡してください。

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

この仕様の以前のバージョンはIESGメンバーと「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 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 and phone lines 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プロトコルの意図は個々のページング端末にページを提供できる規格を提供することです。 最も明白な利益は、モデムと電話回線が英数字のページを生産する必要性の除去と、他の都市か国の端末へのページの配送の加えられた容易さです。 さらに、自動ページ配送はいくらか簡易型であるべきです。

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

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

Gwinn                                                           [Page 1]

RFC 1645                    SNPP - Version 2                   July 1994

Gwinn[1ページ]RFC1645SNPP--バージョン1994年7月2日

   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
   protocol using older style ASCII control characters and a non-
   standard checksumming routine to assist in validating the data.

どこかのあるページング端末。 多くの場合、TAP(また、IXOとして知られているTelocator Alphanumeric入力プロトコル)を使用することでこの配送をします。 このプロトコルはデータを有効にするのを助けるのにより古いスタイルASCII制御文字と非標準のchecksummingルーチンを使用するいくらか複雑で、複雑なプロトコルであるかもしれません。

   Even though TAP is widely used throughout the industry, there are
   plans on the table to move to a more flexible "standard" protocol
   referred to as TME (Telocator Message Entry Protocol).  The level two
   enhancements to SNPP (as described below) are intended for use with
   this forthcoming standard.

TAPは産業中で広く使用されますが、プランがTME(Telocator Message Entryプロトコル)と呼ばれたよりフレキシブルな「標準」のプロトコルに動かすテーブルにあります。 SNPP(以下で説明されるように)へのレベルtwo増進はこの今度の規格がある使用のために意図します。

   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 the base protocol
   attempts to address.  Validation of the paging information is left
   completely up to the paging terminal, making an SNPP gateway a direct
   "shim" between a paging terminal and the Internet.

しかしながら、現在のプロトコル(または、それの不足)の複雑さと柔軟性を承認して、最終的なユーザ機能はかなり簡単です: 原産地からだれかのポケベルまでの1ページを提供するために。 それはベースプロトコルが扱うのを試みる簡単で、リアルタイムの機能です。 ページング情報の合法化は完全にページング端末に任せられます、ページング端末とインターネットの間で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.  This inability to guarantee delivery
   could, whether rightly or wrongly, place the service provider in an
   uncomfortable position with a client who has just received his or her
   emergency page, six hours too late.

ここの明白な違いはページ配送ではなく、あなたのメッセージに影響する問題が即座の通知です。 標準のメールとSMTP、多くの場合、かなり信頼できる間、すべてのノードの間で明確にいつも保証できるというわけではありません、それを非常時望ましくないのも、それほど緊急でないページングにして。 正しいか誤ってであることにかかわらず荷渡しを保証できないこのことはちょうどその人の非常時のページを受けたクライアントと共に不愉快な位置にサービスプロバイダーを置くかもしれません、あまりに6時間遅く。

Gwinn                                                           [Page 2]

RFC 1645                    SNPP - Version 2                   July 1994

Gwinn[2ページ]RFC1645SNPP--バージョン1994年7月2日

   Another advantage of using a separate protocol for paging delivery is
   that it gives the sender absolute flexibility over what is sent to
   the pager.  For instance, in the paging arena, where messages are
   sent to alphanumeric pagers, it is less desirable to send the
   recipient general header lines from a standard SMTP message.  Much of
   the information is useless, possibly redundant, and a waste of
   precious RF bandwidth.

ページング配送に別々のプロトコルを使用する別の利点はポケットベルに送られるものの上に送付者の絶対柔軟性を与えるということです。 例えば、ページングアリーナでは、標準のSMTPメッセージから受取人の一般的なヘッダー系列を送るのはそれほど望ましくはありません。そこでは、メッセージが英数字のポケットベルに送られます。 情報の多くが、役に立たなくて、ことによると余分であって、貴重なRF帯域幅の浪費です。

   Therefore, when implementing an SMTP gateway, the service provider
   should elect to parse out needed information (such as the sender, and
   possibly subject) such to maximize the utility of the transmission.
   Parsing generally means less control over content and format by the
   message originator.  SNPP provides a clean, effective way to send a
   message, as written, to the recipient's pager.

したがって、SMTPゲートウェイを実装するとき、サービスプロバイダーは、トランスミッションに関するユーティリティを最大にするためにそのような出ている必要な情報(送付者としてそのようで、ことによると受けることがある)を分析するのを選ぶべきです。 一般に、構文解析はメッセージ創始者で内容と形式の、より少ないコントロールを意味します。 SNPPは書かれるとして受取人のポケットベルにメッセージを送る清潔で、効果的な方法を提供します。

   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.

もう片方の考慮は手動のtelnetセッションのためのSNPPプロトコル対手動でメール・メッセージをゲートウェイにハックしようとするだれかの相対的な簡単さです。

4. The SNPP Protocol

4. SNPPプロトコル

   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 several input commands (the first 4 characters of each are
   significant) that solicit various server responses falling into four
   categories:

SNPPプロトコルは、コマンドと回答の系列であり、現在使用中の他の多くのインターネットプロトコルの哲学に基づいています。 SNPPには、4つのカテゴリになる様々なサーバ応答に請求するいくつかの入力コマンド(それぞれの最初の4つのキャラクタが重要である)があります:

    2xx - Successful, continue
    3xx - Begin DATA input (see "DATA" command)
    4xx - Failed with connection terminated
    5xx - Failed, but continue session

2xx--うまくいきます、3xxを続けてください--失敗されたDATA入力(「データ」コマンドを見る)4xx(接続の終えられた5xxによると、失敗される)を始めなさい、ただし、セッションを続けてください。

   The first character of every server response code is a digit
   indicating the category of response.  The text portion of the
   response following the code may be altered to suit individual
   applications.

あらゆるサーバ応答コードの最初のキャラクタは応答のカテゴリを示すケタです。 コードに従う応答のテキスト部分は、個々のアプリケーションに合うように変更されるかもしれません。

   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 "220" level message
   (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 paging
   terminal, gathers a response, and reports the success or failure to
   the client.

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

Gwinn                                                           [Page 3]

RFC 1645                    SNPP - Version 2                   July 1994

Gwinn[3ページ]RFC1645SNPP--バージョン1994年7月2日

4.1 Examples of SNPP Transactions

4.1 SNPPトランザクションに関する例

   The following illustrate examples of client-server communication
   using SNPP.

以下は、SNPPを使用することでクライアント/サーバコミュニケーションに関する例を例証します。

4.1.1 A Typical Level One Connection

4.1.1 典型的な平らな1つの接続

            Client                         Server

クライアントサーバ

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

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

4.1.2 A Typical Level Two, Multiple Transaction

4.1.2 典型的なレベルTwo、複数のトランザクション

   The following example illustrates a single message sent to two
   pagers.  Using this level protocol, pager-specific options may be
   selected for each receiver by specifying the option prior to issuing
   the "PAGEr" command.  In this example, an alternate coverage area is
   selected for the first pager, while delayed messaging is specified
   for the second.

以下の例は2つのポケットベルに送られたただ一つのメッセージを例証します。 この平らなプロトコルを使用して、ポケットベル特有のオプションは、各受信機のために「ポケットベル」コマンドを発行する前にオプションを指定することによって、選択されるかもしれません。 この例では、代替の適用範囲の地域は最初のポケットベルのために選択されます、遅れたメッセージングが2番目に指定されますが。

            Client                         Server

クライアントサーバ

    Open Connection               -->
                                  <--  220 SNPP Server Ready
    COVE 2                        -->
                                  <--  250 Alternate Area Selected
    PAGE 5551212 FOOBAR           -->
                                  <--  250 Pager ID Accepted
    HOLD 9401152300 -0600         -->
                                  <--  250 Delayed Message OK
    PAGE 5552323 XYZZY            -->
                                  <--  250 Pager ID Accepted
    SUBJ Seattle Meeting          -->
                                  <--  250 Message Subject OK
    DATA                          -->
                                  <--  354 Begin Input, End With '.'
    Please meet me tomorrow at    -->
    the Seattle office            -->
                                  <--  250 DATA Accepted

オープンな接続--><--220 SNPPのサーバの持ち合わせの入り江2--><--250 代替の領域選択されたページ5551212FOOBAR--><--250 Pager IDは5552323XYZZYを保持9401152300 -0600--><--遅れた250メッセージOKページ受け入れました--><; '250ポケットベルID Accepted SUBJシアトルMeeting--><--250Message Subject OK DATA--><--354Begin Input、'.'Pleaseが会うEnd With、私、明日、--、>、シアトルオフィス--><--250DATA Accepted

Gwinn                                                           [Page 4]

RFC 1645                    SNPP - Version 2                   July 1994

Gwinn[4ページ]RFC1645SNPP--バージョン1994年7月2日

    SEND                          -->
                                  <--  250 Message Sent OK
    QUIT                          -->
                                  <--  221 OK, Goodbye

送られたOKがやめた250メッセージ--><--さようならを221OK、送ってください(><)。

4.2 Level 1 Commands

4.2 レベル1は命令します。

   Level one commands are designed as a minimum implementation of the
   protocol.  This collection of commands may be used with either
   TAP/IXO or TME for message delivery to the paging terminal.

レベル1 コマンドはプロトコルの最小の実装として設計されています。 コマンドのこの収集はメッセージ配送にTAP/IXOかTMEのどちらかと共にページング端末まで使用されるかもしれません。

4.2.1 PAGEr <Pager ID>

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

   The PAGEr command submits a pager ID (PID) number, for inclusion in
   the next messaging transaction.  The PID used must reside in, and be
   validated by the paging terminal.  Limited validation may optionally
   be done on the server (such as all numeric, and ID length), or
   validation can be left up to the terminal at the time the page is
   sent.

PAGErコマンドは次のメッセージングトランザクションでの包含のポケットベルID(PID)番号を提出します。 使用されるPIDは存して、ページング端末で有効にしなければなりません。 サーバ(すべての数値や、IDの長さなどの)で任意に株式会社合法化をするかもしれませんか、またはページを送るとき、端末に合法化を任せることができます。

   When implementing SNPP, the user may elect to support multiple
   recipients per message sent.  However, be wary that validation-
   prior-to-sending is not possible with TAP/IXO (and is not an official
   option of the current TME specification).  What this means is that in
   order to validate a PID, one must generate a message to the pager.
   The terminal responds favorably or negatively.  When reporting
   failure of a single PID in a sequence, delineating and reporting the
   failure in a "standard format" may prove to be a challenge.

SNPPを実装するとき、ユーザは、1送られたメッセージあたりの複数の受取人をサポートするのを選ぶかもしれません。 しかしながら、用心深くいてください、その合法化、先の発信、TAP/IXO(現在のTME仕様が公式のオプションがない)では、可能ではありません。 これが意味することはPIDを有効にするためにポケットベルにメッセージを生成しなければならないということです。 端末は好意的か否定的に応じます。 次々に独身のPIDの失敗を報告するとき、「標準書式」での失敗を図で表わして、報告するのは挑戦であると判明するかもしれません。

   Possible responses from the SNPP server, with suggested text, in
   response to a PAGEr command are:

PAGErコマンドに対応した提案されたテキストがあるSNPPサーバからの可能な応答は以下の通りです。

    250 Pager ID Accepted
    421 Too Many Errors, Goodbye (terminate connection)
    421 Gateway Service Unavailable (terminate connection)
    550 Error, Invalid Pager ID
    554 Error, failed (technical reason)

250 421Too Many Errors(Goodbye(接続を終える)421ゲートウェイService Unavailable(接続を終える)550Error、Invalid Pager ID554Error)が失敗したポケットベルID Accepted(技術的な理由)

   The level 2 enhancements affect the PAGEr command.  Please refer to
   the appropriate section for details.

平らな2増進はPAGErコマンドに影響します。 詳細について相当区を参照してください。

4.2.2 MESSage <Alpha or Numeric Message>

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

   The MESSage command specifies a single-line message, 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 paging terminal.  Duplicating the MESSage command before
   SENDing the message should produce an "503 ERROR, Message Already

MESSageコマンドは単線メッセージをゲートウェイに指定します。 SNPPサーバ(長さなどの)でメッセージの株式会社合法化をするかもしれませんが、ページング端末はメッセージのタイプ合法化をするべきです。 SENDingの前にMESSageコマンドをコピーして、メッセージが出されるべきである、「503誤り、メッセージ、既に」

Gwinn                                                           [Page 5]

RFC 1645                    SNPP - Version 2                   July 1994

Gwinn[5ページ]RFC1645SNPP--バージョン1994年7月2日

   Entered" message, and allow the user to continue.

「入られ」て、通信してください、そして、ユーザを続けさせてください。

   Possible responses from the SNPP server, with suggested text, in
   response to a MESSage command are:

MESSageコマンドに対応した提案されたテキストがあるSNPPサーバからの可能な応答は以下の通りです。

    250 Message OK
    421 Too Many Errors, Goodbye (terminate connection)
    421 Gateway Service Unavailable (terminate connection)
    503 ERROR, Message Already Entered
    550 ERROR, Invalid Message
    554 Error, failed (technical reason)

250 メッセージOK421Too Many Errors、Goodbye(接続を終える)421ゲートウェイService Unavailable(接続を終える)503ERROR、Message Already Entered550ERROR(Invalid Message554Error)は失敗しました。(技術的な理由)

4.2.3 RESEt

4.2.3 リセット

   The RESEt command clears already entered information from the server
   session, resetting it to the state of a freshly opened connection.
   This is provided, primarily, as a means to reset accidentally entered
   information during a manual session.

RESEtコマンドはサーバセッションから既に入力された情報をクリアします、新たに開かれた接続の状態にそれをリセットして。 手動のセッションの間に偶然入力された情報をリセットする手段として主としてこれを提供します。

   Possible responses from the SNPP server, with suggested text, in
   response to a RESEt command are:

RESEtコマンドに対応した提案されたテキストがあるSNPPサーバからの可能な応答は以下の通りです。

    250 RESET OK
    421 Too Many Errors, Goodbye (terminate connection
    421 Gateway Service Unavailable (terminate connection)

250RESET OK421Too Many Errors、Goodbye、(接続421ゲートウェイService Unavailableを終えてください。(接続を終えます)

4.2.4 SEND

4.2.4 発信してください。

   The SEND command finalizes the current message transaction, and
   processes the page to the paging terminal.  Prior to processing, the
   PAGEr and MESSage fields (or message DATA when using the level two
   option) 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 that the information is complete, the SNPP server should
   format and send the page to the paging terminal, and await a
   response.

SENDコマンドは、現在のメッセージトランザクションを成立させて、ページング端末にページを処理します。 処理の前に、PAGErとMESSage分野(平らな2オプションを使用するときにはDATAを通信させる)は情報の存在がないかどうかチェックされるべきです。 これらの必須項目の1つがなくなるなら、サーバは、「503誤り、不完全情報」について応答して、ユーザが続くのを許容するべきです。 情報が完全であると仮定する場合、SNPPサーバは、ページング端末にページをフォーマットして、送って、応答を待つべきです。

   Possible responses from the SNPP server, with suggested text, in
   response to a SEND command are:

SENDコマンドに対応した提案されたテキストがあるSNPPサーバからの可能な応答は以下の通りです。

    250 Message Sent Successfully
    421 Too Many Errors, Goodbye (terminate connection)
    421 Gateway Service Unavailable (terminate connection)
    503 Error, Pager ID or Message Incomplete
    554 Message Failed [non-administrative reason]

250 メッセージSent Successfully421Too Many Errors、503Error、Goodbye(接続を終える)421ゲートウェイService Unavailable(接続を終える)Pager IDまたはMessage Incomplete554Message Failed[非管理の理由]

Gwinn                                                           [Page 6]

RFC 1645                    SNPP - Version 2                   July 1994

Gwinn[6ページ]RFC1645SNPP--バージョン1994年7月2日

   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 submit another transaction.

SENDコマンドを処理した後に、サーバはクライアントが別のトランザクションを提出するのを許容するためにオンラインのままで残るべきです。

4.2.5 QUIT

4.2.5 やめてください。

   The QUIT command terminates the current session.  The server should
   simply respond:

QUITコマンドは現在のセッションを終えます。 サーバは単に反応するべきです:

    221 OK, Goodbye"

「221 OK、さようなら」

   and close the connection.

そして、接続を終えてください。

4.2.6 HELP (optional)

4.2.6 ヘルプ(任意)です。

   The optional HELP command 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" series message is issued.

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

   Possible responses from the SNPP server, with suggested text, in
   response to a HELP command are:

HELPコマンドに対応した提案されたテキストがあるSNPPサーバからの可能な応答は以下の通りです。

    214 [Help Text]  (repeated for each line of information)
    250 End of Help Information
    421 Too Many Errors, Goodbye (terminate connection)
    421 Gateway Service Unavailable (terminate connection)
    500 Command Not Implemented

情報421ヘルプToo Many Errorsの214[Textを助けます](情報の各系列のために、繰り返される)250End、Goodbye(接続を終える)421ゲートウェイService Unavailable(接続を終える)500Command Not Implemented

4.3 Level 2 - Minimum Extensions

4.3レベル2--最小の拡大

   This section specifies minimum enhancements to the SNPP protocol for
   added functionality.

このセクションは付記された機能性としてSNPPプロトコルに最小の増進を指定します。

4.3.1 DATA

4.3.1 データ

   The DATA command is an alternate form of the MESSage command,
   allowing for multiple line delivery of a message to the paging
   terminal.  This command's function is similar to the DATA command
   implemented in SMTP (Internet STD10, RFC821).  The SNPP server should
   only allow one DATA or MESSage command to be issued prior to a SEND.

DATAコマンドはMESSageコマンドの代替のフォームです、メッセージの複数の系列配送をページング端末まで考慮して。 このコマンドの機能はSMTP(インターネットSTD10、RFC821)で実装されたDATAコマンドと同様です。 SNPPサーバはSENDの前で発行されるべきコマンドを1DATAかMESSageにしか許容するべきではありません。

Gwinn                                                           [Page 7]

RFC 1645                    SNPP - Version 2                   July 1994

Gwinn[7ページ]RFC1645SNPP--バージョン1994年7月2日

   Possible responses from the SNPP server, with suggested text, in
   response to a DATA command are:

DATAコマンドに対応した提案されたテキストがあるSNPPサーバからの可能な応答は以下の通りです。

    354 Begin Input; End with <CRLF>'.'<CRLF>
    421 Too Many Errors, Goodbye (terminate connection)
    421 Gateway Service Unavailable (terminate connection)
    503 ERROR, Message Already Entered
    500 Command Not Implemented
    550 ERROR, failed (administrative reason)
    554 ERROR, failed (technical reason)

354 入力を始めてください。 '<CRLF>で、終わってください'。'<CRLF>421Too Many Errors、Goodbye(接続を終える)421ゲートウェイService Unavailable(接続を終える)503ERROR、Message Already Entered500Command Not Implemented550ERROR(失敗した(管理理由)554ERROR)は失敗しました'(技術的な理由)

   Upon receiving a "354" response, the client begins line input of the
   message to send to the pager.  A single period ("."), in the first
   position of the line, terminates input.  After input, the server may
   respond:

「354」応答を受けると、クライアントはポケットベルに発信するメッセージの系列入力を始めます。 ただ一つの期間、(「」、)、系列の第1ポジションでは、入力を終えます。 入力された後に、サーバは反応するかもしれません:

    250 Message OK
    421 Too Many Errors, Goodbye (terminate connection)
    421 Gateway Service Unavailable (terminate connection)
    550 ERROR, Invalid Message (or administrative reason)
    554 ERROR, Failed (technical reason)

250 メッセージOK421Too Many Errors、Goodbye(接続を終える)421ゲートウェイService Unavailable(接続を終える)550ERROR、Invalid Message(または、管理理由)554ERROR、Failed(技術的な理由)

4.4 Level 2 - Optional Extensions

4.4レベル2--任意の拡大

   This section discusses enhancements to the SNPP protocol for more
   control over paging functions.  These are primarily designed to
   mirror the added functionality built into the Telocator Message Entry
   (TME) protocol as specified in the TDP protocol suite. These
   functions may, optionally (as is being done by the author), be
   integrated into a paging terminal.  There is no requirement to
   implement all of these functions.  Requests for invalid functions
   should return a "500 Function Not Implemented" error.

このセクションはページング機能の、より多くのコントロールのためにSNPPプロトコルに増進について論じます。 これらは、付記されたTDPプロトコル群の指定されるとしてのTelocator Message Entry(TME)プロトコルが組み込まれた機能性を反映するように主として設計されています。 これらの機能は任意に(作者によって行われるように)ページング端末と統合されるかもしれません。 これらの機能のすべてを実装するという要件が全くありません。 無効の機能を求める要求は「実装されなかった500機能」誤りを返すべきです。

   It is important to note that, at the time of this publication, the
   TME standard is still not finalized.

TME規格がこの公表時点でまだ成立させられていないことに注意するのは重要です。

4.4.1 LOGIn <loginid> [password]

4.4.1 ログイン<loginid>。[パスワード]

   This command allows for a session login ID to be specified.  It is
   used to validate the person attempting to access the paging terminal.
   If no LOGIn command is issued, "anonymous" user status is assumed.

このコマンドは、セッションログインのためにIDが指定されるのを許容します。 それは、ページング端末にアクセスするのを試みる人を有効にするのに使用されます。 LOGInコマンドを全く発行しないなら、「匿名」の使用者の地位に就きます。

   Possible responses from the SNPP server, with suggested text, in
   response to a LOGIn command are:

LOGInコマンドに対応した提案されたテキストがあるSNPPサーバからの可能な応答は以下の通りです。

    250 Login Accepted
    421 Too Many Errors, Goodbye (terminate connection)
    421 Gateway Service Unavailable (terminate connection)

250 ログインAccepted421Too Many Errors、Goodbye(接続を終える)421ゲートウェイService Unavailable(接続を終えます)

Gwinn                                                           [Page 8]

RFC 1645                    SNPP - Version 2                   July 1994

Gwinn[8ページ]RFC1645SNPP--バージョン1994年7月2日

    421 Illegal Access Attempt
    550 Error, Invalid LoginID or Password
    554 Error, failed (technical reason)

421 不法なAccess Attempt550Error(Invalid LoginIDかPassword554Error)は失敗しました。(技術的な理由)

4.4.2 PAGEr <PagerID> [Password/PIN]

4.4.2 ポケットベル<PagerID>。[パスワード/暗証番号]

   This PAGEr command is an enhancement to the level one specification.
   The primary difference is the ability to specify a password or PIN
   for validation or feature access.

このPAGErコマンドは平らな1つの仕様への増進です。 プライマリ違いは合法化か特徴アクセサリーのためのパスワードか暗証番号を指定する能力です。

   Before proceeding, it is important to understand the logical function
   of the PAGEr command with respect to the LEVEl, COVErage, HOLDtime,
   and ALERt commands (option parameters as described below).  Each time
   a PAGEr command is issued, it should be thought of as the last step
   in a multiple step transaction.

進行の前に、LEVEl、COVErage、HOLDtime、およびALERtコマンド(以下で説明されるオプションパラメタ)に関してPAGErコマンドの論理関数を理解しているのは重要です。 PAGErコマンドが発行される各回、それは最後のステップとして複数のステップトランザクションで考えられるべきです。

   When the PAGEr command is processed, the pager ID (and password) is
   submitted to the paging terminal with LEVEl, COVErage, HOLDtime, and
   ALERt.  If these parameters have not been altered, then their
   defaults are assumed for the transaction.  After the next PAGEr
   command has been processed, these option parameters are reset their
   defaults.  Using this type of "option-option- option-go" scheme, it
   is possible to specify a different priority level for "Jeff," and an
   alternate coverage area for "Kathy," while sending the same message
   to each.

PAGErコマンドを処理するとき、LEVEl、COVErage、HOLDtime、およびALERtと共にポケットベルID(そして、パスワード)をページング端末に提出します。 これらのパラメタが変更されていないなら、それらのデフォルトはトランザクションのために想定されます。 処理されたPAGErが、命令する次、これらのオプションパラメタがそうであるのになった後に、それらのデフォルトをリセットしてください。 このタイプの「オプションオプションオプション許可する」体系を使用して、「ジェフ」に異なった優先順位を指定して、「キャシー」のために代替の適用範囲の地域を指定するのは同じメッセージをそれぞれに送る間、可能です。

   Possible responses from the SNPP server, with suggested text, in
   response to a PAGEr command are:

PAGErコマンドに対応した提案されたテキストがあるSNPPサーバからの可能な応答は以下の通りです。

    250 Pager ID Accepted
    421 Too Many Errors, Goodbye (terminate connection)
    421 Gateway Service Unavailable (terminate connection)
    550 Error, Invalid Pager ID or Password
    554 Error, failed (technical reason)

250 421Too Many Errors、550Error、Goodbye(接続を終える)421ゲートウェイService Unavailable(接続を終える)Invalid Pager IDまたはPassword554Errorが失敗したポケットベルID Accepted(技術的な理由)

4.4.3 LEVEl <ServiceLevel>

4.4.3 レベル<ServiceLevel>。

   The LEVEl function is used to specify an optional alternate level of
   service for the next PAGEr command.  Ideally, "ServiceLevel" should
   be an integer between 0 and 11 inclusive.  The TME protocol specifies
   ServiceLevel as follows:

LEVEl機能は、次のPAGErコマンドのための任意の代替のレベルのサービスを指定するのに使用されます。 理想的に、"ServiceLevel"は0と11の間で包括的な整数であるべきです。 TMEプロトコルは以下のServiceLevelを指定します:

    0 - Priority
    1 - Normal (default)
    2 - Five minutes
    3 - Fifteen minutes
    4 - One hour
    5 - Four hours

0--優先権1--標準(デフォルト)の2--5分4--1つの一時間の3--15分5--4時間

Gwinn                                                           [Page 9]

RFC 1645                    SNPP - Version 2                   July 1994

Gwinn[9ページ]RFC1645SNPP--バージョン1994年7月2日

    6 - Twelve hours
    7 - Twenty Four hours
    8 - Carrier specific '1'
    9 - Carrier specific '2'
   10 - Carrier specific '3'
   11 - Carrier specific '4'

6--12時間7--20Four時間8--キャリヤー特定の'1'9--キャリヤー特定の'2'10--キャリヤー特定の'3'11--キャリヤー特定の'4'

   The choice on how to implement this feature, or to what level it
   should be implemented, should be optional and up to the discretion of
   the carrier.

どのようにこの特徴を実装するべきであるか、そして、またはそれがどんなレベルに実装されるべきであるかに関する選択は、キャリヤーの裁量に任意であって、上がっているべきです。

   Possible responses from the SNPP server, with suggested text, in
   response to a LEVEl command are:

LEVElコマンドに対応した提案されたテキストがあるSNPPサーバからの可能な応答は以下の通りです。

    250 OK, Alternate Service Level Accepted
    421 Too Many Errors, Goodbye (terminate connection)
    421 Gateway Service Unavailable (terminate connection)
    500 Command Not Implemented
    550 Error, Invalid Service Level Specified
    554 Error, failed (technical reason)

250 OK、Alternate Service Level Accepted421Too Many Errors、Goodbye(接続を終えます)421ゲートウェイService Unavailable(接続を終える)500Command Not Implemented550Error(Invalid Service Level Specified554Error)は失敗しました。(技術的な理由)

4.4.4 ALERt <AlertOverride>

4.4.4 <AlertOverride>を警告してください。

   The optional ALERt command may be used to override the default
   setting and specify whether or not to alert the subscriber upon
   receipt of a message.  This option, like the previous command, alters
   the parameters submitted to the paging terminal using the PAGEr
   command.  The TME protocol specifies AlertOverride as either 0-
   DoNotAlert, or 1-Alert.

任意のALERtコマンドは、メッセージを受け取り次第既定の設定をくつがえして、加入者を警告するかどうか指定するのに使用されるかもしれません。 前のコマンドのように、このオプションはPAGErコマンドを使用することでページング端末に提出されたパラメタを変更します。 TMEプロトコルは0DoNotAlertか1警戒のどちらかとしてAlertOverrideを指定します。

   Possible responses from the SNPP server, with suggested text, in
   response to a ALERt command are:

ALERtコマンドに対応した提案されたテキストがあるSNPPサーバからの可能な応答は以下の通りです。

    250 OK, Alert Override Accepted
    421 Too Many Errors, Goodbye (terminate connection)
    421 Gateway Service Unavailable (terminate connection)
    500 Command Not Implemented
    550 Error, Invalid Alert Parameter
    554 Error, failed (technical reason)

250 OK、Alert Override Accepted421Too Many Errors、Goodbye(接続を終えます)421ゲートウェイService Unavailable(接続を終える)500Command Not Implemented550Error(Invalid Alert Parameter554Error)は失敗しました。(技術的な理由)

4.4.5 COVErage <AlternateArea>

4.4.5 適用範囲<AlternateArea>。

   The optional COVErage command is used to override the subscriber's
   default coverage area, and allow for the selection of an alternate
   region.  This option, like the previous command, alters the
   parameters submitted to the paging terminal using the PAGEr command.
   AlternateArea is a designator for one of the following:

任意のCOVErageコマンドは、加入者のデフォルト適用範囲の地域をくつがえして、代替の領域の選択を考慮するのに使用されます。 前のコマンドのように、このオプションはPAGErコマンドを使用することでページング端末に提出されたパラメタを変更します。 AlternateAreaは以下の1つの指示子です:

Gwinn                                                          [Page 10]

RFC 1645                    SNPP - Version 2                   July 1994

Gwinn[10ページ]RFC1645SNPP--バージョン1994年7月2日

    - A subscriber-specific alternate coverage area
    - A carrier-defined region available to subscribers

- 加入者特有の代替の適用範囲の地域--加入者にとって、利用可能なキャリヤー規定領域

   As an example, Mary Ghoti is a subscriber having local service in
   Chicago, Illinois (Mary's region '1').  Her account has been set up
   in such a manner as to allow Mary's pager to be paged nationwide upon
   demand (Mary's region '2').  Specifying "COVErage 2" prior to issuing
   the appropriate "PAGEr" command allows the default Chicago area to be
   overridden, and Mary's pager to be messaged nationally for that
   transaction.  It is assumed that the carrier providing Mary's service
   will keep track of how many pages have been sent to her pager in this
   manner, and will bill her accordingly.

例として、メアリGhotiはシカゴ(イリノイ)(メアリの領域'1')にローカル・サービスを持っている加入者です。 メアリのポケットベルが全国的に要求に応じて(メアリの領域'2')呼び出されるのを許容するほど彼女のアカウントはそのような方法でセットアップされました。 「そのトランザクションのために全国的に通信するためにコマンドがくつがえされるのをデフォルトシカゴの地域を許容する適切な「ポケットベル」、およびメアリのポケットベルを支給する適用範囲2インチ前」のときに、指定します。 メアリのサービスがいくつのページ動向をおさえるかなら、キャリヤーがこの様に彼女のポケットベルに送られて、それに従って、彼女に請求すると思われます。

   Possible responses from the SNPP server, with suggested text, in
   response to a COVErage command are:

COVErageコマンドに対応した提案されたテキストがあるSNPPサーバからの可能な応答は以下の通りです。

    250 Alternate Coverage Selected
    421 Too Many Errors, Goodbye (terminate connection)
    421 Gateway Service Unavailable (terminate connection)
    500 Command Not Implemented
    550 Error, Invalid Alternate Region
    554 Error, failed (technical reason)

250 421Too Many Errors(Goodbye(接続を終えます)421ゲートウェイService Unavailable(接続を終える)500Command Not Implemented550Error、Invalid Alternate Region554Error)が失敗した代替のCoverage Selected(技術的な理由)

4.4.6 HOLDuntil <YYMMDDHHMMSS> [+/-GMTdifference]

4.4.6 HOLDuntil<YYMMDDHHMMSS>。[+/-GMTdifference]

   The HOLDuntil command allows for the delayed delivery of a message,
   to a particular subscriber, until after the time specified.  The time
   may be specified in local time (e.g. local to the paging terminal),
   or with an added parameter specifying offset from GMT (in other
   words, "-0600" specifies Eastern Standard Time).  This option, like
   the previous command, alters the parameters submitted to the paging
   terminal using the PAGEr command.

時間が指定した後までHOLDuntilコマンドは特定の加入者にとってメッセージの遅延分娩を考慮します。 時間が現地時間(例えば、ページング端末へのローカル)に指定されたかもしれないか、または付記されたパラメタで、指定がグリニッジ標準時から相殺された、(言い換えれば、「-0600」が指定する、米国東部標準時、) 前のコマンドのように、このオプションはPAGErコマンドを使用することでページング端末に提出されたパラメタを変更します。

   Possible responses from the SNPP server, with suggested text, in
   response to a HOLDuntil command are:

HOLDuntilコマンドに対応した提案されたテキストがあるSNPPサーバからの可能な応答は以下の通りです。

    250 Delayed Messaging Selected
    421 Too Many Errors, Goodbye (terminate connection)
    421 Gateway Service Unavailable (terminate connection)
    500 Command Not Implemented
    550 Error, Invalid Delivery Date/Time
    554 Error, failed (technical reason)

250はMessaging Selected421Too Many Errorsを遅らせました、550Error(Invalid Delivery Date/時間554Error)が失敗したGoodbye(接続を終える)421ゲートウェイService Unavailable(接続を終える)500Command Not Implemented(技術的な理由)

4.4.7 CALLerid <CallerID>

4.4.7 CALLerid<CallerID>。

   The CALLerid function is a message-oriented function (as opposed to
   the subscriber-oriented functions just described).  This allows for
   the specification of the CallerIdentifier function as described in

CALLerid機能はメッセージ指向の機能(ただ説明された加入者指向の機能と対照的に)です。 これは中で説明されるようにCallerIdentifier機能の仕様を考慮します。

Gwinn                                                          [Page 11]

RFC 1645                    SNPP - Version 2                   July 1994

Gwinn[11ページ]RFC1645SNPP--バージョン1994年7月2日

   TME.  This parameter is optional, and is at the discretion of the
   carrier as to how it should be implemented or used.

TME。 このパラメタは、任意であり、それが実装されるべきであるか、またはどう使用されるべきであるかに関してキャリヤーの裁量にはあります。

   Possible responses from the SNPP server, with suggested text, in
   response to a CALLerid command are:

CALLeridコマンドに対応した提案されたテキストがあるSNPPサーバからの可能な応答は以下の通りです。

    250 Caller ID Accepted
    421 Too Many Errors, Goodbye (terminate connection)
    421 Gateway Service Unavailable (terminate connection)
    500 Command Not Implemented
    550 Error, Invalid Caller ID
    554 Error, failed (technical reason)

250 421Too Many Errors(Goodbye(接続を終えます)421ゲートウェイService Unavailable(接続を終える)500Command Not Implemented550Error、Invalid Caller ID554Error)が失敗した発信番号表示Accepted(技術的な理由)

4.4.8 SUBJect <MessageSubject>

4.4.8 対象の<MessageSubject>。

   The SUBJect function allows is a message-oriented function that
   allows the sender to specify a subject for the next message to be
   sent.  This parameter is optional and is at the discretion of the
   carrier as to how it should be implemented or used.

機能が許容するSUBJectは送付者が次の送られるべきメッセージに対象を指定できるメッセージ指向の機能です。 このパラメタは、任意であり、それが実装されるべきであるか、またはどう使用されるべきであるかに関してキャリヤーの裁量にはあります。

   Possible responses from the SNPP server, with suggested text, in
   response to a SUBJect command are:

SUBJectコマンドに対応した提案されたテキストがあるSNPPサーバからの可能な応答は以下の通りです。

    250 Message Subject Accepted
    421 Too Many Errors, Goodbye (terminate connection)
    421 Gateway Service Unavailable (terminate connection)
    500 Command Not Implemented
    550 Error, Invalid Subject Option
    554 Error, failed (technical reason)

250 421Too Many Errors(Goodbye(接続を終えます)421ゲートウェイService Unavailable(接続を終える)500Command Not Implemented550Error、Invalid Subject Option554Error)が失敗したメッセージSubject Accepted(技術的な理由)

4.5 Illegal Commands

4.5 不法なコマンド

   Should the client issue an illegal command, the server may respond in
   one of the two following ways:

クライアントが不法入国者を発行するなら、命令してください、そして、サーバは2つの次の方法の1つで反応してもよいです:

    421 Too Many Errors, Goodbye (terminate connection)
    500 Command Not Implemented, Try Again

421、もMany Errors、Goodbye(接続を終える)500Command Not Implemented、Try Again

   The number of illegal commands allowed before terminating the
   connection should be at the discretion of the operator of the SNPP
   server.  The only response that has not been discussed is:

SNPPサーバのオペレータの裁量には接続を終える前に許容された不正コマンドの数がそうあるべきです。議論していない唯一の応答は以下の通りです。

    421 SERVER DOWN, Goodbye

421サーバ下である、さようなら

   This is used to refuse or terminate connections when the gateway is
   administratively down, or when there is some other technical or
   administrative problem with the paging terminal.

これは、ゲートウェイが行政上下がっているか、またはページング端末に関するある他の技術的であるか管理の問題があるとき、接続を拒否するか、または終えるのに使用されます。

Gwinn                                                          [Page 12]

RFC 1645                    SNPP - Version 2                   July 1994

Gwinn[12ページ]RFC1645SNPP--バージョン1994年7月2日

4.6 Timeouts

4.6 タイムアウト

   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タイムアウト、さようなら」を反応させて、接続を終えます。

4.7 Rigidity of Command Structure

4.7 命令系統の剛性

   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 to suit
   the tastes of the operator of the SNPP server. It is suggested that
   the response codes mirror SMTP response codes as closely as possible.

クライアントからサーバまでのコマンドは一定のままで残るべきです。 しかしながら、応答の最初のキャラクタが成否を示すので、SNPPサーバのオペレータの味に合うようにサーバ応答のテキストを変更できました。応答ができるだけ密接に鏡のSMTP応答コードをコード化することが提案されます。

5. Revision History

5. 改訂履歴

   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などの他のサービスに使用されるものと同様です。 プロトコルは最初の提案された草稿からこの仕様に変更されました。

   Administrative errors (Illegal Pager ID, for example) have been
   separated from technical errors (out-of-space on disk, for example).
   Administrative failures are generally preceded with a 550 series
   response, while technical failures bear a 554 series code.

技術的な誤り(例えば、ディスクの上のスペースのアウト)と管理誤り(例えば、不法なPager ID)を切り離してあります。 管理失敗は550シリーズ応答で一般に先行されていますが、技術的な失敗は554のシリーズにコードを示します。

   Level two enhancements to the protocol have been added in preparation
   for TME deployment.

レベルtwo プロトコルへの増進はTME展開に備えて加えられます。

   Error code "502 Command not implemented" was changed to a general
   "500 Command not recognized" failure result to closer follow SMTP.

SMTPが、より近くで続くように、「502Commandは実装しなかった」エラーコードが「Commandが認識しなかった500」一般的な失敗結果に変わりました。

6. Relationship to Other IETF Work

6. 他の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
   experimental network printing protocol [4] 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

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

Gwinn                                                          [Page 13]

RFC 1645                    SNPP - Version 2                   July 1994

Gwinn[13ページ]RFC1645SNPP--バージョン1994年7月2日

   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.

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

7. References

7. 参照

   [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, RFC 1425, February 1993.

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

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

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

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

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

Gwinn                                                          [Page 14]

RFC 1645                    SNPP - Version 2                   July 1994

Gwinn[14ページ]RFC1645SNPP--バージョン1994年7月2日

8.  Security Considerations

8. セキュリティ問題

   Security issues are not discussed in this memo.

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

9. Author's Address

9. 作者のアドレス

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

Gwinn[15ページ]