RFC1569 日本語訳
1569 Principles of Operation for the TPC.INT Subdomain: Radio Paging-- Technical Procedures. M. Rose. January 1994. (Format: TXT=12597 bytes) (Obsoleted by RFC1703) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Rose Request for Comments: 1569 Dover Beach Consulting, Inc. Category: Informational January 1994
コメントを求めるワーキンググループM.バラ要求をネットワークでつないでください: 1569年のドーヴァービーチコンサルティングInc.カテゴリ: 情報の1994年1月
Principles of Operation for the TPC.INT Subdomain:
Radio Paging -- Technical Procedures
TPC.INTサブドメインのための操作のプリンシプルズ: ラジオページング--技術的な手順
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.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Table of Contents
目次
1. Introduction ................................................ 1 2. Naming, Addressing, and Routing ............................. 2 2.1 Addressing ................................................. 2 2.2 Routing .................................................... 3 3. Procedure ................................................... 3 3.1 MAILing versus SENDing ..................................... 4 3.2 Latency .................................................... 4 4. Usage Examples .............................................. 5 4.1 MIME-based ................................................. 5 4.2 Non-MIME ................................................... 5 5. Security Considerations ..................................... 6 6. Acknowledgements ............................................ 6 7. References .................................................. 6 8. Author's Address ............................................ 6
1. 序論… 1 2. 命名、アドレシング、およびルート設定… 2 2.1 扱います。 2 2.2 ルート設定… 3 3. 手順… 3 3.1 発信に対して郵送します。 4 3.2潜在… 4 4. 用法の例… 5 4.1 MIMEベース… 5 4.2 非MIME… 5 5. セキュリティ問題… 6 6. 承認… 6 7. 参照… 6 8. 作者のアドレス… 6
1. Introduction
1. 序論
As an adjunct to the usual, two-way electronic mail service, it is at times useful to employ a one-way text notification service, called radio paging. This memo describes a technique for radio paging using the Internet mail infrastructure. In particular, this memo focuses on the case in which radio pagers are identified via the international telephone network.
普通の、そして、両用の電子メールサービスへの付属物として、一方向テキスト通知サービスを使うのは時には役に立ちます、呼ばれたラジオページング。 このメモは、ラジオページングのためにインターネット・メールインフラストラクチャを使用することでテクニックについて説明します。 特に、このメモはポケットベルが国際電話ネットワークを通して特定される場合に焦点を合わせます。
The technique described by this memo, mapping telephone numbers to domain names, is derived from the TPC.INT subdomain. Consult RFC 1530, "Principles of Operation for the TPC.INT Subdomain: General Principles and Policy" for overview information.
TPC.INTサブドメインから電話番号をドメイン名に写像して、このメモで説明されたテクニックを得ます。 RFC1530に相談してください、「TPC.INTサブドメインのための操作のプリンシプルズ:」 概要情報のための「一般プリンシプルズとPolicy。」
Rose [Page 1] RFC 1569 Radio Paging -- Technical Procedures January 1994
ローズ[1ページ]RFC1569ラジオページング--技術的な手順1994年1月
2. Naming, Addressing, and Routing
2. 命名、アドレシング、およびルート設定
A radio pager is identified by a telephone number, e.g.,
ポケットベルは例えば電話番号によって特定されます。
+1 415 940 8776
+1 415 940 8776
where "+1" indicates the IDDD country code, and the remaining string is a telephone number within that country.
その国の中の「+1」をIDDD国名略号を示して、残っているストリングが電話番号であるところ。
2.1. Addressing
2.1. アドレシング
This number is used to construct the address of a radio pager server, which forms the recipient address for the message, e.g., one of:
この数は、メッセージ、例えば、1のための受取人アドレスを形成するポケットベルサーバのアドレスを構成するのに以下について使用されます。
pager-alpha@6.7.7.8.0.4.9.5.1.4.1.tpc.int
pager-numeric@6.7.7.8.0.4.9.5.1.4.1.tpc.int
pager-alpha@6.7.7.8.0.4.9.5.1.4.1.tpc.int ポケットベル数値@6.7.7.8.0.4.9.5.1.4.1.tpc.int
where the domain-part is constructed by reversing the telephone number, converting each digit to a domain-label, and being placed under "tpc.int." (The telephone number must not include any international access codes.)
ドメイン部分が各ケタをドメインラベルに変換して、"tpc.int"の下に置かれて、電話番号を逆にすることによって構成されるところ。 (電話番号は少しの国際的なアクセスコードも含んではいけません。)
In addition, addresses of the form
追加、フォームのアドレスで
pager.ATOM@6.7.7.8.0.4.9.5.1.4.1.tpc.int
pager-alpha.ATOM@6.7.7.8.0.4.9.5.1.4.1.tpc.int
pager-numeric.ATOM@6.7.7.8.0.4.9.5.1.4.1.tpc.int
pager.ATOM@6.7.7.8.0.4.9.5.1.4.1.tpc.int ポケットベルalpha.ATOM@6.7.7.8.0.4.9.5.1.4.1.tpc.int、 pager-numeric.ATOM@6.7.7.8.0.4.9.5.1.4.1.tpc.int
where "ATOM" is an (optional) RFC 822 atom [1], are reserved for future use. Note that the mailbox syntax is purposefully restricted in the interests of pragmatism. To paraphrase RFC 822, an atom is defined as:
「原子」が(任意)のRFCであるところでは、今後の使用において、822原子[1]は予約されています。 メールボックス構文が実益主義のために故意に制限されることに注意してください。 RFC822について言い換えるために、原子は以下と定義されます。
atom = 1*atomchar
原子=1*atomchar
atomchar= <any upper or lowercase alphabetic character
(A-Z a-z)>
/ <any digit (0-9)>
/ "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+"
/ "-" / "/" / "=" / "?" / "^" / "_" / "`" / "{"
/ "|" / "}" / "~"
atomcharは少しもより上に<と等しい、またはどんなケタ(0-9)>/“!"にも英字(A-Z a-z)>/<を小文字で印刷します。 / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "/" / "=" / "?" / "^" / "_" / "`" / "{" / "|" / "}" / "~"
Finally, note that some Internet mail software (especially gateways from outside the Internet) impose stringent limitations on the size of a mailbox-string. Thus, originating user agents should take care in limiting the local-part to no more than 70 or so characters.
最終的に、何らかのインターネット・メールソフトウェア(インターネットの外からの特にゲートウェイ)がメールボックスストリングのサイズに厳しい制限を課すことに注意してください。 したがって、ユーザエージェントを溯源するのに地方の部分をおよそ70未満のキャラクタに制限する際に注意するべきです。
Rose [Page 2] RFC 1569 Radio Paging -- Technical Procedures January 1994
ローズ[2ページ]RFC1569ラジオページング--技術的な手順1994年1月
2.2. Routing
2.2. ルート設定
The message is routed in exactly the same fashion as all other electronic mail, i.e., using the MX algorithm [2]. Since a radio pager server might be able to access many radio pagers, the wildcarding facilities of the DNS [3,4] are used accordingly. For example, if a radio pager server residing at "dbc.mtview.ca.us" is willing to access any radio pager with a telephone number prefix of
すなわち、メッセージは、MXアルゴリズム[2]を使用しながら、まさに他のすべての電子メールと同じファッションで発送されます。 ポケットベルサーバが多くのポケットベルにアクセスできるかもしれないので、DNS[3、4]のwildcarding施設はそれに従って、使用されます。 例えば、aであるなら、"dbc.mtview.ca.us"に住んでいると電話番号接頭語があるどんなポケットベルもアクセスしても構わないと思われているポケットベルサーバを無線連絡してください。
+1 415 940
+1 415 940
then this resource record might be present
その時、このリソース記録は存在しているかもしれません。
*.0.4.9.5.1.4.1.tpc.int. IN MX 10 dbc.mtview.ca.us.
*.0.4.9.5.1.4.1.tpc.int。 IN MX10dbc.mtview.ca.us。
Naturally, if several radio pager servers were willing to access any radio pager in that prefix, multiple MX resource records would be present.
当然、いくつかのポケットベルサーバが、その接頭語で何かポケットベルにアクセスしても構わないと思っているなら、複数のMXリソース記録が存在しているでしょうに。
It should be noted that the presence of a wildcard RR which matches a radio pager server's address does not imply that the corresponding telephone number is valid, or, if valid, that a radio pager is identified by the phone number. Rather, the presence of a wildcard RR indicates that a radio pager server is willing to attempt access.
ポケットベルサーバのアドレスに合っているRRがそうしないワイルドカードの存在が、または、有効ですが、対応する電話番号が有効であり、ポケットベルが電話番号によって特定されるのを含意することに注意されるべきです。 むしろ、ワイルドカードRRの存在は、ポケットベルサーバが、アクセサリーを試みても構わないと思っているのを示します。
3. Procedure
3. 手順
When information is to be sent to a radio pager, the user application constructs an RFC 822 message, containing a "Message-ID" field and a textual content (e.g., a "text/plain" content [5]).
情報がポケットベルに送ることであるときに、ユーザアプリケーションはRFC822メッセージを構成します、「Message ID」分野と原文の内容を含んでいて。(例えば、「テキスト/明瞭な」内容[5])。
The message is then sent to the radio pager server's electronic mail address.
そして、ポケットベルサーバの電子メールアドレスにメッセージを送ります。
The radio pager server begins by looking at the local part of the address. If the local-part is the literal string "pager-alpha" then this indicates that the recipient is using an alpha-numeric pager. The radio pager server consults a local database to determine how to send the page based on the domain-part. This local knowledge includes information about the protocol used to talk to the paging network and the access number. As such, a radio pager server will register itself in the DNS as providing service only to those phone numbers for which it has such knowledge.
ポケットベルサーバは、アドレスの地方の部分を見ることによって、始まります。 地方の部分が文字通りのストリング「ポケットベルアルファ」であるなら、これは、受取人がアルファベット数字式ポケットベルを使用しているのを示します。 ポケットベルサーバは、ドメイン部分に基づくページを送る方法を決定するためにローカルのデータベースに相談します。 この局所的知識はページングネットワークとアクセス番号と話すのに使用されるプロトコルの情報を含んでいます。 そういうものとして、ポケットベルサーバはそれがそのような知識を持っているそれらの電話番号だけに対するサービスを提供するとしてDNSにそれ自体を登録するでしょう。
Otherwise, if the local-part is the literal string "pager-numeric" then this indicates that the recipient is using a numeric pager. The radio pager server may consult a local database to determine how to send the page based on the domain-part; or, it may dial the number
さもなければ、地方の部分が文字通りのストリング「ポケットベル数値」であるなら、これは、受取人が数値ポケットベルを使用しているのを示します。 ポケットベルサーバはドメイン部分に基づくページを送る方法を決定するためにローカルのデータベースに相談するかもしれません。 または、それはその番号にかけるかもしれません。
Rose [Page 3] RFC 1569 Radio Paging -- Technical Procedures January 1994
ローズ[3ページ]RFC1569ラジオページング--技術的な手順1994年1月
specified in the domain-part directly.
ドメイン部分では、直接指定されます。
For alpha-numeric pagers, the radio pager server determines which information found in the headers and body of the message are used when constructing the paging message. For example, some radio pager servers might choose to examine the "To" and "Subject" fields, in addition to the body, whilst other radio pager servers might choose to simply send the body verbatim.
アルファベット数字式ポケットベルに関しては、ポケットベルサーバは、ページングメッセージを構成するとき、ヘッダーとメッセージ欄で見つけられたどの情報が使用されているかを決定します。 例えば、いくつかのポケットベルサーバが、“To"と「受けることがある」分野を調べるのを選ぶかもしれません、ボディーに加えて、他のポケットベルサーバは、単にボディーを逐語的に送るのを選ぶかもしれませんが。
For numeric pagers, the radio pager server sends only the body, which must consistent solely of digits.
数値ポケットベルに関しては、ポケットベルサーバは唯一ケタで一貫していた状態でそうしなければならないボディーだけを送ります。
3.1. MAILing versus SENDing
3.1. 郵送対発信
An SMTP client communicating with a radio pager server may use attempt either the MAIL or SEND command. The radio pager server MUST support the MAIL command, and MAY support any of the SEND, SOML, or SAML commands.
ポケットベルサーバとコミュニケートするSMTPクライアントはメールかSENDのどちらかが命令する試みを使用するかもしれません。 ポケットベルサーバは、メールがコマンドであることをサポートしなければならなくて、SEND、SOML、またはSAMLコマンドのいずれもサポートするかもしれません。
If the MAIL command is used, then a positive completion reply to both the RCPT and DATA commands indicates, at a minimum, that the message has been queued for transmission into the radio paging network for the recipient, but is at least queued for transmission into the radio paging network.
メールコマンドが使用されているなら、RCPTとDATAコマンドの両方に関する積極的な完成回答は、最小限でメッセージがトランスミッションのために受取人のためのラジオページングネットワークへ列に並ばせられましたが、トランスミッションのためにラジオページングネットワークへ少なくとも列に並ばせられるのを示します。
If the SEND command is used, then a positive completion reply to both the RCPT and DATA commands indicates that the message has been accepted by the radio paging network for delivery to the recipient.
SENDコマンドが使用されているなら、RCPTとDATAコマンドの両方に関する積極的な完成回答は、メッセージが配送のためにラジオページングネットワークによって受取人に受け入れられたのを示します。
If the SOML or SAML command is used, then a positive completion reply to both the RCPT and DATA commands indicates that the message may have been accepted by the radio paging network for delivery to the recipient.
SOMLかSAMLコマンドが使用されているなら、RCPTとDATAコマンドの両方に関する積極的な完成回答は、メッセージが配送のためにラジオページングネットワークによって受取人に受け入れられたかもしれないのを示します。
3.2. Latency
3.2. 潜在
Although the Internet electronic mail service tends to perform delivery in a timely and reliable manner, some paging services will wish to provide a higher degree of assurance to their clients, in particular guaranteeing that a positive reply code means that the page has been sent on the radio network. For such requirements, the primary constraints are server implementation and client/server network connectivity.
インターネット電子メールサービスは、タイムリーで信頼できる方法で配送を実行する傾向がありますが、いくつかのポケットベルサービスが、より高度合いを保証を彼らのクライアントに提供したくなるでしょう、積極的な返事コードが、ラジオ放送網でページを送ることを意味するのを特に保証して。 そのような要件に関しては、プライマリ規制はサーバ実装とクライアント/サーバネットワークの接続性です。
A client that uses the SEND or SAML commands is explicitly requesting real-time transmission on the radio network and is requiring that the server reply code will carry a statement of success or failure about that transmission.
SENDかSAMLコマンドを使用するクライアントは、ラジオ放送網で明らかにリアルタイムのトランスミッションを要求していて、サーバ回答コードがそのトランスミッションに関して成否の声明を運ぶのを必要としています。
Rose [Page 4] RFC 1569 Radio Paging -- Technical Procedures January 1994
ローズ[4ページ]RFC1569ラジオページング--技術的な手順1994年1月
The IP level of the Internet performs datagram store-and-forward service, but gives the end system hosts the appearance of direct connectivity, by virtue of allowing interactive service. The Internet electronic mail service adds another layer of store-and- forward indirection, so that messages may go through any number of relays (and/or gateways). This may introduce arbitrarily large delays of minutes, hours, or days.
インターネットのIPレベルは、データグラム店とフォワードサービスを実行しますが、ダイレクト接続性の外観を終わりのシステムホストに与えます、双方向サービスを許容することによる。 インターネット電子メールサービスが別の層の店を加える、-、-間接指定(いろいろなリレー(そして/または、ゲートウェイ)でメッセージが行かせるかもしれないそう)を進めてください。 これは数分、何時間もの、または何日もの任意に大きい遅れを導入するかもしれません。
A client that configures their Internet attachment to permit "direct" SMTP connectivity to a pager server will be able to submit paging requests to the server directly, without additional SMTP-relaying. That is, transmission from paging client to paging server will be one "SMTP-hop"only. This will eliminate any possibility of non- deterministic delay by the Internet itself.
SMTPの接続性をポケットベルサーバに「ダイレクトに」可能にするために彼らのインターネット付属を構成するクライアントは直接サーバへ要求を呼び出しながら、提出できるでしょう、追加SMTP-リレーなしで。 すなわち、ページングクライアントからページングサーバまでのトランスミッションは1「SMTP-ホップ」専用でしょう。 これはインターネット自体のそばで非決定論的な遅れのどんな可能性も排除するでしょう。
The combination of configuring paging server and paging client to allow direct IP/SMTP-level interaction and ensuring that they use SEND or SAML commands only will mean that a client receiving a positive reply from the server is assured that the page has been sent on the radio network.
ページングサーバを構成して、ダイレクトSMTP IP/レベル相互作用を許容するためにクライアントを呼び出して、彼らがSENDかSAMLコマンドだけを使用するのを確実にする組み合わせは、サーバから積極的な返事を受けるクライアントがラジオ放送網でページを送ると確信していることを意味するでしょう。
4. Usage Examples
4. 使用例
4.1. MIME-based
4.1. MIMEベースです。
To: pager-alpha@6.7.7.8.0.4.9.5.1.4.1.tpc.int
cc: Marshall Rose <mrose@dbc.mtview.ca.us>
From: Carl Malamud <carl@malamud.com>
Date: Thu, 22 Jul 1993 08:38:00 -0800
Subject: First example, for an alphanumeric pager
Message-ID: <19930908220700.1@malamud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
To: pager-alpha@6.7.7.8.0.4.9.5.1.4.1.tpc.int cc: マーシャル Rose <mrose@dbc.mtview.ca.us 、gt;、From: カール Malamud <carl@malamud.com 、gt;、日付: 木曜日、1993年7月22日の08:38:00 -0800Subject: 英数字のポケットベルMessage-IDのための最初の例: <19930908220700.1@malamud.com>MIMEバージョン: 1.0コンテントタイプ: テキスト/平野。 charsetが私たちと等しい、-、ASCII
A brief textual message.
簡潔な原文のメッセージ。
4.2. Non-MIME
4.2. 非MIME
To: pager-numeric@6.7.7.8.0.4.9.5.1.4.1.tpc.int
cc: Marshall Rose <mrose@dbc.mtview.ca.us>
From: Carl Malamud <carl@malamud.com>
Date: Thu, 22 Jul 1993 08:38:00 -0800
Subject: Second example, for a numeric pager
Message-ID: <19930908220700.2@malamud.com>
To: pager-numeric@6.7.7.8.0.4.9.5.1.4.1.tpc.int cc: マーシャル Rose <mrose@dbc.mtview.ca.us 、gt;、From: カール Malamud <carl@malamud.com 、gt;、日付: 木曜日、1993年7月22日の08:38:00 -0800Subject: 数値ポケットベルMessage-IDのための2番目の例: <19930908220700.2@malamud.com>。
2026282044
2026282044
Rose [Page 5] RFC 1569 Radio Paging -- Technical Procedures January 1994
ローズ[5ページ]RFC1569ラジオページング--技術的な手順1994年1月
5. Security Considerations
5. セキュリティ問題
Internet mail may be subject to monitoring by third parties, and in particular, message relays.
インターネット・メールは第三者、および特にメッセージでリレーをモニターするのを受けることがあるかもしれません。
6. Acknowledgements
6. 承認
This document was motivated by "Simple Network Paging Protocol - Version 1", by Allen Gwinn of Southern Methodist University.
このドキュメントは「南部のメソジスト教派の大学のアレンGwinnでプロトコルをバージョン1インチ呼び出す簡単なネットワーク」によって動機づけられました。
David H. Crocker and Carl Malamud also provided substantive comments.
また、デヴィッド・H.クロッカーとカール・マラマッドは実質的なコメントを提供しました。
7. References
7. 参照
[1] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, University of Delaware, August 1982.
[1] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、デラウエア大学(1982年8月)。
[2] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
974, BBN, January 1986.
[2] ヤマウズラ、C.が「ルート設定とドメインシステムを郵送する」、STD14、RFC974、BBN、1月1986日
[3] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
13, RFC 1034, Information Sciences Institute, November 1987.
[3]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、科学が設ける情報、11月1987日
[4] Mockapetris, P., "Domain Names -- Implementation and
Specification", STD 13, RFC 1035, Information Sciences Institute,
November 1987.
[4]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、科学が設ける情報、11月1987日
[5] 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.
[5] Borenstein、N.、およびN.フリード、「パート1をまねてください(マルチパーパスインターネットメールエクステンション)」 「インターネットメッセージ本体の形式を指定して、説明するためのメカニズム」、RFC1521、Bellcore、Innosoft、1993年9月。
8. Author's Address
8. 作者のアドレス
Marshall T. Rose Dover Beach Consulting, Inc. 420 Whisman Court Mountain View, CA 94043-2186 US
Inc.420Whisman法廷カリフォルニア94043-2186マウンテンビュー(米国)に相談するマーシャル・T.バラドーヴァービーチ
Phone: +1 415 968 1052 Fax: +1 415 968 2510 EMail: mrose@dbc.mtview.ca.us
以下に電話をしてください。 +1 415 968、1052Fax: +1 2510年の415 968メール: mrose@dbc.mtview.ca.us
Rose [Page 6]
上昇しました。[6ページ]
一覧
スポンサーリンク
