Network Working Group G. Parsons
Request for Comments: 3939 J. Maruszak
Category: Standards Track Nortel Networks
December 2004
Calling Line Identification for Voice Mail Messages
Status of this 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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（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.
この文書は、保存されたボイスメールメッセージのヘッダに起因する発信者を特定するための方法を説明します。 Caller_IDとCalled_Name：二つの新しいヘッダフィールドは、この目的のために定義されています。 Caller_idは、受信者がコールバックするために十分な情報を格納する、またはメッセージの送信者に返信するために使用されます。発信者名は、メッセージを送信者の名前を提供します。
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
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メッセージのフォーマットは、すなわち、インターネットメールメッセージストアで「コール回答」の音声メッセージを格納するために使用される場合に使用することを意図され、発呼者は呼び出しに応答することができませんでした受信者のための音声メッセージを残します。含意は、発信者のために知られているいかなるRFC 2822アドレスがないことです。
[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.から： "416 555 1234" <非メールのユーザ@ホスト> 2.：3. "ジョン・ドウ" <ホスト@ 4165551234>：不明:;
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).
これらのいずれかが強制的に翻訳したものですので、操作を行わずに、着信側への電話システムによって提示されるように、発呼者の名前と電話番号を保存するために有用であろう。これは、発呼者の情報は（電話に表示されて、それに似た）受信者に表示され、また、発信者（存在する場合）のためのインターネット・アドレスの今後の決意を許可することができるようになります。そこにこの情報は、着信側に提示されていないとして、（例えば、数のタイプは、プレゼンテーションが制限）のメタデータを格納するためには要求されないとメールシステムを声に一般的に利用できないことに注意してください。意図は、アナログ（非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").
2つの新しいメッセージヘッダフィールドは、この情報、すなわち呼び出しライン識別（「発信者ID」）と、発信者名（「発信者名」）を保持するために含まれることが提案されています。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、[RFC2119]に記載されているように解釈されます。
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.
呼び出しライン識別ヘッダー（「発信者ID」）は、コールバック、またはメッセージの送信者に返信するには、受信者のボイスメールシステムのための十分な情報を保持しています。このヘッダに含まれている番号は、電話システムによって供給されます。受信したデータの正確なフォーマットは、呼のタイプに依存し、それは、 - 内部または外部の呼び出し。
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」パラメータは、セマンティックを示すために使用されるかもしれません。
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.
内線通話の場合（例えば、同一企業内の二つの拡張の間）、会社のダイヤルプランに基づいて、発呼者の拡張子だけを、リレーするのに十分です。
However, the support of longer numbers may be supported by the enterprise phone system.
しかし、長い数字のサポートは、企業の電話システムによってサポートされてもよいです。
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]で説明したように、発呼者の数は、完全な国際的な数でなければならない、すなわち、国コード（CC）、ナショナル宛先コード（NDC）、およびサブスクライバ番号（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.
非アナログシステム（例えば、サブアドレス、リダイレクト数）、ならびにメタデータが利用可能な他の定義されたフィールドは、このヘッダに格納することを意図するものではないことに留意されたいです。
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-」は、企業やサービス固有のダイヤルプランを示すために使用することができます。
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]あたりの発呼者の電話番号と電話システムによって含まれることができます。この情報を保持するために、既存の「日付」のインターネットヘッダーがあり、これは、使用されるかもしれません。今回は、ローカルシステム時刻が「日付」ヘッダに記録されるかどうか地元の実装決定です。
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]あたりのサービス・プロバイダ・オプションです。発信者の名前がサービスプロバイダーのシグナリング輸送（例えば、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）国際リファレンスアルファベット（IRA）、旧国際アルファベット5番またはIA5 [T.50] 2）ラテンアルファベット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文字セットは、国内およびアプリケーション指向のバージョンを指定するに役立つ多くのオプションが含まれています。これらのオプションを使用するには、当事者間の合意がない場合、7ビットの文字セットがしたIRA、T.61、およびASCIIのグラフィック文字がまったく同じコード化されている、と想定されます。さらに、[8859]の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文字で表されています。 [RFC2047]で定義されるようしかし、名前を受信した場合、7ビットのASCIIで表現することができない、それが設定された固有の文字を使用して格納されてもよいです。
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]にこれを制限することを選択することができます。
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]に記載されているように拡張バッカスナウア記法（BNF）を使用して構文仕様に従います。これらのヘッダーのセマンティクスはセクション4および5に定義されているが、構文は[RFC2822]で定義された「非構造化」トークンを使用しています。
unstructured = *([FWS] utext) [FWS]
構造化されていない= *（[FWS]のutext）FWS]
"Caller-ID" ":" 1*DIGIT [ "," "NumberingPlan="
( "unknown" / "local" / "e164" / ietf-token / x-token ) ] CRLF
ietf-token := <An extension token defined by a standards-track RFC and registered with IANA.>
= <拡張トークンは標準トラックRFCで定義され、IANAに登録。>：トークンIETF
x-token := <The two characters "X-" or "x-" followed, with no intervening white space, by any token>
X-トークン：= <2つの文字「X-」または「X-」は、任意のトークンによって、介在しない空白で、続きます>
"Caller-Name" ":" unstructured CRLF
「発信者名」「：」非構造化CRLF
To: +19725551212@vm1.example.com
Caller-ID: 6137684087
Caller-Name: Derrick Dunne
To: 6137637582@example.com Caller-ID: 6139416900 Caller-Name: Jean Chretien
To：6137637582@example.com発信者ID：6139416900発信者名：クレティエン
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]などの他の文書で定義されています。
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.
考えなければならないこのメカニズムは失敗する可能性がどのようにいくつかのシナリオがあります。 10桁の国際数の切り捨て - 最初は、セクション3.2に記載されています。これは、結果の数の誤った解釈につながる可能性があります。一見「北 - フォームのインスタンス、国際番号（例えば、アイルランド）は、「91 73 3307 353」「91 73 3307 53」北米で受信し、「539 917 3307」として解釈場合に切り捨てられることができアメリカの」スタイルナンバー。したがって、受信者は、おそらく北米の数でイライラ呼び出し先で、メッセージに返信するために誤った情報が残されています。
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のシナリオは、コール応答メッセージが転送されるときに、外部の受信者に内線を送信する可能性があります。これは、受信者が間違った電話番号を与えられ、会社のダイヤルプランが露出することができ、二つの問題を提起します。
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.
最後の懸念は、発信者名フィールドのコーディングで使用可能な文字オプションの行使を扱っています。国際システムは、このように、受信者、誤った発信者名を与えて、受信側システムで使用できないオプションをコーディングしてメッセージを送信することができます。
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.
サービスプロバイダ間で交換完全な詳細とは対照的に、これらのヘッダーフィールドは、着信側が（例えば、「プライベート名」）見るもの含むように定義されているとして、非上場と制限された数字は問題ではないことに注意してください。
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で検討されている間、このメッセージの受信者は、ユーザーのクライアントが情報を提示しない限り、この情報はヘッダに含まれていることを認識していなくてもよいです。それが電話画面に表示されたときにそれがあるとして、その使用は、有益であることを意図しています。
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節での発信者IDの番号計画のためのIANA投与登録スペースを定義します。各レジストリエントリは、エントリの識別トークンと短いテキスト記述から構成されています。このレジストリ内の3件の初期のエントリーがあります。
unknown - The number's semantics are unknown. This value is the default in the absence of this parameter.
不明 - 番号の意味は不明です。この値は、このパラメータが存在しない場合のデフォルトです。
local - The number only has meaning within the domain of the sending system identified by the RFC 2822 From field of the message.
ローカル - メッセージの分野から、RFC 2822で識別される送信側システムのドメイン内で意味を持つだけの数。
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です。
[VPIMV2R2] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail - version 2 (VPIMv2)", RFC 3801, June 2004.
[VPIMV2R2]ヴォードルイユ、G.とG.パーソンズ、 "インターネットメール用の音声プロファイル - バージョン2（VPIMv2）"、RFC 3801、2004年6月。
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text ", RFC 2047, November 1996.
[RFC2047]ムーア、K.、 "MIME（多目的インターネットメール拡張）パート3：非ASCIIテキストのためのメッセージヘッダの拡張"、RFC 2047、1996年11月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822]レズニック、P.、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC2234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 2234、1997年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076, February 1997.
[RFC2076]パルメ、J.、 "一般的なインターネットメッセージヘッダ"、RFC 2076、1997年2月。
[E.164] ITU-T Recommendation E.164 (1997), "The international public telecommunication numbering plan"
[E.164] ITU-T勧告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）（撤回）、「国際テレテックスサービスのための文字レパートリ及び符号化文字集合」
[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）、情報技術_ 8ビットのシングルバイトコード化されたグラフィック文字セット_パート1：ラテンアルファベット1号
[ASCII] American National Standards Institute (ANSI), Coded Character Set - 7-Bit American National Standard Code for Information Interchange, ANSI X3.4, 1986.
[ASCII]米国規格協会（ANSI）、コード化文字セット - 情報交換、ANSI X3.4、1986年のための7ビットの米国標準コード。
[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]米国規格協会（ANSI）は、電気通信_ネットワーク・ツー・カスタマーインストールインターフェイス_アナログVoicegradeは名前配達、またはVisualメッセージ待機インジケータ機能、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]米国規格協会（ANSI）、通信 - 統合サービスデジタル網（ISDN）_発呼回線識別と制限付加サービス、ANSI T1.625-1993
[T1.641] American National Standards Institute (ANSI), Telecommunications - Calling Name Identification Presentation, ANSI T1.641-1995
[T1.641]米国規格協会（ANSI）、通信 - 発信者名識別プレゼンテーション、ANSI T1.641-1995
[GR-1188-CORE] Telcordia Technologies, "CLASS Feature: Calling Name Delivery Generic Requirements", GR-1188-CORE, Issue 2, December 2000
[GR-1188-CORE]のTelcordia Technologies社、 "CLASS特集：発信者名配達ジェネリック要件"、GR-1188-CORE、2号、2000年12月
[GR-31-CORE] Telcordia Technologies, "CLASS Feature: Calling Number Delivery", GR-31-CORE, Issue 1, June 2000
[GR-31-CORE]のTelcordia Technologies社、：、GR-31-CORE、1号、2000年6月 "CLASS機能ナンバー配信を呼び出します"
[RFC3191] Allocchio, C., "Minimal GSTN address format in Internet Mail", RFC 3191, October 2001.
[RFC3191] Allocchio、C.、 "インターネットメールにおける最小GSTNアドレス形式"、RFC 3191、2001年10月。
[RFC2806] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April 2000.
[RFC2806] Vaha-Sipila、A.、2000年4月、RFC 2806、 "電話のURLを呼び出します"。
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.
このドキュメントのバージョンの以前の著者は、デリックダンとジェイソン・コリンズでした。現在の作者は彼らの貢献のためにデリックとJasonに感謝したいと思います。
Authors' Addresses
著者のアドレス
Glenn Parsons Nortel Networks P.O. Box 3511, Station C Ottawa, ON K1Y 4H7
グレン・パーソンズNortel Networksの私書箱K1Y 4H7のボックス3511、駅のCオタワ、
Phone: +1-613-763-7582 EMail: gparsons@nortelnetworks.com
電話：+ 1-613-763-7582 Eメール：gparsons@nortelnetworks.com
Janusz Maruszak
ヤヌシュMaruszak
Phone: +1-416-885-0221 EMail: jjmaruszak@sympatico.ca
電話：+ 1-416-885-0221 Eメール：jjmaruszak@sympatico.ca
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004).
著作権（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 IETF文書の権利に関するIETFの手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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機能のための基金は現在、インターネット協会によって提供されます。