[要約] RFC 3966は、電話番号のためのtel URIの仕様を定めたものであり、要約すると以下のようになります。1. RFC 3966は、電話番号を表すためのURIスキームであるtel URIの仕様を提供しています。 2. この仕様は、電話番号を一意に識別し、通信プロトコルに関係なく電話番号を扱うための方法を提供します。 3. 目的は、電話番号の一貫性と相互運用性を確保し、電話番号をURIとして使用するための標準化を促進することです。
Network Working Group H. Schulzrinne
Request for Comments: 3966 Columbia University
Obsoletes: 2806 December 2004
Category: Standards Track
The tel URI for Telephone Numbers
電話番号のTEL URI
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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状況については、「Internet Official Protocol Standards」（STD 1）の現在の版を参照してください。このメモの分布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット社会（2004）。
Abstract
概要
This document specifies the URI (Uniform Resource Identifier) scheme "tel". The "tel" URI describes resources identified by telephone numbers. This document obsoletes RFC 2806.
このドキュメントはURI（Uniform Resource Identifier）スキーム "Tel"を指定します。「Tel」URIは、電話番号で識別されるリソースを記述します。この文書はRFC 2806を廃止します。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. URI Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. URI Comparisons . . . . . . . . . . . . . . . . . . . . . . . 6
5. Phone Numbers and Their Context . . . . . . . . . . . . . . . 6
5.1. Phone Numbers. . . . . . . . . . . . . . . . . . . . . 6
5.1.1. Separators in Phone Numbers . . . . . . . . . . 7
5.1.2. Alphabetic Characters Corresponding to Digits . 7
5.1.3. Alphabetic, *, and # Characters as Identifiers. 7
5.1.4. Global Numbers. . . . . . . . . . . . . . . . . 7
5.1.5. Local Numbers . . . . . . . . . . . . . . . . . 8
5.2. ISDN Subaddresses. . . . . . . . . . . . . . . . . . . 9
5.3. Phone Extensions . . . . . . . . . . . . . . . . . . . 10
5.4. Other Parameters . . . . . . . . . . . . . . . . . . . 10
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Why Not Just Put Telephone Numbers in SIP URIs?. . . . 11
7.2. Why Not Distinguish between Call Types?. . . . . . . . 11
7.3. Why tel. . . . . . . . . . . . . . . . . . . . . . . . 11
7.4. Do Not Confuse Numbers with How They Are Dialed. . . . 11
8. Usage of Telephone URIs in HTML . . . . . . . . . . . . . . . 11
9. Use of "tel" URIs with SIP (Informative). . . . . . . . . . . 12
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
11. Security Considerations . . . . . . . . . . . . . . . . . . . 14
12. Changes Since RFC 2806. . . . . . . . . . . . . . . . . . . . 14
13. References. . . . . . . . . . . . . . . . . . . . . . . . . . 15
13.1. Normative References . . . . . . . . . . . . . . . . . 15
13.2. Informative References . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 17
This document defines the URI scheme "tel", which describes resources identified by telephone numbers. A telephone number is a string of decimal digits that uniquely indicates the network termination point. The number contains the information necessary to route the call to this point. (This definition is derived from [E.164] but encompasses both public and private numbers.)
このドキュメントは、電話番号によって識別されるリソースを記述するURIスキーム「Tel」を定義します。電話番号は、ネットワーク終端点を一意に示す10進数の文字列です。この数には、この点に電話をルーティングするために必要な情報が含まれています。（この定義は[E.164]から派生していますが、パブリック番号とプライベート番号の両方を含みます。）
The termination point of the "tel" URI telephone number is not restricted. It can be in the public telephone network, a private telephone network, or the Internet. It can be fixed or wireless and address a fixed wired, mobile, or nomadic terminal. The terminal addressed can support any electronic communication service (ECS), including voice, data, and fax. The URI can refer to resources identified by a telephone number, including but not limited to originators or targets of a telephone call.
「Tel」URI電話番号の終点は制限されていません。公衆電話網、民間電話網、またはインターネットに入ることができます。固定または無線で、固定有線、モバイル、または遊牧民端末に対処することができます。アドレス指定された端末は、音声、データ、およびファックスを含む任意の電子通信サービス（EC）をサポートすることができる。URIは、電話番号によって識別されるリソースを参照することができ、これに限定されないが、電話のターゲットまたはターゲットを含む。
The "tel" URI is a globally unique identifier ("name") only; it does not describe the steps necessary to reach a particular number and does not imply dialling semantics. Furthermore, it does not refer to a specific physical device, only to a telephone number.
「Tel」URIは、グローバルに一意の識別子（「名前」）のみです。特定の数字に到達するために必要な手順を説明しておらず、ダイヤルの意味論を意味しません。さらに、特定の物理デバイスは電話番号のみ参照されません。
As commonly understood, telephone numbers comprise two related but distinct concepts: a canonical address-of-record and a dial string. We define the concepts below:
一般的に理解されているように、電話番号は2つの関連するが明確な概念を含む。以下の概念を定義します。
Address-of-record or identifier: The telephone number is understood here as the canonical address-of-record or identifier for a termination point within a specific network. For the public network, these numbers follow the rules in E.164 [E.164], while private numbers follow the rules of the owner of the private numbering plan. Subscribers publish these identifiers so that they can be reached, regardless of the location of the caller. (Naturally, not all numbers are reachable from everywhere, for a variety of technical and local policy reasons. Also, a single termination point may be reachable from different networks and may have multiple identifiers.)
記録アドレスまたは識別子：電話番号は、特定のネットワーク内の終端点の標準的な記録アドレスまたは識別子としてここで理解されています。パブリックネットワークの場合、これらの数はE.164 [E.164]の規則に従いますが、プライベート番号はプライベートナンバーリングプランの所有者の規則に従います。加入者はこれらの識別子を公開して、発信者の場所に関係なく、それらが到達できるようにします。（当然のことながら、すべての数字が至る所から到達可能ではない、さまざまな技術的および地域の政策上の理由から、至る所から到達可能ではありません。また、単一の終了点は異なるネットワークから到達可能であり、複数の識別子を持つことができます。）
Dial string: "Dial strings" are the actual numbers, symbols, and pauses entered by a user to place a phone call. A dial string is consumed by one or more network entities and understood in the context of the configuration of these entities. It is used to generate an address-of-record or identifier (in the sense described above) so that a call can be routed. Dial strings may require prepended digits to exit the private branch exchange (PBX) the end system is connected to, and they may include post-dial dual-tone multi-frequency (DTMF) signaling that could control an interactive voice response (IVR) system or reach an extension. Dial strings are beyond the scope of this document.
ダイヤル文字列：「ダイヤル文字列」は、電話をかけるためにユーザーが入力した実際の数字、記号、および一時停止です。ダイヤル文字列は、1つ以上のネットワークエンティティによって消費され、これらのエンティティの構成のコンテキストで理解されています。それは、呼をルーティングすることができるように記録アドレスまたは識別子（上述の意味で）を生成するために使用される。ダイヤル文字列には、エンドシステムが接続されているプライベートブランチ交換（PBX）が接続されており、インタラクティブボイスレスポンス（IVR）システムを制御できるダイヤルダイヤルデュアルトーンマルチ周波数（DTMF）シグナリングを含めることができます。または拡張子に到達する。ダイヤル文字列はこの文書の範囲を超えています。
Both approaches can be expressed as a URI. For dial strings, this URI is passed to an entity that can reproduce the actions specified in the dial string. For example, in an analog phone system, a dialer translates the dial string into a sequence of actions such as waiting for dial tone, sending DTMF digits, pausing, and generating post-dial DTMF digits after the callee picks up. In an integrated services digital network (ISDN) or ISDN user part (ISUP) environment, the signaling elements that receive protocol messages containing the dial string perform the appropriate protocol actions. As noted, this approach is beyond the scope of this specification.
両方のアプローチはURIとして表現することができる。ダイヤル文字列の場合、このURIはダイヤル文字列で指定されたアクションを再現できるエンティティに渡されます。たとえば、Analog Phoneシステムでは、ダイヤラは、ダイヤルトーンがダイヤルトーンの待機、DTMFの数字の送信、一時停止、およびキャリーがピックアップされた後にポストダイヤルDTMF数字を生成するなどの一連のアクションに変換します。統合サービスデジタルネットワーク（ISDN）またはISDNユーザパート（ISUP）環境では、ダイヤル文字列を含むプロトコルメッセージを受信するシグナリング要素は適切なプロトコルアクションを実行します。述べたように、この方法はこの仕様の範囲を超えています。
The approach described here has the URI specify the telephone number as an identifier, which can be either globally unique or only valid within a local context. The dialling application is aware of the local context, knowing, for example, whether special digits need to be dialed to seize an outside line; whether network, pulse, or tone dialling is needed; and what tones indicate call progress. The dialling application then converts the telephone number into a dial sequence and performs the necessary signaling actions. The dialer does not have to be a user application as found in traditional desktop operating systems but could well be part of an IP-to-PSTN gateway.
ここで説明されているアプローチは、識別子として電話番号を指定しています。これは、グローバルに一意またはローカルコンテキスト内でのみ有効になることができます。ダイヤルアプリケーションは、例えば特別な桁をダイヤルする必要があるかどうかを知って、外線をつかむ必要があるかどうかを知っている。ネットワーク、パルス、トーンダイヤルが必要かどうか。そして、どのトーンが電話の進行状況を示しています。次に、ダイヤルアプリケーションは電話番号をダイヤルシーケンスに変換し、必要なシグナリング動作を実行します。ダイヤラは、従来のデスクトップオペレーティングシステムで見つかったユーザーアプリケーションである必要はありませんが、IPからPSTNゲートウェイの一部になる可能性があります。
To reach a telephone number from a phone on a PBX, for example, the user of that phone has to know how to convert the telephone number identifier into a dial string appropriate for that phone. The telephone number itself does not convey what needs to be done for a particular terminal. Instructions may include dialling "9" before placing a call or prepending "00" to reach a number in a foreign country. The phone may also need to strip area and country codes.
たとえば、PBX上の電話機から電話番号に到達するには、その電話機のユーザーは、電話番号識別子をその電話に適したダイヤル文字列に変換する方法を知る必要があります。電話番号自体は、特定の端末に対して何をする必要があるのかを伝えません。指示には、電話をかける前に「9」をダイヤルすること、または外国の数字に到達するために「00」を入力することが含まれます。電話機は、エリアと国のコードを削除する必要があるかもしれません。
The identifier approach described in this document has the disadvantage that certain services, such as electronic banking or voicemail, cannot be specified in a "tel" URI.
この文書に記載されている識別子アプローチは、電子バンキングやボイスメールなどの特定のサービスを「Tel」URIで指定できないという不都合がある。
The notation for phone numbers in this document is similar to that in RFC 3191 [RFC3191] and RFC 3192 [RFC3192]. However, the syntax differs as this document describes URIs whereas RFC 3191 and RFC 3192 specify electronic mail addresses. RFC 3191 and RFC 3192 use "/" to indicate parameters (qualifiers). Since URIs use the forward slash to describe path hierarchy, the URI scheme described here uses the semicolon, in keeping with Session Initiation Protocol (SIP) URI conventions [RFC3261].
この文書の電話番号の表記は、RFC 3191 [RFC3191]とRFC 3192 [RFC3192]の表記と似ています。ただし、このドキュメントはURIが説明されているので、RFC 3191とRFC 3192は電子メールアドレスを指定しています。RFC 3191およびRFC 3192は「/」を使用してパラメータ（修飾子）を示す。URIはPATH階層を説明するために順方向スラッシュを使用するので、ここで説明されているURIスキームはセミコロンを使用しています（Session Initiation Protocol）。
The "tel" URI can be used as a request URI in SIP [RFC3261] requests. The SIP specification also inherits the 'subscriber' part of the syntax as part of the 'user element' in the SIP URI. Other protocols may also use this URI scheme.
「Tel」URIは、SIP [RFC3261]要求のリクエストURIとして使用できます。SIP仕様は、SIP URIの「user要素」の一部として構文の「加入者」部分も継承します。他のプロトコルもこのURIスキームを使用することができる。
The "tel" URI does not specify the call type, such as voice, fax, or data call, and does not provide the connection parameters for a data call. The type and parameters are assumed to be negotiated either in-band by the telephone device or through a signaling protocol such as SIP.
「TEL」URIは、音声、ファックス、またはデータ呼び出しなどのコールタイプを指定しておらず、データコールの接続パラメータを提供しません。タイプとパラメータは、電話デバイスによって、またはSIPなどのシグナリングプロトコルを介してインバンド内のいずれかのインバンドのいずれかをネゴシエートすると仮定されます。
This document obsoletes RFC 2806.
この文書はRFC 2806を廃止します。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119, [RFC2119] and indicate requirement levels for compliant implementations.
この文書では、「必須」、「必須」、「SEQUR」、「しない」、「推奨する」、「推奨」、「5月」、「オプション」、「オプション」BCP 14、RFC 2119、[RFC2119]に記載されているように解釈され、準拠の実装のための要件レベルを示します。
The URI is defined using the ABNF (augmented Backus-Naur form) described in RFC 2234 [RFC2234] and uses elements from the core definitions (appendix A of RFC 2234).
URIは、RFC 2234 [RFC2234]に記載されているABNF（Augmented Backus-Naur形式）を使用して定義され、コア定義から要素を使用します（RFC 2234の付録A）。
The syntax definition follows RFC 2396 [RFC2396], indicating the actual characters contained in the URI. If the reserved characters "+", ";", "=", and "?" are used as delimiters between components of the "tel" URI, they MUST NOT be percent encoded. These characters MUST be percent encoded if they appear in tel URI parameter values.
構文定義はRFC 2396 [RFC2396]に続き、URIに含まれる実際の文字を示します。予約文字が ""、 ";"、 "="、および "？"の場合「Tel」URIのコンポーネント間の区切り文字として使用されます。それらはパーセントエンコードされてはなりません。これらの文字は、TEL URIパラメータ値に表示されている場合はパーセントエンコードされている必要があります。
Characters other than those in the "reserved" and "unsafe" sets (see RFC 2396 [RFC2396]) are equivalent to their "% HEX HEX" percent encoding.
"Reserved"セットと "Unsafe"セット（RFC 2396 [RFC2396]を参照）以外の文字は、それらの "％hex hex"パーセントエンコーディングと同じです。
The "tel" URI has the following syntax:
"Tel" URIには次の構文があります。
telephone-uri = "tel:" telephone-subscriber
telephone-subscriber = global-number / local-number
global-number = global-number-digits *par
local-number = local-number-digits *par context *par
par = parameter / extension / isdn-subaddress
isdn-subaddress = ";isub=" 1*uric
extension = ";ext=" 1*phonedigit
context = ";phone-context=" descriptor
descriptor = domainname / global-number-digits
global-number-digits = "+" *phonedigit DIGIT *phonedigit
local-number-digits =
*phonedigit-hex (HEXDIG / "*" / "#")*phonedigit-hex
domainname = *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum
/ alphanum *( alphanum / "-" ) alphanum
toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum
parameter = ";" pname ["=" pvalue ]
pname = 1*( alphanum / "-" )
pvalue = 1*paramchar
paramchar = param-unreserved / unreserved / pct-encoded
unreserved = alphanum / mark
mark = "-" / "_" / "." / "!" / "~" / "*" /
"'" / "(" / ")"
pct-encoded = "%" HEXDIG HEXDIG
param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$"
phonedigit = DIGIT / [ visual-separator ]
phonedigit-hex = HEXDIG / "*" / "#" / [ visual-separator ]
visual-separator = "-" / "." / "(" / ")"
alphanum = ALPHA / DIGIT
reserved = ";" / "/" / "?" / ":" / "@" / "&" /
"=" / "+" / "$" / ","
uric = reserved / unreserved / pct-encoded
Each parameter name ("pname"), the ISDN subaddress, the 'extension', and the 'context' MUST NOT appear more than once. The 'isdn-subaddress' or 'extension' MUST appear first, if present, followed by the 'context' parameter, if present, followed by any other parameters in lexicographical order.
各パラメータ名（ "PNAME"）、ISDNサブアドレス、 '拡張子'、および 'context'は複数回表示されてはいけません。'isdn-subaddress'または '拡張子'が存在する場合は、最初に表示され、続いて存在する場合は 'context'パラメータが続き、その後に辞書の順序で他のパラメータが続きます。
This simplifies comparison when the "tel" URI is compared character by character, such as in SIP URIs [RFC3261].
これにより、「Tel」URIがSIP URIS [RFC3261]などの文字別文字を比較すると、比較が簡単になります。
Two "tel" URIs are equivalent according to the following rules:
2つの「Tel」URIは、次の規則に従って同等です。
o Both must be either a 'local-number' or a 'global-number', i.e., start with a '+'. o The 'global-number-digits' and the 'local-number-digits' must be equal, after removing all visual separators. o For mandatory additional parameters (section 5.4) and the 'phone-context' and 'extension' parameters defined in this document, the 'phone-context' parameter value is compared as a host name if it is a 'domainname' or digit by digit if it is 'global-number-digits'. The latter is compared after removing all 'visual-separator' characters. o Parameters are compared according to 'pname', regardless of the order they appeared in the URI. If one URI has a parameter name not found in the other, the two URIs are not equal. o URI comparisons are case-insensitive.
o どちらも「ローカル番号」または「グローバルナンバー」のいずれかでなければなりません。すなわち、 ''から始めてください。oすべてのビジュアルセパレータを削除した後、「グローバル番号桁数」および「ローカル番号桁」は等しくなければなりません。必須追加パラメータ（5.4項）およびこのドキュメントで定義されている「Phone-Context」および '拡張子パラメータの場合は、' phone-context 'パラメータ値が' domainname 'またはdigitの場合、ホスト名として比較されます。「グローバル番号桁」の場合は、数字を桁数。後者は、すべての「視覚的に区切り文字」を取り除いた後に比較されます。oパラメータは、URIに表示されている順序に関係なく、「PNAME」に従って比較されます。一方のURIのパラメータ名が見つからない場合、2つのURIは等しくありません。o URI比較は大文字と小文字を区別しない。
All parameter names and values SHOULD use lower-case characters, as tel URIs may be used within contexts where comparisons are case sensitive.
すべてのパラメータ名と値は、比較が大文字と小文字が区別されるコンテキスト内で使用できるため、小文字の文字を使用する必要があります。
Section 19.1.4 in the SIP specification [RFC3261] discusses one such case.
SIP仕様でのセクション19.1.4 [RFC3261]そのような場合は1つについて説明します。
The 'telephone-subscriber' part of the URI indicates the number. The phone number can be represented in either global (E.164) or local notation. All phone numbers MUST use the global form unless they cannot be represented as such. Numbers from private numbering plans, emergency ("911", "112"), and some directory-assistance numbers (e.g., "411") and other "service codes" (numbers of the form N11 in the United States) cannot be represented in global (E.164) form and need to be represented as a local number with a context. Local numbers MUST be tagged with a 'phone-context' (section 5.1.5).
URIの「電話加入者」部分は番号を示します。電話番号は、グローバル（E.164）またはローカル表記のいずれかで表すことができます。すべての電話番号は、そのように表現できない限り、グローバルフォームを使用する必要があります。プライベートナンバリングプラン、緊急（「911」、「112」）、および一部のディレクトリアシスタンス番号（「411」）およびその他の「サービスコード」（米国の形式N11の数）を表すことはできません。Global（E.164）形式で、コンテキストを持つローカル番号として表現する必要があります。ローカル番号は「Phone-Context」でタグ付けする必要があります（セクション5.1.5）。
Implementations MUST NOT assume that telephone numbers have a maximum, minimum, or fixed length, or that they always begin with or contain certain digits.
実装は、電話番号が最大、最小、または固定長さ、またはそれらが常に特定の数字で始まるか、または特定の数字を含むと仮定してはいけません。
Phone numbers MAY contain visual separators. Visual separators ('visual-separator') merely aid readability and are not used for URI comparison or placing a call.
電話番号には視覚区切り文字が含まれている可能性があります。視覚区切り文字（「視覚的区切り」）は単に読みやすさを支援し、URI比較または通話を配置するために使用されません。
Although it complicates comparisons, this specification retains visual separators in order to follow the spirit of RFC 2396 [RFC2396], which remarks that "A URI often needs to be remembered by people, and it is easier for people to remember a URI when it consists of meaningful components". Also, ISBN URNs documented in RFC 3187 [RFC3187] use visual separators in a manner similar to this specification.
それは比較を複雑にしていますが、この仕様はRFC 2396 [RFC2396]の精神に従うために視覚的な区切り文字を保持しています。意味のある成分のうち」。また、RFC 3187 [RFC3187]に記載されているISBN URNSは、この仕様と同様に視覚区切り文字を使用しています。
However, even though ITU-T E.123 [E.123] recommends the use of space characters as visual separators in printed telephone numbers, "tel" URIs MUST NOT use spaces in visual separators to avoid excessive escaping.
ただし、ITU-T E.123 [E.123]は、印刷された電話番号の視覚区切り文字としてスペース文字を使用することをお勧めしています。
In some countries, it is common to write phone numbers with alphabetic characters corresponding to certain numbers on the telephone keypad. The URI format does not support this notation, as the mapping from alphabetic characters to digits is not completely uniform internationally, although there are standards [E.161][T1.703] addressing this issue.
一部の国では、電話のキーパッドの特定の数字に対応する英字で電話番号を書くことが一般的です。アルファベット文字から数字へのマッピングが完全に制限されていないので、URI形式はこの表記法が完全に制限されていないが、標準はこの問題に対処しています。
As called and calling terminal numbers (TNs) are encoded in BCD in ISUP, six additional values per digit can be encoded, sometimes represented as the hexadecimal characters A through F. Similarly, DTMF allows for the encoding of the symbols *, #, and A through D. However, in accordance with E.164, these may not be included in global numbers. Their meaning in local numbers is not defined here, but they are not prohibited.
呼び出された端末番号（TNS）はISUPでBCDでエンコードされると、1桁あたり6つの追加値を符号化することができ、時には16進文字aからFとして表されます。同様に、DTMFはシンボル*、＃、および＃、および＃、ただし、E.164に従って、これらはグローバル数に含まれていない可能性があります。ローカル数の意味はここで定義されていませんが、禁止されていません。
Globally unique numbers are identified by the leading "+" character. Global numbers MUST be composed with the country (CC) and national (NSN) numbers as specified in E.123 [E.123] and E.164 [E.164]. Globally unique numbers are unambiguous everywhere in the world and SHOULD be used.
グローバルに固有の数字は、先頭の ""文字によって識別されます。グローバル数は、E.123 [E.123]とE.164 [E.164]で指定されている国（CC）とNational（NSN）番号で構成する必要があります。世界中のユニークな数字は、世界中のいたると一致しており、使用する必要があります。
Local numbers are unique only within a certain geographical area or a certain part of the telephone network, e.g., a private branch exchange (PBX), a state or province, a particular local exchange carrier, or a particular country. URIs with local phone numbers should only appear in environments where all local entities can successfully set up the call by passing the number to the dialling software. Digits needed for accessing an outside line, for example, are not included in local numbers. Local numbers SHOULD NOT be used unless there is no way to represent the number as a global number.
ローカル数は、特定の地理的領域または電話ネットワークの特定の部分、例えばプライベートブランチ交換（PBX）、州または州、特定の地方交換担当者、または特定の国の中でのみ独特です。ローカル電話番号を持つURIは、すべてのローカルエンティティが番号をダイヤルソフトウェアに渡すことによってコールを正常に設定できる環境でのみ表示されます。たとえば、外線にアクセスするために必要な数字は、ローカル番号には含まれません。グローバル数を表す方法がない限り、ローカル番号を使用しないでください。
Local numbers SHOULD NOT be used for several reasons. Local numbers require that the originator and recipient are configured appropriately so that they can insert and recognize the correct context descriptors. Since there is no algorithm to pick the same descriptor independently, labelling numbers with their context increases the chances of misconfiguration so that valid identifiers are rejected by mistake. The algorithm to select descriptors was chosen so that accidental collisions would be rare, but they cannot be ruled out.
いくつかの理由でローカル番号を使用しないでください。ローカル数は、オリジネータと受信者が正しいコンテキスト記述子を挿入して認識できるように適切に構成されている必要があります。同じディスクリプタを独立して選択するためのアルゴリズムがないので、それらのコンテキストを持つラベリング番号は、有効な識別子が誤って拒否されるように、誤構成の可能性を高めます。記述子を選択するアルゴリズムが選択され、偶発的な衝突がまれであるが除外することはできません。
Local numbers MUST have a 'phone-context' parameter that identifies the scope of their validity. The parameter MUST be chosen to identify the local context within which the number is unique unambiguously. Thus, the combination of the descriptor in the 'phone-context' parameter and local number is again globally unique. The parameter value is defined by the assignee of the local number. It does NOT indicate a prefix that turns the local number into a global (E.164) number.
ローカル番号には、妥当性の範囲を識別する「Phone-Context」パラメータが必要です。このパラメータは、その数が明確にユニークなローカルコンテキストを識別するために選択する必要があります。したがって、「Phone-Context」パラメータとローカル番号の記述子の組み合わせは、またグローバルに一意です。パラメータ値は、ローカル番号の担当者によって定義されます。ローカル数をグローバル（E.164）番号に変えるプレフィックスを示すものではありません。
There are two ways to label the context: via a global number or any number of its leading digits (e.g., "+33") and via a domain name, e.g., "houston.example.com". The choice between the two is left to the "owner" of the local number and is governed by whether there is a global number or domain name that is a valid identifier for a particular local number.
コンテキストにラベルを付ける方法は2つあります。グローバル番号またはその先頭の数字（例えば、 "33"）とドメイン名、例えば "houston.example.com"を介して、2つの選択はローカル数の「所有者」に残され、特定のローカル番号の有効な識別子であるグローバル番号またはドメイン名があるかどうかによって管理されます。
The domain name does not have to resolve to any actual host but MUST be under the administrative control of the entity managing the local phone context.
ドメイン名は実際のホストに解決する必要はありませんが、ローカル電話のコンテキストを管理するエンティティの管理管理下にある必要があります。
A global number context consists of the initial digits of a valid global number. All global numbers with these initial digits must be assigned to the same organization, and no such matching number can be used by any other organization. For example, +49-6151-16 would be a suitable context for the Technical University of Darmstadt, as it uses all numbers starting with those digits. If such an initial string of digits does not exist, the organization SHOULD use the lowest number of the global number range assigned to it. (This can occur if two organizations share the same decimal block of numbers. For example, assume an organization owns the number range +1-212- 555-0100 through +1-212-555-0149. +1-212-555-1 would not be a valid global number context, but +1-212-555-0100 would work.) It is not required that local numbers within the context actually begin with the chosen set of initial numbers.
グローバル番号コンテキストは、有効なグローバル番号の初期桁から構成されています。これらの最初の桁数を持つすべてのグローバル番号を同じ組織に割り当てる必要がなく、そのようなマッチング数は他の組織で使用できません。たとえば、49-6151-16はDarmStadtの技術大学のための適切なコンテキストであろう。そのような初期の数字の文字列が存在しない場合、組織はそれに割り当てられたグローバル数範囲の最小数を使用する必要があります。たとえば、組織が1-212-555-0100から1-212-555-0149を所有していると仮定してください。1-212-555-0149。有効なグローバル番号のコンテキストであるが、1-212-555-0100が機能することが必要ではない。）コンテキスト内のローカル番号は実際には初期番号の選択されたセットから始まる必要はありません。
A context consisting of the initial digits of a global number does not imply that adding these to the local number will generate a valid E.164 number. It might do so by coincidence, but this cannot be relied upon. (For example, "911" should be labeled with the context "+1", but "+1-911" is not a valid E.164 number.)
グローバル番号の初期桁からなるコンテキストは、ローカル番号にこれらを追加することは有効なE.164番号を生成することを意味しません。それは一致によってそうするかもしれませんが、これは信頼できません。（たとえば、 "911"はコンテキスト "1"でラベル付けされるべきですが、 "1-911"は有効なE.164番号ではありません。）
National freephone numbers do not need a context, even though they are not necessarily reachable from outside a particular country code or numbering plan. Recall that "tel" URIs are identifiers; it is sufficient that a global number is unique, but it is not required that it be reachable from everywhere.
特定の国コードや番号付け計画の外部から必ずしも到達可能ではないにもかかわらず、国民のFreePhoneの番号は文脈を必要としません。「Tel」URIが識別子であることを思い出してください。グローバル数が一意であるのは十分ですが、どこからでも到達可能である必要はありません。
Even non-freephone numbers may be out of date or may not be reachable from a particular location. For example, premium services such as "900" numbers in the North American numbering plan are often not dialable from outside the particular country code.
非フリーフォン数でさえ、特定の場所から到達できない場合があります。たとえば、北米の番号付け計画の「900」の数字などのプレミアムサービスは、特定の国コードの外部からダイヤル可能ではありません。
The two label types were chosen so that, in almost all cases, a local administrator can pick an identifier that is reasonably descriptive and does not require a new IANA-managed assigned number. It is up to the administrator to assign an appropriate identifier and to use it consistently. Often, an organization can choose among several different identifiers.
2つのラベルタイプが選択されたため、ほとんどすべての場合では、ローカル管理者が合理的に説明的で、新しいIANA管理割り当て番号を必要としない識別子を選択できます。適切な識別子を割り当てて一貫して使用するには、管理者次第です。多くの場合、組織はいくつかの異なる識別子の中から選択できます。
If the recipient of a "tel" URI uses it simply for identification, the receiver does not need to know anything about the context descriptor. It simply treats it as one part of a globally unique identifier, with the other being the local number. If a recipient of the URI intends to place a call to the local number, it MUST understand the context and be able to place calls within that context.
「TEL」URIの受信者が単純に識別のために使用する場合、受信者はコンテキスト記述子について何も知る必要はありません。それは単にグローバルに一意の識別子の一部としてそれを扱い、他はローカル番号です。URIの受信者がローカル番号に電話をかけることを意図している場合は、コンテキストを理解し、そのコンテキスト内で呼び出しを配置することができます。
A phone number MAY also contain an 'isdn-subaddress' parameter that indicates an ISDN subaddress.
電話番号には、ISDNサブアドレスを示す「isdn-subaddress」パラメータも含めることができます。
ISDN subaddresses typically contain International Alphabet 5 (IA5 [T.50]) characters but may contain any octet value.
ISDNサブアドレスには、通常、国際アルファベット5（IA5 [T.50]）文字が含まれていますが、オクテット値を含めることができます。
Phone extensions identify stations behind a non-ISDN PBX and are functionally roughly equivalent to ISDN subaddresses. They are identified with the 'extension' parameter. At most, one of the 'isdn-subaddress' and 'extension' parameters can appear in a "tel" URI, i.e., they cannot appear both at the same time.
Phone Extensions非ISDN PBXの背後にあるステーションを特定し、ISDNサブアドレスと機能的にほぼほぼ同じです。それらは '拡張子'パラメータで識別されます。ほとんどの場合、 'ISDN-Subaddress'と 'Extension'パラメータの1つは "Tel" URI、すなわち、それらの両方に同時に現れることができません。
Future protocol extensions to this URI scheme may add other parameters ('parameter' in the ABNF). Such parameters can be either mandatory or optional. Mandatory parameters start with "m-". An implementation MAY ignore optional parameters and MUST NOT use the URI if it contains unknown mandatory parameters. The "m-" prefix cannot be added to parameters that were already registered (except to create a new, logically distinct parameter). The "phone-context" parameter in this document is mandatory, and "isub" and "ext" are optional.
このURIスキームに対する将来のプロトコル拡張は、他のパラメータ（ABNF内の「パラメータ」）を追加することができる。そのようなパラメータは必須またはオプションのいずれかです。必須パラメータは「M-」で始まります。実装はオプションのパラメータを無視し、それが未知の必須パラメータを含む場合はURIを使用してはいけません。"M-"プレフィックスは、すでに登録されていたパラメータに追加できません（新しい、論理的に異なるパラメータを作成する以外は除く）。このドキュメントの "Phone-Context"パラメータは必須です、そして "isub"と "ext"はオプションです。
New mandatory parameters must be described in a standards-track RFC, but an informational RFC is sufficient for optional parameters.
新しい必須パラメータは標準トラックRFCで記述されなければなりませんが、情報RFCはオプションのパラメータに十分です。
For example, 'parameter' parameters can be used to store application-specific additional data about the phone number, its intended use, or any conversions that have been applied to the number.
たとえば、 'Parameter'パラメータを使用して、電話番号、その意図された使用、またはその数に適用されている変換に関するアプリケーション固有の追加データを格納することができます。
Entities that forward protocol requests containing "tel" URIs with optional parameters MUST NOT delete or modify parameters they do not understand.
オプションのパラメータを使用して「Tel」URIを含むプロトコル要求を転送するエンティティは、わからないパラメータを削除または変更してはいけません。
tel:+1-201-555-0123: This URI points to a phone number in the United States. The hyphens are included to make the number more human readable; they separate country, area code and subscriber number.
TEL：1-201-555-0123：このURIは米国の電話番号を指しています。ハイフンはより多くの人間を読めることができるようにするために含まれています。彼らは国、市外局番と加入者番号を分離します。
tel:7042;phone-context=example.com: The URI describes a local phone number valid within the context "example.com".
TEL：7042; Phone-Context = example.com：URIは、コンテキスト "example.com"内で有効なローカル電話番号を説明しています。
tel:863-1234;phone-context=+1-914-555: The URI describes a local phone number that is valid within a particular phone prefix.
TEL：863-1234;電話 - コンテキスト= 1-914-555：URIは、特定の電話プレフィックス内で有効なローカル電話番号を記述します。
The "tel" URI describes a service, reaching a telephone number, that is independent of the means of doing so, be it via a SIP-to-PSTN gateway, a direct SIP call via E.164 number ("ENUM") translation [RFC3761], some other signaling protocols such as H.323, or a traditional circuit-switched call initiated on the client side via, say, the Telephony Application Programming Interface (TAPI). Thus, in spirit, it is closer to the URN schemes that also leave the resolution to an external mechanism. The same "tel" URI may get translated to any number of other URIs in the process of setting up the call.
「Tel」URIは、電話番号に到達するサービスを記述し、それはSIPからPSTNゲートウェイ、E.164番号を介して直接SIPコール（「enum」）翻訳を介してそれを介してそれを記述します。[RFC3761]、H.323などの他のいくつかのシグナリングプロトコル、またはクライアント側で開始された伝統的な回線交換呼び出しは、Telephony Application Programming Interface（TAPI）です。したがって、精神では、解像度を外部機構に残すURN方式に近い。同じ「TEL」URIが、通話を設定するプロセスにおいて、任意の数の他のURIに翻訳される可能性があります。
Signaling protocols such as SIP allow negotiating the call type and parameters, making the very basic indication within the URI scheme moot. Also, since the call type can change frequently, any such indication in a URI is likely to be out of date. If such designation is desired for a device that directly places calls without a signaling protocol such as SIP, mechanisms such as the "type" attribute for the "A" element in HTML may be more appropriate.
SIPなどのシグナリングプロトコルは、コールタイプとパラメータをネゴシエーションすることを可能にし、URIスキーム内の非常に基本的な表示を行います。また、呼タイプは頻繁に変化する可能性があるため、URIのそのような表示は時代遅れになる可能性があります。そのような指定が、SIPなどのシグナリングプロトコルなしでコールを直接配置するデバイスに望まれる場合、HTML内の「A」要素の「Type」属性などのメカニズムがより適切であり得る。
"tel" was chosen because it is widely recognized that none of the other suggestions appeared appropriate. "Callto" was discarded because URI schemes locate a resource and do not specify an action to be taken. "Telephone" and "phone" were considered too long and not easily recognized internationally.
他の提案が適切に現れていないことが広く認識されているので、「Tel」が選択されました。URI方式はリソースを見つけて実行するアクションを指定しないため、 "callto"が破棄されました。「電話」と「電話」は長すぎて、国際的に認識されていないと考えられていました。
As an example, in many countries the E.164 number "+1-212-555-3141" will be dialed as 00-1-212-555-3141, where the leading "00" is a prefix for international calls. (In general, a "+" symbol in E.164 indicates that an international prefix is required.)
一例として、多くの国ではE.164番号「1-212-555-3141」が00-1-212-555-3141としてダイヤルされ、そこで先頭の「00」は国際電話の接頭辞です。（一般に、E.164の「」記号は、国際的な接頭辞が必要であることを示しています。）
Links using the "tel" URI SHOULD enclose the telephone number so that users can easily predict the action taken when following the link
「TEL」URIを使用したリンクは、リンク後に取られたときに取られたアクションを簡単に予測できるように電話番号を囲む必要があります。
Dial <a href="tel:+1-212-555-0101">+1-212-555-0101</a> for assistance.
ダイヤル<a href="tel：212-555-0101"> 1-212-555-0101 </a> </a>を支援する。
instead of
の代わりに
Dial <a href="tel:+1-212-555-0101">this number</a> for assistance.
<a href="tel：1-212-555-0101">この番号</a>をダイヤルしてください。
On a public HTML page, the telephone number in the URI SHOULD always be in the global form, even if the text of the link uses some local format:
パブリックHTMLページでは、リンクのテキストがいくつかのローカルフォーマットを使用していても、URIの電話番号は常にグローバルフォームにあります。
Telephone (if dialling in the United States):
<a href="tel:+1-201-555-0111">(201) 555-0111</a>
or even
あるいは
For having RFCs read aloud, call <a href="tel:+1-555-438-3732">1-555-IETF-RFC</a>.
RFCが声を出して読み上げて、コール<a href="tel：1-555-438-3732"> 1-555-ietf-rfc </a>。
SIP can use the "tel" URI anywhere a URI is allowed, for example as a Request-URI, along with "sip" and "sips" URIs. For brevity, we will imply "sips" URIs when talking about SIP URIs. Both "tel" and SIP URIs can contain telephone numbers. In SIP URIs, they appear as the user part, i.e., before the @ symbol (section 19.1.6 in [RFC3261]).
SIPは、「SIP」および「SIP」URIとともに、URIが要求 - URIとして許可されている任意の場所に「Tel」URIを使用することができる。簡潔にするために、SIP URIについて話すときに「SIP」のURIを意味します。「Tel」とSIP URIの両方に電話番号を含めることができます。SIP URIでは、それらはユーザーの部分として、すなわち@記号の前に表示されます（[RFC3261]のセクション19.1.6）。
Unless a SIP UA connects directly to a PSTN gateway, one of the SIP proxy servers has to translate the "tel" URI to a SIP URI, with the host part of that URI pointing to a gateway. Typically, the outbound proxy server, as the first proxy server visited by a call request, performs this translation. A proxy server can translate all "tel" URIs to the same SIP host name or select a different gateway for different "tel" prefixes, based, for example, on information learned from TRIP [RFC3219]. However, a proxy server could also delegate this translation task to any other proxy server, as proxy servers are free to apply whatever routing logic they desire. For local numbers, the proxy MUST NOT translate "tel" URIs whose contexts it does not understand.
SIP UAがPSTNゲートウェイに直接接続されていない限り、SIPプロキシサーバの1つは「Tel」URIをSIP URIに変換し、そのURIのホスト部分をゲートウェイに指している。通常、発信プロキシサーバーは、通話要求によって訪問された最初のプロキシサーバーとして、この翻訳を実行します。プロキシサーバーは、すべての "Tel" URIを同じSIPホスト名に変換することも、たとえばTrip [RFC3219]から学習された情報に基づいて、さまざまな「Tel」プレフィックスの異なるゲートウェイを選択できます。ただし、プロキシサーバーは、プロキシサーバーが必要なルーティングロジックが適用されているため、この変換タスクを他のプロキシサーバーに委任することもできます。ローカル数の場合、プロキシはコンテキストが理解できない「Tel」URIを翻訳してはいけません。
As noted earlier, all phone numbers MUST use the global form unless they cannot be represented as such. If the local-number format is used, it MUST be qualified by the 'phone-context' parameter. Effectively, the combination of local number and phone context makes the "tel" URI globally unique.
前述のように、それらがそのように表現できない限り、すべての電話番号はグローバルフォームを使用する必要があります。ローカル番号フォーマットが使用されている場合は、「Phone-Context」パラメータによって修飾されている必要があります。事実上、ローカル番号と電話のコンテキストの組み合わせは、「Tel」URIをグローバルにユニークにします。
Although web pages, vCard business cards, address books, and directories can easily contain global "tel" URIs, users on twelve-button (IP) phones cannot dial such numbers directly and are typically accustomed to dialling shorter strings, e.g., for PBX extensions or local numbers. These so-called dial strings (section 1) are not directly represented by "tel" URIs, as noted. We refer to the rules that govern the translation of dial strings into SIP and "tel" URIs, global or local, as the dial plan. Currently, translations from dial strings to "tel" URIs have to take place in end systems. Future efforts may provide means to carry dial strings in a SIP URI, for example, but no such mechanisms exist as of this writing.
Webページ、VCard名刺、アドレス帳、およびディレクトリにグローバル "Tel" URIを簡単に含めることができますが、12ボタン（IP）電話機のユーザーはそのような数字を直接ダイヤルすることはできず、通常はPBX Extensionsのために短い文字列をダイヤルすることに慣れています。またはローカル番号。述べたように、これらのいわゆるダイヤル文字列（セクション1）は「Tel」URIによって直接表されていません。ダイヤル文字列へのダイヤル文字列の翻訳と「Tel」URI、GlobalまたはLocalの翻訳をダイヤルプランとして指しています。現在、ダイヤル文字列から「Tel」URIへの翻訳は、エンドシステムで起こらなければなりません。将来の努力は、例えば、SIP URI内のダイヤル文字列を搬送するための手段を提供することができるが、この書き込みのようなそのようなメカニズムは存在しない。
A SIP UA can use a dial plan to translate dial strings into SIP or "tel" URIs. The dial plan can be manually configured or, preferably, downloaded as part of a device configuration mechanism. (At this time, there is no standardized mechanism for this.)
SIP UAはダイヤルプランを使用してダイヤル文字列をSIPまたは「Tel」URIに変換できます。ダイヤルプランは、手動で構成されているか、または装置構成機構の一部としてダウンロードされ得る。（現時点では、これには標準化されていません。）
A mobile user can use at least two dial plans, namely the dial plan for the network that he is currently visiting and the dial plan for his home network. Generally, dialed numbers meant to represent global numbers will look the same after the translation regardless of the dial plan, even if, say, the visited network uses '0' for dialling an 'outside' number and the user's home network uses '9', as long as the user is aware of the current dial plan. However, local extensions without a direct global equivalent may well behave differently. To avoid any ambiguity, the dial plan MUST insert a suitable 'phone-context' string when performing the translation. If the 'phone-context' is a domain name, there are three cases:
モバイルユーザーは、少なくとも2つのダイヤルプラン、すなわち、現在訪問しているネットワークのダイヤルプランと彼のホームネットワークのダイヤルプランを使用することができます。一般に、ダイヤル数を表すことを意味するダイヤル番号は、ダイヤルプランに関係なく翻訳後も同じように見えるようになるでしょう。ユーザーが現在のダイヤルプランを認識している限り。ただし、直接グローバルな同等のものなしのローカル拡張は、異なる動作がよく動作します。あいまいさを避けるために、翻訳を実行するときにダイヤルプランは適切な「電話コンテキスト」文字列を挿入する必要があります。「Phone-Context」がドメイン名の場合、3つのケースがあります。
1. The outbound proxy recognizes the domain name in the "tel" or SIP URI as its local context and can route the request to a gateway that understands the local number.
1. 発信プロキシは、 "Tel"またはSIP URIのローカルコンテキストとしてドメイン名を認識し、ローカル番号を理解しているゲートウェイにリクエストをルーティングできます。
2. The outbound proxy does not use the same phone context but can route to a proxy that handles this phone context. This routing can be done via a lookup table, or the domain name of the phone context might be set up to reflect the SIP domain name of a suitable proxy. For example, a proxy may always route calls with "tel" URIs like
2. アウトバウンドプロキシは同じ電話コンテキストを使用しませんが、この電話コンテキストを処理するプロキシにルーティングできます。このルーティングはルックアップテーブルを介して行うことができます、または適切なプロキシのSIPドメイン名を反映するように電話コンテキストのドメイン名が設定される可能性があります。たとえば、プロキシは常に "Tel" URIで呼び出しをルーティングすることがあります。
tel:1234;phone-context=munich.example.com
to the SIP proxy located at munich.example.com. (Proxies receiving a tel URI with a context they do not understand are obligated to return a 404 (Not Found) status response so that an outbound proxy may decide to attempt such a heuristic.)
Munich.example.comにあるSIPプロキシに。（理解されていないコンテキストでTel URIを受信するプロキシは、404（見つかりません）ステータスレスポンスを返す義務があります。
3. The outbound proxy does not recognize the phone context and cannot find the appropriate proxy for that phone context. In that case, the translation fails, and the outbound proxy returns a 404 (Not Found) error response.
3. アウトバウンドプロキシは電話のコンテキストを認識せず、その電話コンテキストの適切なプロキシを見つけることができません。その場合、変換が失敗し、アウトバウンドプロキシは404（見つかりません）エラー応答を返します。
This document is derived from RFC 2806 [RFC2806], written by Antti Vaehae-Sipilae. Mark Allman, Flemming Andreasen, Francois Audet, Lawrence Conroy, Cullen Jennings, Michael Hammer, Paul Kyzivat, Andrew Main, Xavier Marjou, Jon Peterson, Mike Pierce, Jonathan Rosenberg, and James Yu provided extensive comments.
この文書は、Antti Vaehae-Sipilaeによって書かれたRFC 2806 [RFC2806]から派生しています。Mark Allman、Flemming Andreasen、Francois Audet、Lawrence Conroy、Cullen Jennings、Michael Hammer、Paul Kyzivat、Andrew Main、Xavier Marjou、Jon Peterson、Mike Pierce、Jonathan Rosenberg、James Yuには広範囲のコメントがありました。
The security considerations parallel those for the mailto URL [RFC2368].
セキュリティ上の考慮事項は、MailTo URL [RFC2368]の並列並列です。
Web clients and similar tools MUST NOT use the "tel" URI to place telephone calls without the explicit consent of the user of that client. Placing calls automatically without appropriate user confirmation may incur a number of risks, such as those described below:
Webクライアントと同様のツールは、そのクライアントのユーザーの明示的な同意なしに電話をかけるために「Tel」URIを使用してはいけません。適切なユーザー確認なしで呼び出しを自動的に配置すると、以下に説明されるもののような数のリスクが発生する可能性があります。
o Calls may incur costs. o The URI may be used to place malicious or annoying calls. o A call will take the user's phone line off-hook, thus preventing its use. o A call may reveal the user's possibly unlisted phone number to the remote host in the caller identification data and may allow the attacker to correlate the user's phone number with other information, such as an e-mail or IP address.
o 呼び出しはコストをかける可能性があります。o URIは悪意のあるまたは迷惑な電話をかけるために使用されるかもしれません。o呼び出しはユーザーの電話回線をオフフックにし、その使用を防ぎます。o呼び出しは、呼び出し元識別データ内のリモートホストへのユーザのおそらく非公開電話番号を明らかにし、攻撃者がユーザの電話番号を電子メールまたはIPアドレスなどの他の情報と相関させることを可能にし得る。
This is particularly important for "tel" URIs embedded in HTML links, as a malicious party may hide the true nature of the URI in the link text, as in
悪意のある当事者がリンクテキストのURIの本当の性質を隠す可能性があるため、これはHTMLリンクに埋め込まれている「Tel」URIが特に重要です。
<a href="tel:+1-900-555-0191">Find free information here</a>
<a href="tel:+1-900-555-0191">tel:+1-800-555-0191</a>
"tel" URIs may reveal private information, similar to including phone numbers as text. However, the presence of the tel: schema identifier may make it easier for an adversary using a search engine to discover these numbers.
「Tel」URIは、電話番号をテキストとして含めるのと同様に、個人情報を明らかにするかもしれません。ただし、TEL：Schema IDの存在は、検索エンジンを使用している敵対者がこれらの数を発見するのを容易にすることがあります。
The specification is syntactically backwards-compatible with the "tel" URI defined in RFC 2806 [RFC2806] but has been completely rewritten. This document more clearly distinguishes telephone numbers as identifiers of network termination points from dial strings and removes the latter from the purview of "tel" URIs.
仕様は、RFC 2806 [RFC2806]で定義されている「Tel」URIと構文的に後方互換性がありますが、完全に書き換えられました。この文書は、ダイヤル文字列からのネットワーク終端点の識別子として電話番号をより明確に区別し、「Tel」URIのPURViewから後者を削除します。
Compared to RFC 2806, references to carrier selection, dial context, fax and modem URIs, post-dial strings, and pause characters have been removed. The URI syntax now conforms to RFC 2396 [RFC2396].
RFC 2806と比較して、キャリア選択、ダイヤルコンテキスト、ファックス、モデムURI、ダイヤル文字列、および一時停止文字への参照が削除されました。URI構文はRFC 2396 [RFC2396]に準拠しています。
A section on using "tel" URIs in SIP was added.
SIPの「Tel」URIを使用するセクションを追加しました。
[E.123] International Telecommunications Union, "Notation for national and international telephone numbers, e-mail addresses and web addresses", Recommendation E.123, February 2001.
[E.123]国際電気通信連合、「国内外の電話番号、電子メールアドレス、Webアドレスの表記法」、勧告E.123、2001年2月。
[E.161] International Telecommunications Union, "Arrangement of digits, letters and symbols on telephones and other devices that can be used for gaining access to a telephone network", Recommendation E.161, May 1995.
[E.161]国際電気通信連合、「電話網へのアクセス権を得るために使用できる桁数、文字および記号の配置」、勧告E.161、1995年5月。
[E.164] International Telecommunications Union, "The international public telecommunication numbering plan", Recommendation E.164, May 1997.
[E.164]国際電気通信連合「国際公共通信番号計画」、勧告E.164、1997年5月。
[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月。
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC2234] Crocker、D.およびP. Overell、「Syntax仕様のための拡張BNF：ABNF」、RFC 2234、1997年11月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M.、E. Schooler、「SIP：セッション開始プロトコル」、RFC 3261、2002年6月。
[T1.703] ANSI, "Allocation of Letters to the Keys of Numeric Keypads for Telecommunications", Standard T1.703-1995 (R1999), 1999.
[T1.703] ANSI、「電気通信のためのテンキーのキーへの文字の割り当て」、標準T1703-1995（R1999）、1999年。
[RFC2368] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto URL scheme", RFC 2368, July 1998.
[RFC2368] Hoffman、P.、Masinter、L.、J.Zawinski、「Mailto URLスキーム」、RFC 2368、1998年7月。
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC2396] Berners-Lee、T.、Field、R.、およびL. Masinter、「Uniform Resource Identifiers（URI）：Generic Syntax」、RFC 2396、1998年8月。
[RFC2806] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April 2000.
[RFC2806] Vaha-Sipila、A。、「電話のためのURL」、RFC 2806、2000年4月。
[RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[RFC3761] Faltstrom、P.およびM. Mealling、「E.164から均一なリソース識別子（URI）動的代表団検出システム（DDDS）アプリケーション（ENUM）アプリケーション（ENUM） "、RFC 3761、2004年4月。
[RFC3187] Hakala, J. and H. Walravens, "Using International Standard Book Numbers as Uniform Resource Names", RFC 3187, October 2001.
[RFC3187] Hakala、J.およびH. Walravens、「国際標準名としての統一資源名としての使用」、RFC 3187、2001年10月。
[RFC3191] Allocchio, C., "Minimal GSTN address format in Internet Mail", RFC 3191, October 2001.
[RFC3191] Allocchio、C、「インターネットメールの最小GSTNアドレスフォーマット」、RFC 3191、2001年10月。
[RFC3192] Allocchio, C., "Minimal FAX address format in Internet Mail", RFC 3192, October 2001.
[RFC3192] Allocchio、C、「インターネットメールの最小ファックスアドレスフォーマット」、RFC 3192、2001年10月。
[RFC3219] Rosenberg, J., Salama, H., and M. Squire, "Telephony Routing over IP (TRIP)", RFC 3219, January 2002.
[RFC3219] Rosenberg、J.、Salama、H.、M. Squire、「IP（Trip）over IP（Trip）」、RFC 3219、2002年1月。
[T.50] International Telecommunications Union, "International Reference Alphabet (IRA) (Formerly International Alphabet No. 5 or IA5) - Information technology - 7-bit coded character set for information interchange", Recommendation T.50, 1992.
[T.50]国際電気通信連合、「国際参照アルファベット（IRA）（以前の国際アルファベットNo.5またはIA5） - 情報技術 - 情報交換の7ビットコード化文字セット、勧告T.50,1992。
Author's Address
著者の住所
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US
Henning Schulzrinne Columbia Universityコンピュータサイエンス省450コンピュータサイエンスビルニューヨーク、NY 10027アメリカ
Phone: +1 212 939 7042
EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu
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文書の権利に関する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事務局へのIETF事務局と利用可能なライセンスの保証のコピー、またはこの仕様書の実装者や利用者による一般的なライセンスまたは許可を得るための試みの結果を得ることができます。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-ipr@ietf.orgのIETFに情報を宛先に宛ててください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディタ機能のための資金は、現在インターネット社会によって提供されています。