[要約] RFC 3939は、音声メールメッセージの発信元番号識別に関する規格であり、要約すると、音声メールメッセージにおいて発信元番号を識別するための方法を提供しています。この規格の目的は、音声メールメッセージの発信元を正確に識別することにより、通信の信頼性とセキュリティを向上させることです。
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 という 2 つの新しいヘッダー フィールドが定義されています。Caller_id は、受信者がメッセージの送信者にコールバックまたは返信するために十分な情報を保存するために使用されます。Caller-name には、メッセージを送信する人の名前が表示されます。
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" <non-mail-user@host> 2. 差出人: "John Doe" <4165551234@host> 3. 差出人: 不明:;
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] では現在、発信者の電話番号を保持するインターネット メッセージ ヘッダーとして「phone」をリストしていますが、これは「非標準」としてリストされています。つまり、このヘッダーの使用は一般に推奨されません。また、フォーマットも定義されていないため、情報を解析できません。発信者の名前に類似したエントリはありません。
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].
この文書のキーワード「しなければならない」、「してはならない」、「必須」、「しなければならない」、「してはならない」、「すべきである」、「すべきではない」、「推奨」、「してもよい」、「任意」は次のとおりです。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.
Calling Line Identification ヘッダー (「Caller-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」パラメータを使用してもよい(MAY)。
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.
ただし、企業電話システムでは、これより長い番号のサポートがサポートされている場合があります。
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」パラメータを使用してもよい(MAY)。定義されているセマンティクスは、「unknown」、「local」、および「e164」の 3 つだけです。「unknown」は、番号計画のセマンティクスが不明な場合のデフォルトです (パラメータが存在しない場合のデフォルト)。「ローカル」は、メッセージを保存したボイス メール システムのドメイン内でのみ意味を持ちます (つまり、ボイス メール システムは、その番号がローカル番号計画に属していることを認識しています)。「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] に従って、電話システムによって発呼者の電話番号とともに含められる場合があります。この情報を保持する既存の「Date」インターネットヘッダーがあるため、これを使用してもよい(MAY)。「Date」ヘッダーにこの時刻を記録するか、ローカル システム時刻を記録するかは、ローカルの実装によって決定されます。
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 つで送信される可能性があります。これらには次のものが含まれます。
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]
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] で定義されているネイティブ文字セットを使用して保存してもよい(MAY)。
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 文字を超えてはなりません (MUST NOT)。ただし、サービス プロバイダーは、[T1.401] や [GR-1188-CORE] など、顧客の機器に配信するためにこれを 15 文字にさらに制限することを選択する場合があります。
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] で説明されている拡張された Backus-Naur Form (BNF) を使用した構文仕様に従います。これらのヘッダーのセマンティクスはセクション 4 と 5 で定義されていますが、構文では [RFC2822] で定義されている「非構造化」トークンが使用されます。
unstructured = *([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.>
x-token := <The two characters "X-" or "x-" followed, with
no intervening white space, by any token>
"Caller-Name" ":" unstructured CRLF
To: +19725551212@vm1.example.com
Caller-ID: 6137684087
Caller-Name: Derrick Dunne
To: 6137637582@example.com Caller-ID: 6139416900 Caller-Name: Jean Chretien
宛先: 6137637582@example.com 発信者 ID: 6139416900 発信者名: Jean Chretien
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.
このメカニズムがどのように失敗するかを考慮する必要があるシナリオがいくつかあります。1 つ目は、セクション 3.2 で説明されています。国際番号の 10 桁への切り捨てです。これにより、結果の数値が誤って解釈される可能性があります。たとえば、「353 91 73 3307」という形式の国際番号（アイルランド発など）は、北米で受信すると「53 91 73 3307」に切り詰められ、「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 番目のシナリオは、通話応答メッセージが転送されるときに内部内線番号が外部受信者に送信される可能性です。これには 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.
local - この番号は、メッセージの RFC 2822 From フィールドで識別される送信システムのドメイン内でのみ意味を持ちます。
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-token) を追加する唯一の方法は、standards-track RFC を使用することです。
[VPIMV2R2] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail - version 2 (VPIMv2)", RFC 3801, June 2004.
[VPIMV2R2] Vaudreuil、G. および G. Parsons、「インターネット メールの音声プロファイル - バージョン 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] Moore, K.、「MIME (多目的インターネットメール拡張) パート 3: 非 ASCII テキストのメッセージ ヘッダー拡張」、RFC 2047、1996 年 11 月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822] Resnick, P.、「インターネット メッセージ フォーマット」、RFC 2822、2001 年 4 月。
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC2234] Crocker, 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] Bradner, S.、「要件レベルを示すために RFC で使用するキーワード」、BCP 14、RFC 2119、1997 年 3 月。
[RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076, February 1997.
[RFC2076] Palme, J.、「Common Internet Message Headers」、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: ラテン文字 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] 米国規格協会 (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] 米国規格協会 (ANSI)、電気通信 _ ネットワークから顧客への設置インターフェイス _ 発信番号配信、発信者名配信、またはビジュアル メッセージ待機インジケータ機能を備えたアナログ音声グレード交換アクセス回線、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 機能: Calling Name Delivery Generic Requirements」、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、「CLASS 機能: 発信番号配信」、GR-31-CORE、第 1 号、2000 年 6 月
[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-Spila, A.、「電話通話の URL」、RFC 2806、2000 年 4 月。
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 Dunne と Jason Collins でした。現在の著者は、Derrick と Jason の貢献に感謝したいと思います。
Authors' Addresses
著者の住所
Glenn Parsons Nortel Networks P.O. Box 3511, Station C Ottawa, ON K1Y 4H7
グレン・パーソンズ ノーテル・ネットワークス P.O.ボックス 3511、ステーション C、オタワ、ON K1Y 4H7
Phone: +1-613-763-7582
EMail: gparsons@nortelnetworks.com
Janusz Maruszak
ヤヌシュ・マルザク
Phone: +1-416-885-0221
EMail: 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.
この文書およびここに含まれる情報は「現状のまま」で提供され、寄稿者、寄稿者が代表または後援する組織（存在する場合）、インターネット協会およびインターネット エンジニアリング タスク フォースは、明示的または明示的または明示的に、すべての保証を否認します。ここに記載された情報の使用がいかなる権利も侵害しないことの黙示的な保証、または商品性や特定の目的への適合性の黙示的な保証を含みますが、これに限定されません。
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.
IETF 事務局に提出された IPR 開示のコピー、および利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような所有権の使用に対する一般ライセンスまたは許可を取得しようとする試みの結果を入手できます。IETF オンライン IPR リポジトリ (http://www.ietf.org/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 (ietf-ipr@ietf.org) に送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC エディター機能の資金は現在、インターネット協会によって提供されています。