RFC3939 日本語訳
3939 Calling Line Identification for Voice Mail Messages. G. Parsons,J. Maruszak. December 2004. (Format: TXT=22739 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Parsons Request for Comments: 3939 J. Maruszak Category: Standards Track Nortel Networks December 2004
教区牧師がコメントのために要求するワーキンググループG.をネットワークでつないでください: 3939年のJ.Maruszakカテゴリ: 規格は2004年12月にノーテルネットワークを追跡します。
Calling Line Identification for Voice Mail Messages
線をボイスメールメッセージのための識別と呼びます。
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(2004)。
Abstract
要約
This document describes a method for identifying the originating calling party in the headers of a stored voice mail message. Two new header fields are defined for this purpose: Caller_ID and Called_Name. Caller_id is used to store sufficient information for the recipient to callback, or reply to, the sender of the message. Caller-name provides the name of the person sending the message.
このドキュメントは格納されたボイスメールメッセージのヘッダーの由来している起呼側を特定するための方法を説明します。 2つの新しいヘッダーフィールドがこのために定義されます: IDと呼ばれた_が命名する訪問者_。 訪問者_イドが回収への受取人への十分な情報、または回答を格納するのにおいて使用されている、メッセージ送信者。 訪問者名は人の発信の名前にメッセージを提供します。
Parsons & Maruszak Standards Track [Page 1] RFC 3939 Calling Line Identification December 2004
回線識別を2004年12月と呼ぶパーソンズとMaruszak標準化過程[1ページ]RFC3939
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions Used in this Document. . . . . . . . . . . . . . . 3 3. Calling Line Identification Field. . . . . . . . . . . . . . . 3 3.1. Internal Call. . . . . . . . . . . . . . . . . . . . . . 4 3.2. External Call. . . . . . . . . . . . . . . . . . . . . . 4 3.3. Numbering Plan . . . . . . . . . . . . . . . . . . . . . 4 3.4. Date Header. . . . . . . . . . . . . . . . . . . . . . . 5 4. Caller Name Field. . . . . . . . . . . . . . . . . . . . . . . 5 5. Formal Syntax. . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Calling Line Identification Syntax . . . . . . . . . . . 6 5.2. Caller Name Syntax . . . . . . . . . . . . . . . . . . . 6 5.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Other Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations. . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . 8 10. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 11
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 このDocumentのコンベンションUsed。 . . . . . . . . . . . . . . 3 3. 回線識別を分野と呼びます。 . . . . . . . . . . . . . . 3 3.1. 内部の呼び出し。 . . . . . . . . . . . . . . . . . . . . . 4 3.2. 外部の呼び出し。 . . . . . . . . . . . . . . . . . . . . . 4 3.3. プラン. . . . . . . . . . . . . . . . . . . . . 4 3.4に付番します。 ヘッダーとデートしてください。 . . . . . . . . . . . . . . . . . . . . . . 5 4. 訪問者名前欄。 . . . . . . . . . . . . . . . . . . . . . . 5 5. 正式な構文。 . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. 回線識別を構文. . . . . . . . . . . 6 5.2と呼びます。 訪問者名前構文. . . . . . . . . . . . . . . . . . . 6 5.3。 例. . . . . . . . . . . . . . . . . . . . . . . . 6 6。 他の問題. . . . . . . . . . . . . . . . . . . . . 6 7。 セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 7 8. IANA問題。 . . . . . . . . . . . . . . . . . . . . . 7 9. 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1。 引用規格. . . . . . . . . . . . . . . . . . 8 9.2。 有益な参照. . . . . . . . . . . . . . . . . 8 10。 承認。 . . . . . . . . . . . . . . . . . . . . . . . 9人の作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . . 10の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
1. 序論
There is currently a need for a mechanism to identify the originating party of a voice mail message, outside of the "FROM" header information. The telephone number and name of the caller are typically available from the telephone network, but there is no obvious header field to store this in an Internet Mail message.
現在、ボイスメールメッセージ(“FROM"ヘッダー情報の外部)の由来しているパーティーを特定するために、メカニズムの必要があります。 訪問者の電話番号と名前は電話網から通常利用可能ですが、インターネットメールメッセージにこれを格納するために、どんな明白なヘッダーフィールドもありません。
This information is intended for use when the VPIM message format is used for storing "Call Answer" voice messages in an Internet Mail message store, i.e., the calling party leaves a voice message for the recipient, who was unable to answer the call. The implication is that there is no RFC 2822 address known for the originator.
VPIMメッセージ・フォーマットがインターネットメールメッセージ店に「呼び出し答え」音声メールを格納するのに使用されるとき、この情報は使用のために意図します、すなわち、起呼側が音声メールを受取人に残します。(その受取人は、電話口に出ることができませんでした)。 含意は創始者で知られているRFC2822アドレスが全くないということです。
[VPIMV2R2] suggests the originating number be included as an Internet address, using the first method shown below. There are several other ways to store this information, but they all involve some manipulation of the "From" field. For example:
[VPIMV2R2]は、以下に示された最初の方法を使用して、由来している数がインターネット・アドレスとして含まれているのを示します。 この情報を格納する他のいくつかの方法がありますが、それらは皆、“From"分野の何らかの操作にかかわります。 例えば:
1. From: "416 555 1234" <non-mail-user@host> 2. From: "John Doe" <4165551234@host> 3. From: unknown:;
1. From: 「416 555、1234、「 <non-mail-user@host 、gt;、2」 From: 「ジョン・ドウ、「 <4165551234@host 、gt;、3」 From: 未知:、。
Parsons & Maruszak Standards Track [Page 2] RFC 3939 Calling Line Identification December 2004
回線識別を2004年12月と呼ぶパーソンズとMaruszak標準化過程[2ページ]RFC3939
Since any of these is a forced translation, it would be useful to store the calling party's name and number as presented by the telephone system to the called party without manipulation. This would allow the calling party's information to be displayed to the recipient (similar to it appearing on the telephone) and also allow future determination of an Internet address for the originator (if one exists). Note that there is no requirement to store meta-data (e.g., type of number, presentation restricted), as this information is not presented to the called party and is generally not available to voice mail systems. The intent is to store the available information to an analog (non-ISDN) phone (e.g., per [T1.401] in North America).
これらのどれかが無理矢理の翻訳であるので、起呼側の名前と番号を格納するのは電話によって操作なしで被呼者に提示されるように役に立つでしょう。 そして、これが、起呼側の情報が受取人に表示されるのを許容するだろう、(それと同様である、電話の上に現れます)、また、創始者のためのインターネット・アドレスの今後の決断を許容してください(1つが存在しているなら)。 メタデータ(例えば、数のタイプ、制限されたプレゼンテーション)を格納するという要件が全くないことに注意してください、この情報が被呼者に提示されないで、また一般にボイスメールシステムに利用可能でないときに。意図はアナログ(非ISDNの)の電話(例えば、北アメリカの[T1.401]あたりの)に入手可能な情報を格納することです。
[RFC2076] currently lists "phone" as an Internet message header which would hold the originating party's telephone number, but it is listed as "non-standard", i.e., usage of this header is not generally recommended. It also has no defined format, making the information unparsable. There is no similar entry for the originator's name.
それは「標準的でない」として記載されています、そして、[RFC2076]は現在、由来しているパーティーの電話番号を保持するインターネットメッセージヘッダーとして「電話」を記載しますが、すなわち、一般に、このヘッダーの使用法は推薦されません。 また、情報を「非-パー-可能」させて、それには定義された形式が全くありません。 創始者の名前のためのどんな同様のエントリーもありません。
It is proposed that two new message header fields be included to hold this information, namely the Calling Line Identification ("Caller- ID") and Caller Name ("Caller-Name").
すなわち、この情報、Callingが線Identification(「訪問者ID」)とCaller Nameを持つように2つの新しいメッセージヘッダーフィールドが含まれている(「訪問者名」)よう提案されます。
2. Conventions Used in this Document
2. このDocumentのコンベンションUsed
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14[RFC2119]で説明されるように本書では解釈されることであるべきです。
3. Calling Line Identification Field
3. 回線識別を分野と呼びます。
The Calling Line Identification header ("Caller-ID") holds sufficient information for the recipient's voice mail system to call back, or reply to, the sender of the message. The number that is contained in this header is supplied by the telephone system. The exact format of the data received depends on the type of call, that is -- internal or external call.
Calling線Identificationヘッダー(「発信番号表示」)は受取人のボイスメールシステムが電話し直すか、または答える十分な情報を保持します、メッセージ送信者。 電話はこのヘッダーに含まれている数を供給します。 すなわち、受け取られたデータの正確な形式を呼び出しのタイプに頼っています--内部の、または、外部の呼び出し。
Note that for both options, the number field MUST contain only the digits of the number and MUST be representable using the American Standard Code for Information Interchange [ASCII] character set; it does not include any separating character (e.g., "-").
両方のオプションに、ナンバーフィールドが数のケタだけを含まなければならなくて、情報交換用米国標準コード[ASCII]文字の組を使用して、「表-可能」であるに違いないというメモ。 それは少しの区切り文字(例えば、「-」)も含んでいません。
It is expected that default, likely to be the most common case, will not have any numbering plan semantic associated with the number. However, in the case that it is known, an optional "NumberingPlan" parameter MAY be used to indicate the semantic.
最も一般的なケースである傾向があるデフォルトでどんな付番プランも意味的に数に関連していた状態でならないと予想されます。 しかしながら、それが知られていて、任意の"NumberingPlan"パラメタは、意味を示すのに使用されるかもしれません。
Parsons & Maruszak Standards Track [Page 3] RFC 3939 Calling Line Identification December 2004
回線識別を2004年12月と呼ぶパーソンズとMaruszak標準化過程[3ページ]RFC3939
3.1. Internal Call
3.1. 内部の呼び出し
For an internal call (e.g., between two extensions within the same company), it is sufficient to relay only the extension of the calling party, based on the company dialing plan.
内部の要求(例えば、同じ会社の中の2つの拡大の間の)では、起呼側の拡大だけをリレーするのは十分です、プランにダイヤルする会社に基づいて。
However, the support of longer numbers may be supported by the enterprise phone system.
しかしながら、より長い数のサポートは企業電話システムで後押しされているかもしれません。
3.2. External Call
3.2. 外部の呼び出し
For an international call, the calling party's number must be the full international number as described in [E.164], i.e., Country Code (CC), National Destination Code (NDC), and Subscriber Number (SN). Other information, such as prefixes or symbols (e.g., "+"), MUST NOT be included. [E.164] allows for numbers of up to 15 digits.
国際電話において、起呼側の番号は[E.164]、すなわち、Country Code(CC)、National Destination Code(NDC)、およびSubscriber Number(SN)で説明されるように完全な国際的な数であるに違いありません。 接頭語やシンボル(例えば、「+」)のように、他の情報を含んではいけません。 [E.164]は最大15ケタの数を考慮します。
For a call within North America, it is also suggested that 15 digits per [T1.625] be supported. However, some service providers may only support 10 digits as described in [T1.401] and [GR-31-CORE]. Though it is desirable that an international number not be truncated to 10 digits if it contains more, it is recognized that limitations of various systems will cause this to happen.
また、北アメリカの中の呼び出しにおいて、[T1.625]あたり15ケタが支持されることが提案されます。 しかしながら、[T1.401]と[GR-31-CORE]で説明されるように10ケタしか支持しないサービスプロバイダーもあるかもしれません。 以上を含んでいるなら国際的な数が10ケタに先端を切られないのが、望ましいのですが、これが様々なシステムの限界で起こると認められます。
Implementors of this specification should be aware that some phone systems are known to truncate international numbers, even though this behavior is undesirable.
この仕様の作成者はいくつかの電話システムが国際的な数に先端を切らせるのが知られているのを意識しているべきです、この振舞いは望ましくないのですが。
Note that the other defined fields available to non-analog systems (e.g., subaddress, redirecting number), as well as the meta-data, are not intended to be stored in this header.
このヘッダーにもう片方が非アナログ・システム(例えば、数を向け直す「副-アドレス」)に利用可能な分野を定義したというメモ、およびメタデータが格納されることを意図しません。
3.3. Numbering Plan
3.3. 付番プラン
In this baseline case (i.e., analog lines), no numbering plan information is known or implied. However, in the case that a numbering plan is known, an optional "NumberingPlan" parameter MAY be used to indicate the semantic. Only three semantics are defined: "unknown", "local", and "e164". "unknown" is the default if no numbering plan semantic is known (and the default if the parameter is absent). "local" has meaning only within the domain of the voice mail system that stored the message (i.e., the voice mail system knows that the number belongs to a local numbering plan). "e164" indicates that the number is as described in [E.164]. "x-" may be used to indicate enterprise or service specific dialing plans.
この基線場合(すなわち、アナログの線)では、付番プラン情報は、全く知られもしませんし、含意もされません。 しかしながら、付番プランが知られていて、任意の"NumberingPlan"パラメタは、意味を示すのに使用されるかもしれません。 3意味論だけが定義されます: 「未知」、「地方」、および"e164"。 「未知」は付番していないプラン意味的であるならデフォルトが知られているという(デフォルトはパラメタであるなら欠けています)ことです。 「地方」はメッセージを格納したボイスメールシステムのドメインだけの中に意味を持っています(すなわち、ボイスメールシステムは、数がローカルの付番プランに属すのを知っています)。 "e164"は、[E.164]で説明されるように数がそうであることを示します。 「x」は、企業を示すか、または特定のダイヤルするプランを修理するのに使用されるかもしれません。
Parsons & Maruszak Standards Track [Page 4] RFC 3939 Calling Line Identification December 2004
回線識別を2004年12月と呼ぶパーソンズとMaruszak標準化過程[4ページ]RFC3939
3.4. Date Header
3.4. 日付のヘッダー
The date and time may be included by the telephone system with the calling party's telephone number per [T1.401]. This MAY be used, as there is an existing "Date" Internet header to hold this information. It is a local implementation decision whether this time or the local system time will be recorded in the "Date" header.
日時は起呼側の[T1.401]あたりの電話番号がある電話によって含まれるかもしれません。 この情報を保持するために既存の「日付」インターネットヘッダーがあるとき、これは使用されているかもしれません。 それは今回かローカルシステム時間が「日付」ヘッダーに記録されるかどうかというローカルの実現決定です。
4. Caller Name Field
4. 訪問者名前欄
The name of the person sending the message is also important. Information about whether the call is internal or external may be included if it is available. This information may not be available on international calls.
また、メッセージを送る人の名前も重要です。 それが利用可能であるなら、呼び出しが内部である、または外部であるかに関する情報は含まれるかもしれません。 この情報は国際電話のときに利用可能でないかもしれません。
Further, the exact format for this field is typically a service provider option per [T1.641]. It is possible for the caller's name to be sent in one of several character sets depending on the service provider signaling transport (e.g., ISDN-UP, SCCP, TCAP). These include:
さらに、通常、[T1.641]あたりこの分野のための正確な形式は1つのサービスプロバイダーオプションです。 サービスプロバイダーシグナリング輸送によるいくつかの文字の組の1つで訪問者の名前を送るのは可能です(例えば、ISDN-UP、SCCP、TCAP)。 これらは:
1) International Reference Alphabet (IRA), formerly know as International Alphabet No.5 or IA5 [T.50] 2) Latin Alphabet No. 1 [8859-1] 3) American National Standard Code for Information Interchange [ASCII] 4) Character Sets for the International Teletex Service [T.61]
1) 国際Reference Alphabet(IRA)、以前、国際Alphabet No.5かIA5[T.50]2)として知ってください。 ローマ字No.1[8859-1]3) 情報交換用米国標準コード[ASCII]4) 国際テレテックスサービスのための文字コード[T.61]
Of these, the IRA and T.61 character sets contain a number of options that help specify national and application oriented versions. If there is no agreement between parties to use these options, then the 7-bit character set in which the graphical characters of IRA, T.61, and ASCII are coded exactly the same, will be assumed. Further, the 7-bit graphical characters of [8859-1] are the same as in [ASCII].
これらでは、IRAとT.61文字の組は国家の、そして、アプリケーション指向のバージョンを指定するのを助ける多くのオプションを含んでいます。 使用するパーティーの間の協定が全くないと、これらのオプション(当時のIRA、T.61、およびASCIIのグラフィカルなキャラクタがまさに同じようにコード化される7ビットの文字の組)は想定されるでしょう。 さらに、[8859-1]の7ビットのグラフィカルなキャラクタは[ASCII]と同じです。
Note that for delivery to customer equipment in North America, the calling name MUST be presented in ASCII per [T1.401].
北アメリカでの顧客設備への配送において、[T1.401]あたりのASCIIで呼ぶ名を提示しなければならないことに注意してください。
As a result, for the caller name header defined in this document, characters are represented with ASCII characters. However, if a name is received that cannot be represented in 7-bit ASCII, it MAY be stored using its native character set as defined in [RFC2047].
その結果、本書では定義された訪問者名前ヘッダーに関して、キャラクタはASCII文字と共に代理をされます。 しかしながら、名前が受け取られているなら、7ビットのASCIIでそれを表すことができないで、それは[RFC2047]で定義されるように固有の文字の組を使用するのが格納されるかもしれません。
In telephone networks, the length of the name field MUST NOT exceed 50 characters, as defined in [T1.641]. However, service providers may choose to further limit this to 15 characters for delivery to customer equipment, e.g., [T1.401] and [GR-1188-CORE].
電話網では、名前欄の長さは[T1.641]で定義されるように50のキャラクタを超えてはいけません。 しかしながら、サービスプロバイダーは、顧客設備への配送のために例えばさらにこれを15のキャラクタに制限するのを選ぶかもしれません。[T1.401]と[GR-1188-CORE。]
Parsons & Maruszak Standards Track [Page 5] RFC 3939 Calling Line Identification December 2004
回線識別を2004年12月と呼ぶパーソンズとMaruszak標準化過程[5ページ]RFC3939
5. Formal Syntax
5. 正式な構文
Both Calling Line Identification and Caller Name follow the syntax specification using the augmented Backus-Naur Form (BNF) as described in [RFC2234]. While the semantics of these headers are defined in sections 4 and 5, the syntax uses the 'unstructured' token defined in [RFC2822]:
[RFC2234]で説明されるように増大しているBN記法(BNF)を使用することでCalling線IdentificationとCaller Nameの両方が構文仕様に従います。 これらのヘッダーがセクション4と5で定義されて、構文用途が'不統一'であるという[RFC2822]で定義された象徴の意味論である間:
unstructured = *([FWS] utext) [FWS]
不統一な=*([FWS]utext)[FWS]
5.1. Calling Line Identification Syntax
5.1. 回線識別を構文と呼びます。
"Caller-ID" ":" 1*DIGIT [ "," "NumberingPlan=" ( "unknown" / "local" / "e164" / ietf-token / x-token ) ] CRLF
「「発信番号表示」」:、」 1*DIGIT、[「」、「NumberingPlan=」(x ietf「未知」/「ローカル」/「e164」/象徴/象徴]CRLF
ietf-token := <An extension token defined by a standards-track RFC and registered with IANA.>
標準化過程RFCによって定義されて、IANA>に登録されたietf-象徴:=<An拡大象徴
x-token := <The two characters "X-" or "x-" followed, with no intervening white space, by any token>
2つのキャラクタ「X」か「x」がどんな象徴>も介入している余白なしで続けたx-象徴:=<。
5.2. Caller Name Syntax
5.2. 訪問者名前構文
"Caller-Name" ":" unstructured CRLF
「「訪問者名」」:、」 不統一なCRLF
5.3. Examples
5.3. 例
To: +19725551212@vm1.example.com Caller-ID: 6137684087 Caller-Name: Derrick Dunne
To: + 19725551212@vm1.example.com 発信番号表示: 6137684087訪問者名: Derrickダン
To: 6137637582@example.com Caller-ID: 6139416900 Caller-Name: Jean Chretien
To: 6137637582@example.com 発信番号表示: 6139416900訪問者名: ジーン・クレティエン
6. Other Considerations
6. 他の問題
6.1. Compatibility with Other Internet Phone Numbers
6.1. 他のインターネット電話番号との互換性
The intent of these headers are to record telephone number that is sent by the analog phone system with an incoming call without alteration or interpretation. If sufficient semantic is known or can be inferred, this may be included in the NumberingPlan field. This may allow it to be later translated into an addressable phone number. Addressable or dialable phone numbers (which this document does not define) are defined in other documents, such as GSTN address [RFC3191] or telephone URL [RFC2806].
これらのヘッダーの意図はかかってきた電話と共にアナログの電話システムによって変更も解釈なしで送られる電話番号を記録することです。 十分であるなら、意味的であるのは、知られているか、または推論されていて、これがNumberingPlan分野に含まれるかもしれないということであるかもしれません。 これは、それが後でアドレス可能な電話番号に翻訳されるのを許容するかもしれません。 アドレス可能であるか「ダイヤル-可能」な電話番号(このドキュメントが定義しない)は他のドキュメントで定義されます、GSTNアドレス[RFC3191]や電話URL[RFC2806]のように。
Parsons & Maruszak Standards Track [Page 6] RFC 3939 Calling Line Identification December 2004
回線識別を2004年12月と呼ぶパーソンズとMaruszak標準化過程[6ページ]RFC3939
6.2. Usage
6.2. 用法
There are a few scenarios of how this mechanism may fail that must be considered. The first is mentioned in section 3.2 - the truncation of an international number to 10 digits. This could result in a misinterpretation of the resulting number. For instance, an international number (e.g., from Ireland) of the form "353 91 73 3307" could be truncated to "53 91 73 3307" if received in North America, and interpreted as "539 917 3307" - a seemingly "North American" style number. Thus, the recipient is left with incorrect information to reply to the message, possibly with an annoyed callee at the North American number.
考えなければならないこのメカニズムがどう失敗するかもしれないかに関するいくつかのシナリオがあります。 セクション3.2で1番目は言及されます--10ケタへの国際的な数のトランケーション。 これは結果として起こる数の誤解をもたらすかもしれません。 例えば、フォームの国際的な数(例えば、アイルランドからの)、「353、91 73 3307、」、北アメリカに受け取られて、解釈されるなら「53 91 73 3307」に先端を切られるかもしれない、「539 917外観上a3307インチ--「ノース・アメリカン」スタイル番号。 したがって、不正確な情報と共に受取人がメッセージに答えるのが残されます、ことによると北米の数におけるいらいらしている訪問される人で。
The second scenario is the possibility of sending an internal extension to an external recipient when a Call Answer message is forwarded. This poses two problems, the recipient is given the wrong phone number, and the company's dialing plan could be exposed.
2番目のシナリオはCall Answerメッセージを転送するとき内部の拡大を外部の受取人に送る可能性です。 これは2つの問題を引き起こします、そして、間違った電話番号を受取人に与えます、そして、会社がプランにダイヤルするのを露出できました。
The final concern deals with exercising character options that are available in coding the Calling Name field. An international system may send a message with coding options that are not available on the receiving system, thus giving the recipient an incorrect Caller Name.
Calling Name分野をコード化するのに利用可能なキャラクタオプションを訓練するとの最終的な関心取引。 国際的なシステムは受電方式の上で利用可能でないコード化オプションと共にメッセージを送るかもしれません、その結果、不正確なCaller Nameを受取人に与えます。
7. Security Considerations
7. セキュリティ問題
Note that unlisted and restricted numbers are not a concern as these header fields are defined to contain what the called party would see (e.g., 'Private Name'), as opposed to the complete details exchanged between service providers.
それが非記載して、これらのヘッダーフィールドが定義されるとき制限された数が関心でないことに注意して、サービスプロバイダーの間で交換されたきわめて詳細な情報と対照的に被呼者が見るもの(例えば、'個人的なName')を含んでください。
However, it must also be noted that this mechanism allows the explicit indication of phone numbers in the headers of an email message (used to store voice messages). While the rationale for this is reviewed in section 1, the recipient of this message may not be aware that this information is contained in the headers unless the user's client presents the information. Its use is intended to be informative as it is when it appears on a telephone screen.
しかしながら、また、このメカニズムがメールメッセージ(以前はよく音声メールを格納していた)のヘッダーの電話番号の明白なしるしを許容することに注意しなければなりません。 これのための原理がセクション1で見直される間、このメッセージの受取人はユーザのクライアントが情報を提示しない場合この情報がヘッダーに含まれているのを意識していないかもしれません。 それが電話スクリーンに現れる時であるときに使用が有益であることを意図します。
8. IANA Considerations
8. IANA問題
This document defines an IANA-administered registration space for Caller-ID numbering plans in section 5.1. Each registry entry consists of an identifying token and a short textual description of the entry. There are three initial entries in this registry:
このドキュメントは発信番号表示付番プランのためにセクション5.1でIANAによって管理された登録スペースを定義します。 それぞれの登録エントリーはエントリーの特定象徴と短い原文の記述から成ります。 3つの初期のエントリーがこの登録にあります:
unknown - The number's semantics are unknown. This value is the default in the absence of this parameter.
未知--数の意味論は未知です。 この値はこのパラメタがないときデフォルトです。
Parsons & Maruszak Standards Track [Page 7] RFC 3939 Calling Line Identification December 2004
回線識別を2004年12月と呼ぶパーソンズとMaruszak標準化過程[7ページ]RFC3939
local - The number only has meaning within the domain of the sending system identified by the RFC 2822 From field of the message.
ローカル--数で、メッセージのRFC2822From分野で送付システムのドメインの中の意味を特定するだけです。
e164 - The number's semantics are described in [E.164].
e164--数の意味論は[E.164]で説明されます。
The only way to add additional entries (ietf-token in section 5.1) to this registry is with a standards-track RFC.
追加エントリー(セクション5.1でのietf-象徴)をこの登録に加える唯一の方法が標準化過程RFCと共にあります。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[VPIMV2R2] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail - version 2 (VPIMv2)", RFC 3801, June 2004.
[VPIMV2R2] ボードルイ、G.、およびG.パーソンズ、「インターネットメールのためにProfileを声に出してください--バージョン2(VPIMv2)」、RFC3801、6月2004日
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text ", RFC 2047, November 1996.
[RFC2047]ムーア、K.、「パートThreeをまねてください(マルチパーパスインターネットメールエクステンション)」 「非ASCIIテキストのためのメッセージヘッダー拡張子」、RFC2047、1996年11月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC2234] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
9.2. Informative References
9.2. 有益な参照
[RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076, February 1997.
[RFC2076] パルメ、J.、「一般的なインターネットメッセージヘッダー」、RFC2076、1997年2月。
[E.164] ITU-T Recommendation E.164 (1997), "The international public telecommunication numbering plan"
[E.164]ITU-T Recommendation E.164(1997)、「国際的な公共の電気通信付番プラン」
[T.50] ITU-T Recommendation T.50 (1992), "International Reference Alphabet (IRA)"
[T.50]ITU-T推薦T.50(1992)、「国際参照アルファベット(IRA)」
[T.61] CCITT Recommendation T.61 (1988) (Withdrawn), "Character Repertoire and Coded Character Sets for the International Teletex Service"
[T.61]CCITT推薦T.61(1988)(引き下がります)と、「国際テレテックスサービスのためのキャラクターレパートリーとコード化文字集合」
Parsons & Maruszak Standards Track [Page 8] RFC 3939 Calling Line Identification December 2004
回線識別を2004年12月と呼ぶパーソンズとMaruszak標準化過程[8ページ]RFC3939
[8859-1] ISO/IEC International Standard 8859-1 (1998), Information Technology _ 8-bit single-byte coded graphic character sets _ Part 1: Latin Alphabet No. 1
[8859-1] ISO/IEC国際規格8859-1(1998)、コード化された情報のTechnologyの_の8ビットの単一のバイト図形文字は_Part1を設定します: ローマ字No.1
[ASCII] American National Standards Institute (ANSI), Coded Character Set - 7-Bit American National Standard Code for Information Interchange, ANSI X3.4, 1986.
[ASCII]American National Standards Institut(ANSI)、7ビットの情報交換用米国標準コード、ANSI X3.4、コード化文字集合--1986。
[T1.401] American National Standards Institute (ANSI), Telecommunications _ Network-to-Customer Installation Interfaces _ Analog Voicegrade Switched Access Lines with Calling Number Delivery, Calling Name Delivery, or Visual Message-Waiting Indicator Features, ANSI T1.6401.03-1998
[T1.401]American National Standards Institut(ANSI)、配送に数に電話をするのにテレコミュニケーション_ネットワークから顧客へのインストールインタフェース_アナログVoicegradeはアクセス回線を切り換えました、名前配送、または視覚通話待ち指示器を特徴と呼んで、ANSI T1.6401.03-1998
[T1.625] American National Standards Institute (ANSI), Telecommunications - Integrated Services Digital Network (ISDN) _ Calling Line identification Presentation and Restriction Supplementary Services, ANSI T1.625-1993
[T1.625]American National Standards Institut(ANSI)、Telecommunications--統合Services Digital Network(ISDN)_Calling線識別のPresentationとRestriction Supplementary Services、ANSI T1.625-1993
[T1.641] American National Standards Institute (ANSI), Telecommunications - Calling Name Identification Presentation, ANSI T1.641-1995
[T1.641]American National Standards Institut(ANSI)、テレコミュニケーション--名前識別をプレゼンテーション、ANSI T1.641-1995と呼ぶこと。
[GR-1188-CORE] Telcordia Technologies, "CLASS Feature: Calling Name Delivery Generic Requirements", GR-1188-CORE, Issue 2, December 2000
[GR1188コア] Telcordia技術、「クラスは以下を特集します」。 「名前配送を一般的な要件と呼びます」、GR1188コア、問題2、2000年12月
[GR-31-CORE] Telcordia Technologies, "CLASS Feature: Calling Number Delivery", GR-31-CORE, Issue 1, June 2000
[GR31コア] Telcordia技術、「クラスは以下を特集します」。 「配送に数に電話をします」、GR31コア、問題1、2000年6月
[RFC3191] Allocchio, C., "Minimal GSTN address format in Internet Mail", RFC 3191, October 2001.
[RFC3191] Allocchio、C.、「インターネットメールにおける最小量のGSTNアドレス形式」、RFC3191、2001年10月。
[RFC2806] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April 2000.
[RFC2806] Vaha-Sipila、A.、「通話のためのURL」、RFC2806、2000年4月。
10. Acknowledgments
10. 承認
The previous authors of versions of this document were Derrick Dunne and Jason Collins. The current authors would like to thank Derrick and Jason for their contributions.
このドキュメントのバージョンの前の作者は、Derrickダンとジェイソン・コリンズでした。 現在の作者は彼らの貢献についてDerrickとジェイソンに感謝したがっています。
Parsons & Maruszak Standards Track [Page 9] RFC 3939 Calling Line Identification December 2004
回線識別を2004年12月と呼ぶパーソンズとMaruszak標準化過程[9ページ]RFC3939
Authors' Addresses
作者のアドレス
Glenn Parsons Nortel Networks P.O. Box 3511, Station C Ottawa, ON K1Y 4H7
グレンノーテル教区牧師は私書箱3511、駅のCオタワをK1Y 4H7にネットワークでつなぎます。
Phone: +1-613-763-7582 EMail: gparsons@nortelnetworks.com
以下に電話をしてください。 +1-613-763-7582 メールしてください: gparsons@nortelnetworks.com
Janusz Maruszak
ヤヌシMaruszak
Phone: +1-416-885-0221 EMail: jjmaruszak@sympatico.ca
以下に電話をしてください。 +1-416-885-0221 メールしてください: jjmaruszak@sympatico.ca
Parsons & Maruszak Standards Track [Page 10] RFC 3939 Calling Line Identification December 2004
回線識別を2004年12月と呼ぶパーソンズとMaruszak標準化過程[10ページ]RFC3939
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(2004)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Parsons & Maruszak Standards Track [Page 11]
パーソンズとMaruszak標準化過程[11ページ]
一覧
スポンサーリンク