RFC1861 日本語訳
1861 Simple Network Paging Protocol - Version 3 -Two-Way Enhanced. A.Gwinn. October 1995. (Format: TXT=49181 bytes) (Obsoletes RFC1645) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group A. Gwinn Request for Comments: 1861 Southern Methodist University Obsoletes: 1645 October 1995 Category: Informational
Gwinnがコメントのために要求するワーキンググループA.をネットワークでつないでください: 1861年の南部のメソジスト教派の大学は以下を時代遅れにします。 1645 1995年10月のカテゴリ: 情報
Simple Network Paging Protocol - Version 3 - Two-Way Enhanced
ツーウェイが高めた簡単なネットワークページングプロトコル(バージョン3)
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 wireless messages, both one and two-way, to appropriate receiving devices. In its simplest form, SNPP provides a simple way to implement a "shim" between the Internet and a TAP/IXO paging terminal. In its level 3 form, it provides an easy-to-use (and build) method for communicating and receiving end-to-end acknowledgments and replies from two-way messaging devices (such as ReFLEX units).
このRFCは無線電信、1と適切な受信へのツーウェイの両方にデバイスを提供するための簡単な方法を勧めます。 最も簡単なフォームに、SNPPはインターネットとTAP/IXOページング端末の間の「詰め物」を実装する簡単な方法を提供します。 レベル3では、形成してください、とそれは両用メッセージングデバイス(ReFLEXユニットなどの)から交信、終わるために終わりを得承認、および回答のための使用しやすい(建ててください)メソッドを前提とします。
Gateways supporting this protocol, as well as SMTP, have been in use for well over a year at several commercial paging companies, and private businesses. Client software supporting this protocol has become widespread, and is being integrated into many of the new paging and messaging products being built. In addition to commercial software, email filters and SNPP client software for Unix and Windows (WikiPage) are available at no cost. Please contact the author for more information.
いくつかの商業ページング会社の1年間の井戸、および私用に、このプロトコルをサポートするゲートウェイ、およびSMTPは使用中です。 このプロトコルをサポートするクライアントソフトウェアが、広範囲になって、新しいページングの多くと統合されて、造られる製品を通信させています。 商用ソフトウェアに加えて、UnixとWindows(WikiPage)のためのメールフィルタと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. 序論
With all due apologies to the Glenayre engineers (who take offense at the term "nerd") 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. The benefits of the Internet
Glenayre技術者(「おたく」という用語のときに腹を立てます)へのすべての当然の謝罪で、ポケベルはコンピュータnerdomのX端末と同じくらい多くの部分です--残念ながら、恐らくより多くです。 Simple Network Pagingプロトコルの意図は個々のページング端末にページを提供できる規格を提供することです。 最も明白な利益は、モデムと電話回線が英数字のページを生産する必要性の除去と、他の都市か国の端末へのページの配送の加えられた容易さです。 インターネットの利益
Gwinn Informational [Page 1] RFC 1861 SNPP - Version 3 October 1995
Gwinnの情報[1ページ]のRFC1861SNPP--バージョン1995年10月3日
become even more realized when growing towards acknowledgment-based messaging such as ReFLEX paging--where it may be impossible to accurately predict costs associated with telco services such as 1-800 numbers.
ReFLEXページングなどの承認ベースのメッセージングに向かって成長するとき、さらに実感さえされるようになってください--正確にフリーダイヤルなどの通信業者サービスに関連しているコストを予測するのが不可能であるかもしれないところで。
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 protocol using older style ASCII control characters and a non- standard checksumming routine to assist in validating the data.
ラジオページングはページング製品の広い有用性と広い使用でいくらか当然のことと思われます。 しかしながら、使用される(特により広い領域ページングで)ページ、およびプロセスの実際の配送はそうです。いくらか複雑です。 ユーザが結局1ページを開始するとき、電話の上で番号にダイヤルするか、またはある入力装置を通して英数字のページに入ることによって、どこかのあるページング端末にページを提供しなければなりません。 多くの場合、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増進はこの今度の規格がある使用のために意図します。
The recently-added level three enhancements have been engineered for use, specifically, with acknowledgment-based paging. With the recent advances in wireless technology, two-way paging is fast approaching reality--therefore creating a need for a workable end-to-end acknowledged protocol. Two-way messaging, however, opens up several new areas of unpredictability. The most pronounced is the subscriber response time. Although deliveries from host to subscriber, and subsequent receipt-acknowledgments happen in a rather predictable manner, it is impossible to know when the subscriber will physically pull the unit out, read the message and respond to it. Therefore, it could well be cost prohibitive to conduct such transactions online using a phone line as medium--especially an 800-number. This makes the Internet an extremely attractive alternative because of its (generally) usage insensitive nature.
使用のために承認ベースのページングで最近加えられたレベルthree増進を明確に設計してあります。 無線技術における最近の進歩で、したがって、終わりから終わりへの実行可能な承認されたプロトコルの必要性を作成して、両用ページングは速く現実にアプローチしています。 しかしながら、通信するツーウェイは予測不可能性のいくつかの新しい領域を開けます。 最も著しいのは、加入者応答時間です。 配送はかなり予測できる方法でホストから加入者の、そして、その後の領収書承認まで起こりますが、加入者がいつ物理的にユニットを引き抜いて、メッセージを読み込んで、それに応じるかを知るのは不可能です。 したがって、それはたぶん中くらいの同じくらい電話回線を使用することでオンラインでそのようなトランザクションを行うためにひどく高い費用でしょう--特に800数。 これは(一般に)用法の神経の鈍い本質のためにインターネットを非常に魅力的な代替手段にします。
However, acknowledging the complexity of task, 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.
しかしながら、タスクの複雑さ、および現在のプロトコルの柔軟性(または、それの不足)を承認して、最終的なユーザ機能はかなり簡単です: 原産地からだれかのポケベルまでの1ページを提供するために。 それはベースプロトコルが扱うのを試みる簡単で、リアルタイムの機能です。
Gwinn Informational [Page 2] RFC 1861 SNPP - Version 3 October 1995
Gwinnの情報[2ページ]のRFC1861SNPP--バージョン1995年10月3日
3. Why not just use Email and SMTP for paging?
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時間遅く。
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プロトコル対手動でメール・メッセージをゲートウェイにハックしようとするだれかの相対的な簡単さです。
Gwinn Informational [Page 3] RFC 1861 SNPP - Version 3 October 1995
Gwinnの情報[3ページ]のRFC1861SNPP--バージョン1995年10月3日
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 the following categories:
SNPPプロトコルは、コマンドと回答の系列であり、現在使用中の他の多くのインターネットプロトコルの哲学に基づいています。 SNPPには、以下のカテゴリになる様々なサーバ応答に請求するいくつかの入力コマンド(それぞれの最初の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によると、失敗される)を始めなさい、ただし、セッションを続けてください。
SNPP version 3 (two-way) adds the following categories:
SNPPバージョン3(ツーウェイ)は以下のカテゴリを加えます:
7xx - UNsuccessful two-way specific transaction, but continue
session
8xx - Successful two-way specific transaction, continue
9xx - Successful QUEUED two-way transaction, continue
7xx--セッション8xxを続けているのを除いたUNsuccessfulの両用特定のトランザクション、うまくいっている両用特定のトランザクション、続行、9xx--うまくいっているQUEUED両用トランザクション、続行
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, especially at SNPP level one, 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.
特にSNPPレベル1では、セッション相互作用は実際にかなり簡単です(したがって、名前)。 クライアントは聴取サーバとの関係を開始します。接続を開くとき、サーバは「220」平らなメッセージを発行します(サーバがSNPPコマンドを受け入れる意欲を示して)。 クライアントは、ポケットベルID情報、およびメッセージを通過して、次に、「発信」コマンドを発行します。 サーバは、クライアントに次に、ページング端末に情報を提供して、応答を集めて、成否を報告します。
4.1 Examples of "simple" SNPP Transactions
4.1 「簡単な」SNPPトランザクションに関する例
The following illustrate examples of client-server communication using SNPP.
以下は、SNPPを使用することでクライアント/サーバコミュニケーションに関する例を例証します。
Gwinn Informational [Page 4] RFC 1861 SNPP - Version 3 October 1995
Gwinnの情報[4ページ]のRFC1861SNPP--バージョン1995年10月3日
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
SEND -->
<-- 250 Message Sent OK
QUIT -->
<-- 221 OK, Goodbye
オープンな接続--><--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 SEND--><--250Message Sent OK QUIT--><--221が承認する>、Goodbye
Gwinn Informational [Page 5] RFC 1861 SNPP - Version 3 October 1995
Gwinnの情報[5ページ]のRFC1861SNPP--バージョン1995年10月3日
4.1.3 A Typical Level Three (two-way) Transaction
4.1.3 典型的な平らな3(ツーウェイ)トランザクション
Level three transactions are inherently single-unit oriented because of the one-to-one issues surrounding responses. Each transaction begins with the "2WAY" command and terminates with a "SEND" command.
レベルthree 本来トランザクションは応答を囲む1〜1冊による指向の1セットです。 各トランザクションは、"2WAY"コマンドで始まって、「発信」コマンドで終わります。
Client Server
クライアントサーバ
Open Connection -->
<-- 220 SNPP (V3) Gateway Ready
2WAY -->
<-- 250 Two-Way Mode Enabled
NOQUEUE -->
<-- 250 Msg will either be Sent or Rejected
PAGER SHIRLEY -->
<-- 850 Unit online; Don't call me Shirley!
ACKRead 1 -->
<-- 250 Read Acknowledgment Requested
DATA -->
<-- 354 Begin Input, End With '.'
Little Bo Binary has lost -->
her Sparcstation and doesn't -->
know where to find it. Have -->
you seen it recently? -->
<-- 250 DATA Accepted
RTYPE MULTICHOICE -->
<-- 250 Multichoice Responses Enabled
MCRESP 01 In the West Pasture -->
<-- 250 MCR Code Accepted
MCRESP 02 GoldiFLOCKs has it -->
<-- 250 MCR Code Accepted
MCRESP 03 Haven't a clue -->
<-- 250 MCR Code Accepted
MCRESP 04 Haven't a life -->
<-- 250 MCR Code Accepted
MCRESP 05 Oh, GO AWAY! -->
<-- 250 MCR Code Accepted
SEND -->
<-- 860 00321 1234 Message Delivered
QUIT -->
<-- 221 OK, Goodbye
開いているConnection--><--220 SNPP(V3)ゲートウェイReady 2WAY--><--250 Two-道のMode Enabled NOQUEUE--><--250 エムエスジーはSentになるだろうか、Rejected PAGERシャーリー(><)はオンライン850Unitです。 私をシャーリーと呼ばないでください! そして、'ACKRead1--><--250Read Acknowledgment Requested DATA--><--354Begin Input、'.'リトルボーBinaryがなくしたEnd With-->、彼女のSparcstation、-->は、どこでそれを見つけるかを知っています。 --、>、あなた、最近、それを見ますか? --><--、250DATA Accepted RTYPE MULTICHOICE--><--250Multichoice Responses Enabled MCRESP01Inの西Pasture--><--250MCR Code Accepted MCRESP02GoldiFLOCKsには、それ--><--寿命ではなく、手がかり(><)250MCR Code Accepted MCRESP04ヘヴン--><--250MCR Code Accepted MCRESP05ではなく、250MCR Code Accepted MCRESP03ヘヴンがおお、GO AWAY!がいます。 --><--コードが受け入れた250MCRはやめられて、00321 1234メッセージが提供した860--><--さようならを221OK、送ります(><)。
4.2 General Response Code Theory
4.2 一般反応コード理論
Before discussing specific SNPP transactions, it may be helpful to discuss some of the response codes. As mentioned previously, every response from the SNPP server to the client contains a 3 digit code that categorizes the response. Several of these codes fall into the
特定のSNPPトランザクションについて議論する前に、応答コードのいくつかについて議論するのは役立っているかもしれません。 既述のとおり、あらゆるSNPPサーバからクライアントまでの応答が応答を分類する3ケタコードを含んでいます。 これらのいくつかのコードが下がります。
Gwinn Informational [Page 6] RFC 1861 SNPP - Version 3 October 1995
Gwinnの情報[6ページ]のRFC1861SNPP--バージョン1995年10月3日
"general" category, and may occur more frequently throughout a given SNPP transaction. There are some lesser used (somewhat transaction specific) responses that will be discussed in conjunction with the format of a specific command.
「一般的な」カテゴリ、与えられたSNPPトランザクション中により頻繁に起こるかもしれません。 特定のコマンドの形式に関連して議論するいくつかの、より少ない中古(トランザクションいくらか特有の)の応答があります。
4.2.1 Code 214 - Multi-line "help/info" message
4.2.1 コード214--マルチ系列「助け/インフォメーション」メッセージ
This code prefixes a line of response information (such as in response to the HELP command). It should be terminated with a "250 OK" message. This code is used when the response will take more than one line to display.
このコードは応答情報(HELPコマンドに対応したなど)の系列を前に置きます。 それは「250OK」メッセージで終えられるべきです。 応答が表示するために1つ以上の系列を取るとき、このコードは使用されています。
4.2.2 Code 218 - Single-line "help/info" message
4.2.2 コード218--「助け/インフォメーション」メッセージをSingle裏打ちしてください。
This code prefixes a single line of response information (such as the request for a single database entry). Unlike the 214 series, it has no "250" series terminator.
このコードは応答情報(単一のデータベースエントリーを求める要求などの)の単線を前に置きます。 214のシリーズと異なって、それは「250」シリーズターミネータを全く持っていません。
4.2.3 Code 250 - Successful Transaction
4.2.3 250--うまくいっているトランザクションをコード化してください。
This code is a general positive acknowledgment from the server indicating that a command was successfully processed. Additionally, code 250 can appear at the end of the response to a HELP command (214 series commands--discussed below).
このコードはコマンドが首尾よく処理されたのを示すサーバからの一般的な肯定応答です。 さらに、コード250はHELPコマンドへの応答の終わりに現れることができます(214のシリーズが命令します--以下では、議論します)。
4.2.4 Code 421 - Fatal Error, Connection Terminated
4.2.4 421をコード化してください--致命的な誤り、接続は終わりました。
This code is displayed just prior to the SNPP server terminating a connection with a client for errors. Such a connection termination may occur at any time and for any reason (administrative or technical).
クライアントとの接続を終えるSNPPサーバのすぐ前に誤りによってこのコードを表示します。 そのような接続終了はいつでもであることにおいてどんな理由のでも(管理的か技術的)で起こるかもしれません。
4.2.5 Code 500 - Command Not Implemented
4.2.5 コード500--実装されないで、命令してください。
This code is a "fail but continue code" that appears when an illegal command is entered.
このコードは不正コマンドが入れられるとき現れる「失敗しますが、コードを続けてください」です。
4.2.6 Code 503 - Duplicate Command Entry; Already Entered That
4.2.6 コード503--コマンド入力をコピーしてください。 既に、それに入りました。
This code indicates that the specified information has already been entered. This code would appear, for instance, if the client attempted to enter a MESSage command after specifying a "DATA" sequence.
このコードは、指定された情報が既に入力されたのを示します。 例えば、クライアントが、「データ」系列を指定した後にMESSageコマンドを入力するのを試みるなら、このコードは現れるでしょうに。
4.2.7 Codes 550 and 554 - Transaction Failed, but Continue
4.2.7 コード550と554--続くのを除いて、失敗されたトランザクション
These codes indicate a failed command, but the session is allowed to continue. A 550 code should be used to indicate a more
これらのコードは失敗したコマンドを示しますが、セッションは続くことができます。 A550コードは、aをもう少し示すのに使用されるべきです。
Gwinn Informational [Page 7] RFC 1861 SNPP - Version 3 October 1995
Gwinnの情報[7ページ]のRFC1861SNPP--バージョン1995年10月3日
"administrative" failure (such as an invalid pager ID, or illegal parameter), while a 554 series indicates a more technical reason (such as a gateway down or equipment failure). In addition to the specified failure codes, additional 550 and 554 failures may be specified as necessary to allow for greater flexibility.
554のシリーズが、より技術的な理由(下にゲートウェイか設備故障などの)を示す間の「管理」の失敗(無効のポケットベルID、または不法なパラメタなどの)。 指定された失敗コードに加えて、追加550と554の失敗が、より大きい柔軟性を考慮するために必要に応じて指定されるかもしれません。
4.2.8 Code 552 - Maximum Entries Exceeded
4.2.8 超えられていた552--最大のエントリーをコード化してください。
This code is in response to the entry of the "n+1" item when the server only permits "n" items in a category. As an example, the client would expect to see this message when trying to enter the 6th PAGEr command when the terminal only supported 5.
サーバがカテゴリで「n」項目しか可能にしないとき、このコードは「n+1」項目のエントリーに対応しています。 例として、クライアントは、端末が5しかサポートしなかったとき、6番目のPAGErコマンドを入力しようとするとき、このメッセージを見ると予想するでしょう。
4.3 Level 1 Commands
4.3 レベル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.3.1 PAGEr <Pager ID>
4.3.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(技術的な理由)
Both level 2 and level 3 enhancements affect the PAGEr command. Please refer to the appropriate section(s) for details.
レベル3 レベル2と増進の両方がPAGErコマンドに影響します。 詳細について相当区を参照してください。
Gwinn Informational [Page 8] RFC 1861 SNPP - Version 3 October 1995
Gwinnの情報[8ページ]のRFC1861SNPP--バージョン1995年10月3日
4.3.2 MESSage <Alpha or Numeric Message>
4.3.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 Entered" message, and allow the user to continue.
MESSageコマンドは単線メッセージをゲートウェイに指定します。 SNPPサーバ(長さなどの)でメッセージの株式会社合法化をするかもしれませんが、ページング端末はメッセージのタイプ合法化をするべきです。 SENDingの前にMESSageコマンドをコピーして、メッセージは、「503誤り、既に入力されたメッセージ」メッセージを出して、ユーザが続くのを許容するべきです。
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.3.3 RESEt
4.3.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.3.4 SEND
4.3.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サーバからの可能な応答は以下の通りです。
Gwinn Informational [Page 9] RFC 1861 SNPP - Version 3 October 1995
Gwinnの情報[9ページ]のRFC1861SNPP--バージョン1995年10月3日
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[非管理の理由]
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コマンドを処理した後に、サーバはクライアントが別のトランザクションを提出するのを許容するためにオンラインのままで残るべきです。
Level 3 enhancements to this command allow for other responses. Please refer to the appropriate section for discussion.
レベル3 このコマンドへの増進は他の応答を考慮します。 議論について相当区を参照してください。
4.3.5 QUIT
4.3.5 やめてください。
The QUIT command terminates the current session. The server should simply respond:
QUITコマンドは現在のセッションを終えます。 サーバは単に反応するべきです:
221 OK, Goodbye"
「221 OK、さようなら」
and close the connection.
そして、接続を終えてください。
4.3.6 HELP (optional)
4.3.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.4 Level 2 - Minimum Extensions
4.4レベル2--最小の拡大
This section specifies minimum enhancements to the SNPP protocol for added functionality.
このセクションは付記された機能性としてSNPPプロトコルに最小の増進を指定します。
Gwinn Informational [Page 10] RFC 1861 SNPP - Version 3 October 1995
Gwinnの情報[10ページ]のRFC1861SNPP--バージョン1995年10月3日
4.4.1 DATA
4.4.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にしか許容するべきではありません。
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.5 Level 2 - Optional Extensions
4.5レベル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.5.1 LOGIn <loginid> [password]
4.5.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.
このコマンドは、セッションログインのためにIDが指定されるのを許容します。 それは、ページング端末にアクセスするのを試みる人を有効にするのに使用されます。
Gwinn Informational [Page 11] RFC 1861 SNPP - Version 3 October 1995
Gwinnの情報[11ページ]のRFC1861SNPP--バージョン1995年10月3日
If no LOGIn command is issued, "anonymous" user status is assumed.
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)
421 Illegal Access Attempt
550 Error, Invalid LoginID or Password
554 Error, failed (technical reason)
250 421Too Many Errors、Goodbye(接続を終えます)421ゲートウェイService Unavailable(接続を終える)421Illegal Access Attempt550Error、Invalid LoginIDまたはPassword554Errorが失敗したログインAccepted(技術的な理由)
4.5.2 PAGEr <PagerID> [Password/PIN]
4.5.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
552 Max Recipients Exceeded
554 Error, failed (technical reason)
250 421Too Many Errors(Goodbye(接続を終える)421ゲートウェイService Unavailable(接続を終える)550Error、Invalid Pager IDかPassword552マックスRecipients Exceeded554Error)が失敗したポケットベルID Accepted(技術的な理由)
4.5.3 LEVEl <ServiceLevel>
4.5.3 レベル<ServiceLevel>。
The LEVEl function is used to specify an optional alternate level of service for the next PAGEr command. Ideally, "ServiceLevel" should
LEVEl機能は、次のPAGErコマンドのための任意の代替のレベルのサービスを指定するのに使用されます。 理想的に、"ServiceLevel"はそうするべきです。
Gwinn Informational [Page 12] RFC 1861 SNPP - Version 3 October 1995
Gwinnの情報[12ページ]のRFC1861SNPP--バージョン1995年10月3日
be an integer between 0 and 11 inclusive. The TME protocol specifies ServiceLevel as follows:
0と11の間で包括的な整数になってください。 TMEプロトコルは以下のServiceLevelを指定します:
0 - Priority
1 - Normal (default)
2 - Five minutes
3 - Fifteen minutes
4 - One hour
5 - Four hours
6 - Twelve hours
7 - Twenty Four hours
8 - Carrier specific '1'
9 - Carrier specific '2'
10 - Carrier specific '3'
11 - Carrier specific '4'
0 - Priority 1 - Normal (default) 2 - Five minutes 3 - Fifteen minutes 4 - One hour 5 - Four hours 6 - Twelve hours 7 - Twenty Four hours 8 - Carrier specific '1' 9 - Carrier specific '2' 10 - Carrier specific '3' 11 - Carrier specific '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.5.4 ALERt <AlertOverride>
4.5.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)は失敗しました。(技術的な理由)
Gwinn Informational [Page 13] RFC 1861 SNPP - Version 3 October 1995
Gwinnの情報[13ページ]のRFC1861SNPP--バージョン1995年10月3日
4.5.5 COVErage <AlternateArea>
4.5.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つの指示子です:
- 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.5.6 HOLDuntil <YYMMDDHHMMSS> [+/-GMTdifference]
4.5.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
250はMessaging Selected421Too Many Errorsを遅らせました、Goodbye(接続を終える)421ゲートウェイService Unavailable(接続を終える)500Command Not Implemented
Gwinn Informational [Page 14] RFC 1861 SNPP - Version 3 October 1995
Gwinnの情報[14ページ]のRFC1861SNPP--バージョン1995年10月3日
550 Error, Invalid Delivery Date/Time
554 Error, failed (technical reason)
550 誤り(Invalid Delivery Date/時間554Error)は失敗しました。(技術的な理由)
4.5.7 CALLerid <CallerID>
4.5.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 TME. This parameter is optional, and is at the discretion of the carrier as to how it should be implemented or used.
CALLerid機能はメッセージ指向の機能(ただ説明された加入者指向の機能と対照的に)です。 これはTMEで説明されるようにCallerIdentifier機能の仕様を考慮します。 このパラメタは、任意であり、それが実装されるべきであるか、またはどう使用されるべきであるかに関してキャリヤーの裁量にはあります。
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.5.8 SUBJect <MessageSubject>
4.5.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.6 Level 3 - Two-Way Extensions
4.6レベル3--両用拡大
This section specifies enhancements to the SNPP protocol to support acknowledgment-based paging (2-way). One of the more powerful features of ReFLEX-style paging, in addition to confirmed message delivery, is the ability to "seed" a message with multiple-choice type responses. After the recipient views the message, she can reply with one of the seeded messages. In addition to the multiple-choice responses (MCR's), the sender may elect to receive confirmation when the message is first viewed by the recipient.
このセクションは、承認ベースのページング(2ウェイ)をサポートするためにSNPPプロトコルに増進を指定します。 確認されたメッセージ配送に加えたReFLEX-スタイルページングの、より強力な特徴の1つは多項選択式のタイプ応答でメッセージに「種を蒔く」能力です。 受取人がメッセージを見た後に、彼女は種を蒔かれたメッセージの1つで返答できます。 多項選択式の応答(MCRのもの)に加えて、送付者は、メッセージが最初に受取人によって見られるとき、確認を受け取るのを選ぶかもしれません。
Gwinn Informational [Page 15] RFC 1861 SNPP - Version 3 October 1995
Gwinnの情報[15ページ]のRFC1861SNPP--バージョン1995年10月3日
4.6.1 2WAY
4.6.1 2 ずっと
The 2WAY command prefaces each two-way transaction (see previous example). This places the server in the mode to receive and process a single 2-way transaction. The server returns to "non-2WAY" mode upon the completion of a SEND command or a RESEt command. In 2WAY mode, it is, however, possible to do multiple MSTAtus commands (to check responses from field message units). Possible responses are:
2WAYコマンドはそれぞれの両用トランザクションについて前書きします(前の例を見てください)。 これは、ただ一つの2ウェイトランザクションを受けて、処理するためにサーバをモードに置きます。 サーバはSENDコマンドかRESEtコマンドの完成の「非2WAY」モードに戻ります。 しかしながら、2WAYモードで、複数のMSTAtusコマンド(分野メッセージ単位から応答をチェックする)をするのは可能です。 可能な応答は以下の通りです。
250 OK, Beginning 2-Way Transaction
550 Error, Standard Transaction Already Underway, use RESEt
421 Gateway Service Unavailable (terminate connection)
500 Command Not Implemented
554 Error, failed (technical reason)
250 OK(Beginning Transaction550Error(Standard Transaction Already Underway)がRESEt421ゲートウェイService Unavailable(接続を終える)500Command Not Implementedを使用する2方法554Error)は失敗しました。(技術的な理由)
4.6.2 PING <PagerID | Alias>
4.6.2 ピング<PagerID| アリア>。
This command localizes (finds) the field message unit on the system and returns its location and/or status. Because of the sensitive nature of location information, the subscriber may elect to have a generic "pager located" message (ACLU mode) rather than to return her actual location. Possible responses are:
このコマンドは、システムの上で分野メッセージ単位をローカライズして(見つけます)、位置、そして/または、状態を返します。 位置情報の敏感な本質のために、加入者は、彼女の実際の場所を返すというよりむしろ「ポケットベルは場所を見つけた」ジェネリックに(ACLUモード)を通信させるのを選ぶかもしれません。 可能な応答は以下の通りです。
820 <Locus_Code> Unit On System, This Area
821 Unit On System, No Location Information Available (ACLU mode)
750 Unit Valid But Not Online At This Time
920 Unit Not Online, But Can Queue Message for Later Delivery
550 Can't PING; Unit NOT 2-way capable
550 Unknown or Illegal ID
421 Gateway Service Unavailable (terminate connection)
500 Command Not Implemented
554 Error, failed (technical reason)
820 <場所_Code>Unit On System、This Area821Unit On System、いいえ、Location情報Available(ACLUモード)750Unit Valid But Not Online At This Time920Unit Not Online、PINGではなく、Later Delivery550CanのためのBut Can Queue Message。 2ウェイできる550UnknownかIllegal ID421ゲートウェイService Unavailable(接続を終える)500Command Not Implemented554Errorではなく、ユニットであって、失敗されています。(技術的な理由)
4.6.3 EXPTag <hours>
4.6.3 EXPTag<何時間もの>。
Changes the default expiry time for a queued message delivery. If the message is not delivered in the specified number of hours, then it is deleted and the MSTAtus tag is updated to reflect the inability to deliver (code 760). Possible responses are:
列に並ばせられたメッセージ配送のためのデフォルト満期時間を変えます。 何時間もの指定された数でメッセージを提供しないなら、それを削除します、そして、配送できないこと(コード760)を反映するためにMSTAtusタグをアップデートします。 可能な応答は以下の通りです。
250 Message Expiry Time Changed to 'nnn' Hours
550 Cannot Change Expiry Time
421 Gateway Service Unavailable (terminate connection)
500 Command Not Implemented
554 Error, failed (technical reason)
250 'nnn'Hours550Cannot Change Expiry Time421ゲートウェイService Unavailable(接続を終える)500Command Not Implementedに554Errorであって、失敗したメッセージExpiry Time Changed(技術的な理由)
Gwinn Informational [Page 16] RFC 1861 SNPP - Version 3 October 1995
Gwinnの情報[16ページ]のRFC1861SNPP--バージョン1995年10月3日
4.6.4 NOQUEUEing
4.6.4 NOQUEUEing
Specifies that the server should not allow message queuing for this 2WAY transaction. In this mode, if a pager is not online, the client will receive a "750" series response to a PAGEr command. This command must be specified prior to a PAGEr command. Possible responses are:
サーバがこの2WAYトランザクションのためのメッセージ待ち行列を許容するべきでないと指定します。 このモードで、ポケットベルがオンラインでないなら、クライアントはポケットベルコマンドへの「750」シリーズ応答を受けるでしょう。 PAGErコマンドの前にこのコマンドを指定しなければなりません。 可能な応答は以下の通りです。
250 Queuing Disabled, This Transaction
550 Can't Disable Queueing
421 Gateway Service Unavailable (terminate connection)
500 Command Not Implemented
554 Error, failed (technical reason)
250 列を作りDisabled(Disable Queueing421ゲートウェイService Unavailable(接続を終えます)500Command Not Implemented554Errorではなく、This Transaction550Can)は失敗しました。(技術的な理由)
4.6.5 ACKRead <0|1>
4.6.5 ACKRead<0|1 >。
Activates or deactivates message "read" acknowledgment. When activated, instructs the field message unit to return a message when the subscriber actually views the received message. This feature is independent of the actual reply. Possible responses are:
承認が「読まれた」メッセージを動かすか、または非活性化します。 実際に、受信されたメッセージを見ますいつが、動かして、加入者であるときに、分野メッセージ単位がメッセージを返すよう命令する。 この特徴は実際の回答から独立しています。 可能な応答は以下の通りです。
250 Read Acknowledgment <Enabled|Disabled>
550 Cannot modify Read Acknowledgment
421 Gateway Service Unavailable (terminate connection)
500 Command Not Implemented
554 Error, failed (technical reason)
250は<が可能にした承認を読みます。|失敗されて、障害がある>550CannotはRead Acknowledgment421ゲートウェイService Unavailable(接続を終える)500Command Not Implemented554Errorを変更します。(技術的な理由)
4.6.6 RTYPe <Reply_Type_Code>
4.6.6 _RTYPe<回答_タイプコード>。
Changes the type of reply expected from the field message unit that is acceptable to the client program. Initial appropriate reply type codes are:
回答のタイプが許容できる分野メッセージ単位からクライアントプログラムまで予想した変化。 初期の適切な回答タイプコードは以下の通りです。
NONE - (default) No Reply Permitted
YESNO - Seeds a simple "Yes" or "No reply
SIMREPLY - Only pre-coded replies from providers's reply base
MULTICHOICE - Allows full multiple choice replies
TEXT - Allows full text replies (generated by field unit)
NONE((デフォルト)Reply Permitted YESNOがない)は簡単な「はい」に種を蒔くか、または「どんな回答SIMREPLY(プロバイダーsの回答ベースMULTICHOICEからのあらかじめコード化された回答だけ)も完全な選択式回答にTEXTを許容しません--全文回答を許します」。(分野単位で、生成されます)
Possible responses to an RTYPe command are:
RTYPeコマンドへの可能な応答は以下の通りです。
250 Reply Type Accepted
550 Illegal Reply Type
503 Already Entered That
421 Gateway Service Unavailable (terminate connection)
500 Command Not Implemented
554 Error, failed (technical reason)
250回答Type Accepted550Illegal Reply Type503Already Entered That421ゲートウェイService Unavailable(接続を終える)500Command Not Implemented554Errorであって、失敗されています。(技術的な理由)
Gwinn Informational [Page 17] RFC 1861 SNPP - Version 3 October 1995
Gwinnの情報[17ページ]のRFC1861SNPP--バージョン1995年10月3日
4.6.7 MCREsponse <2-byte_Code> Response_Text
4.6.7 MCREsponseの<の2バイトの_コード>応答_テキスト
This command is issued prior the the SEND command, and "seeds" the transaction with an acceptable multiple choice response. Each response is specific to the current message. The number of acceptable responses may be limited by the SNPP server as desired by the provider. Examples of MCREsponse(s) are:
このコマンドは、優先的に発行されて、SENDが命令するということであり、許容できる選択式応答でトランザクションに「種を蒔きます」。 それぞれの応答は現在のメッセージに特定です。 許容できる応答の数はプロバイダーによって望まれているようにSNPPサーバによって制限されるかもしれません。 MCREsponse(s)に関する例は以下の通りです。
MCREsponse 1E2C Here is one response
MCREsponse 0002 This is another response
MCREsponse1E2C Hereによる1つの応答のMCREsponse0002Thisが別の応答であるということです。
Responses from the SNPP server to the client are:
SNPPサーバからクライアントまでの応答は以下の通りです。
250 Response Added to Transaction
502 Error! Would Duplicate Previously Entered MCResponse
550 Invalid MCResponse Code
550 MCResponses Not Enabled
552 Too Many MCResponses Entered
421 Gateway Service Unavailable (terminate connection)
500 Command Not Implemented
554 Error, failed (technical reason)
250 トランザクション502誤りに加えられた応答! Duplicate Previously Entered MCResponse550Invalid MCResponse Code550MCResponses Not Enabled552Too Many MCResponses Entered421ゲートウェイService Unavailable(接続を終えます)500Command Not Implemented554Errorであって、失敗にされるだろう(技術的な理由)
4.6.8 PAGEr
4.6.8 ポケットベル
In 2WAY mode, the following enhanced responses are available:
2WAYモードで、以下の高められた応答は利用可能です:
850 Two-Way Unit Online and Available; Transaction Accepted
950 Unit NOT Online; Message Will be Queued for Later Delivery
750 Two-Way Unit NOT Online; Transaction Denied
550 Error, Pager Not 2WAY Capable
550 Error, RTYPe Mode Invalid for This Unit
503 Already Selected PAGEr
421 Gateway Service Unavailable (terminate connection)
554 Error, failed (technical reason)
オンラインの、そして、利用可能な両用850個のユニット。 トランザクションは、950個のユニットがオンラインでないと受け入れました。 Later Delivery750のためのQueuedがTwo-道のUnit NOT Onlineであったならウィルを通信させてください。 Denied550Error(Pager Not 2WAY Capable550Error、This Unit503Already Selected PAGEr421ゲートウェイService Unavailable(接続を終える)554ErrorのためのRTYPe Mode Invalid)が失敗したトランザクション(技術的な理由)
4.6.9 SEND
4.6.9 発信してください。
Instructs the SNPP server to "launch" the message (plus attached response codes) to the field message unit. A successful SEND command will return, to the client, a "Message_Tag" number and a "Pass_Code" for periodic status checking. The client then uses the MSTAtus command to check the progression of the transaction. The "Message_Tag" functions as a "record locator," while the "Pass_Code" should be a randomly generated "PIN" code to authorize checking of the "Message_Tag."
メッセージ(そのうえ、応答コードを付ける)を分野メッセージ単位に「始める」ようSNPPサーバに命令します。 うまくいっているSENDコマンドは周期的な状態の照合のために「メッセージ_タグ」番号と「パス_コード」をクライアントに返すでしょう。 そして、クライアントはトランザクションの進行をチェックするMSTAtusコマンドを使用します。 「メッセージ_タグ」は「記録的なロケータ」として機能します、「パス_コード」は「メッセージ_タグ」をチェックするのを認可する手当たりしだいに発生している「暗証番号」コードであるべきですが。
Response codes to a SEND command, as well as the MSTAtus command, indicate the degree of "finality" to the transaction. Based on the
SENDコマンド、およびMSTAtusコマンドへの応答コードは「最終的な状態」の度合いをトランザクションに示します。 based on
Gwinn Informational [Page 18] RFC 1861 SNPP - Version 3 October 1995
Gwinnの情報[18ページ]のRFC1861SNPP--バージョン1995年10月3日
delivery process, there are four categories. Together with their response code prefixes, these are:
配送は処理されて、4つのカテゴリがあります。 それらの応答コード接頭語と共に、これらは以下の通りです。
86x - Initial message delivered, awaiting requested action(s)
87x - Intermediate processing completed, awaiting closure
88x - Transaction concluded (final)
96x - Queued transaction
These prefixes make a multi-tiered transaction relatively simple to
follow to closure. When an 88x series response code is received from
the server, all requested portions of the transaction have been
processed, and no further status changes will take place.
86x--初期のメッセージは配送されました、要求された動作87xを待って--トランザクションが(最終的)の96xを結論づけたという列に並ばせられたトランザクションThese接頭語が比較的閉鎖に続くのが簡単であるマルチtieredされたトランザクションをする閉鎖88xを待って、終了する中間的処理。 88xシリーズ応答コードがサーバから受け取られているとき、すべてが、トランザクションの部分を処理してあるよう要求しました、そして、一層の状態変化は全く起こらないでしょう。
The SEND command should reply with the first tier of message processing. Following this, the status of the message in the system is checked, periodically, using the MSTAtus command.
SENDコマンドはメッセージ処理の最初の層で返答するべきです。 これに続いて、システムのメッセージの状態は、MSTAtusコマンドを使用することで定期的にチェックされます。
Possible responses to a SEND command are:
SENDコマンドへの可能な応答は以下の通りです。
860 <Message_Tag> <Pass_Code> Delivered, Awaiting Read Ack
861 <Message_Tag> <Pass_Code> Delivered, Awaiting Reply (MCR)
860 <メッセージ_タグ><パス_コード>は配送されて、回答をお待ちしていて、Ack861<メッセージ_タグ><パス_コード>が読まれた待ちは配送されました。(MCR)
880 <Message_Tag> <Pass_Code> Message Delivered
880<メッセージ_タグ><パス_コード>メッセージは配送されました。
960 <Message_Tag> <Pass_Code> OK, Message QUEUED for Delivery
960 <パス_コード>が承認する<メッセージ_タグ>、配送のために列に並ばせられたメッセージ
550 Delivery Failed! Message destroyed.
421 Gateway Service Unavailable (terminate connection)
500 Command Not Implemented
554 Error, failed (technical reason)
550 配送は失敗しました! 無効にされたメッセージ。 421ゲートウェイService Unavailable(接続を終える)500Command Not Implemented554Errorであって、失敗されています。(技術的な理由)
4.6.10 MSTAtus <Message_Tag> <Pass_Code>
4.6.10 MSTAtus<メッセージ_タグ><パス_コード>。
This is used by a client program to periodically check the status of delivery and response of a given message. The SEND command returns the "Message_Tag" and "Pass_Code" required to check the status. A "Message_Tag" may be (should be) expired by the SNPP server after an appropriate amount of time has passed. Expiration of these tags is vendor dependent, and may accelerate after the first check after final disposition of the message (such as after a client program has successfully received the field unit's response code).
これは、定期的に配送の状態と与えられたメッセージの応答をチェックするのにクライアントプログラムで使用されます。 SENDコマンドは「メッセージ_タグ」を返します、そして、「パス_コード」が状態をチェックするのが必要です。 適切な時間が経過した後に「メッセージ_タグ」はSNPPサーバによって吐き出されるかもしれません(あるべきです)。 これらのタグの満了は、ベンダーに依存していて、メッセージの最終的な気質の後の最初のチェックの後に加速するかもしれません(クライアントプログラムなどの後のように、分野単位の応答コードは首尾よく受信していました)。
The tag record contains a "Sequence" number which is an incremental counter that rises as the record's status changes (such as from a delivery acknowledgment to a reply). In addition, date and time of the current transaction should be kept in the following format:
タグ記録は記録の状態が変化するのに従って(配送承認などから回答まで)上昇する増加のカウンタである「系列」番号を含んでいます。 さらに、経常取引の日時は以下の形式で保たれるべきです:
YYMMDDHHMMSS+GMT (example: 950925143501+7)
YYMMDDHHMMSS+グリニッジ標準時です。(例: 950925143501 +7)
Gwinn Informational [Page 19] RFC 1861 SNPP - Version 3 October 1995
Gwinnの情報[19ページ]のRFC1861SNPP--バージョン1995年10月3日
Because of the tiered structure of replies, possible responses to an MSTAtus command are:
回答のtiered構造のために、MSTAtusコマンドへの可能な応答は以下の通りです。
860 <Sequence> <Date&Time> Delivered, Awaiting Read Confirmation
861 <Sequence> <Date&Time> Delivered, Awaiting Reply (MCR)
860 <系列><日付と時間>は配送しました、そして、待ちは<系列><が日付を入れる確認861を読みました、そして、回答をお待ちしていて、時間>は配送しました。(MCR)
870 <Sequence> <Date&Time> Delivered, Read, Awaiting Reply (MCR)
>が提供した870<系列><日付と時間、回答をお待ちしていて、読んでください。(MCR)
880 <Sequence> <Date&Time> Message Delivered (No Reply Pending)
881 <Sequence> <Date&Time> Message Delivered and Read by Recipient
888 <Sequence> <Date&Time> <Reply_Code> MCR Reply Received
889 <Sequence> <Date&Time> <Full_Text_Response>
880 受取人888<系列><日付と時間><回答_コード>MCR回答で提供されて、読まれた881の<系列><日付と時間>メッセージが提供された(未定の回答がありません)<系列><日付と時間>メッセージは889<系列><日付と時間の>の<の完全な_テキスト_応答>を得ました。
960 <Sequence> <Date&Time> Message Queued; Awaiting Delivery
960 <系列><日付と時間>メッセージは列を作りました。 配送を待ちます。
780 <Sequence> <Date&Time> MESSAGE EXPIRED Before Delivery!
780 配送の前に吐き出された<系列><日付と時間>メッセージ!
550 Unknown or Illegal Message_Tag or Pass_Code
421 Gateway Service Unavailable (terminate connection)
500 Command Not Implemented
554 Error, failed (technical reason)
550、未知、Illegal Message_TagまたはPass_Code421ゲートウェイService Unavailable(接続を終えます)500Command Not Implemented554Errorであって、失敗にされる(技術的な理由)
After a closure-series (88x) command has been returned to the client, acceleration of message tag deletion may be desired to maximize use of resources on the server.
閉鎖シリーズ(88x)コマンドをクライアントに返した後に、サーバにおけるリソースの使用を最大にすることをメッセージタグ削除の加速を望むかもしれません。
KTAG <Message_Tag> <Pass_Code>
KTAG<メッセージ_タグ><パス_コード>。
Used to "kill" the message tag after final reading (or when no further responses are desired). This is more of a courtesy feature that allows the client to "clean up" rather than wait for the SNPP server to expire the tag.
最終的な読書の後にメッセージタグを「殺すこと」において、使用されています(または、さらなる応答は全くいつ望まれていませんか)。 これはクライアントがSNPPサーバが吐き出すのを待っているよりむしろタグを「きれいにすること」を許容する礼儀機能の以上です。
4.7 Illegal Commands
4.7 不法なコマンド
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サーバ下である、さようなら
Gwinn Informational [Page 20] RFC 1861 SNPP - Version 3 October 1995
Gwinnの情報[20ページ]のRFC1861SNPP--バージョン1995年10月3日
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.
これは、ゲートウェイが行政上下がっているか、またはページング端末に関するある他の技術的であるか管理の問題があるとき、接続を拒否するか、または終えるのに使用されます。
4.8 Timeouts
4.8 タイムアウト
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.9 Rigidity of Command Structure
4.9 命令系統の剛性
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展開に備えて加えられます。
Level three enhancements to the protocol have been added in preparation for acknowledgment-based messaging.
レベルthree プロトコルへの増進は承認ベースのメッセージングに備えて加えられます。
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
この仕様の戦略、および詳細の多くがIETF作業部会と3人のIESGメンバーによって再検討されました。 彼らは、既存のメールインフラストラクチャを使用するアプローチが望ましいと結論を下しました、よほど新しいプロトコルを配布する非常に高いコストとインターネットを使用する利点に、当然です。
Gwinn Informational [Page 21] RFC 1861 SNPP - Version 3 October 1995
Gwinnの情報[21ページ]のRFC1861SNPP--バージョン1995年10月3日
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 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.
ほとんどの広く分配されたアプリケーションがインフラストラクチャについて議定書の中で述べます。 ほとんどの評論家が、新しいプロトコルはクライアントとサーバの慎重な構成で「至急、配送するか、または失敗してください」というSNPPの特別な要件を達成できたので全く必要でなかったと感じました。 実験的なネットワーク印刷プロトコル[4]は既存の問題への既存のインフラストラクチャアプローチに関する例として特定されました。 他の評論家は、新しいプロトコルの詳細のためにページングクライアントとサーバを互いに特定して、弁護がトランザクションの詳細を交渉するのをすることができましたが、新しいプロトコル構造を配布するより拡大としてむしろ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 Informational [Page 22] RFC 1861 SNPP - Version 3 October 1995
Gwinnの情報[22ページ]のRFC1861SNPP--バージョン1995年10月3日
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@radio.net
以下に電話をしてください。 214/768-3186 メールしてください: allen@mail.cox.smu.edu かallen@radio.net
Gwinn Informational [Page 23]
Gwinn情報です。[23ページ]
一覧
スポンサーリンク
