RFC3939 日本語訳

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ページ]