[要約] RFC 2806は、電話通話のためのURLに関する規格であり、電話番号をURL形式で表現する方法を提案しています。この規格の目的は、電話番号をURLとして使用することで、電話通話の自動化や統合を容易にすることです。
Network Working Group A. Vaha-Sipila
Request for Comments: 2806 Nokia
Category: Standards Track April 2000
URLs for Telephone Calls
電話用のURL
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 (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
Abstract
概要
This document specifies URL (Uniform Resource Locator) schemes "tel", "fax" and "modem" for specifying the location of a terminal in the phone network and the connection types (modes of operation) that can be used to connect to that entity. This specification covers voice calls (normal phone calls, answering machines and voice messaging systems), facsimile (telefax) calls and data calls, both for POTS and digital/mobile subscribers.
このドキュメントは、URL（均一なリソースロケーター）スキーム「Tel」、「Fax」、および「Modem」を指定します。。この仕様は、ポットとデジタル/モバイルサブスクライバーの両方の音声通話（通常の電話、応答機、音声メッセージングシステム）、Faximile（TeleFax）コール、およびデータコールをカバーしています。
Table of Contents
目次
1. Introduction ................................................ 2
1.1 New URL schemes ............................................ 2
1.2 Formal definitions ......................................... 3
1.3 Requirements ............................................... 3
2. URL schemes for telephone calls ............................. 3
2.1 Applicability .............................................. 3
2.2 "tel" URL scheme ........................................... 4
2.3 "fax" URL scheme ........................................... 6
2.4 "modem" URL scheme ......................................... 6
2.5 Parsing telephone, fax and modem URLs ...................... 7
2.5.1 Call type ................................................ 7
2.5.2 Phone numbers and their scope ............................ 7
2.5.3 Separators in phone numbers .............................. 10
2.5.4 Converting the number to the local numbering scheme ...... 10
2.5.5 Sending post-dial sequence after call setup .............. 10
2.5.6 Pauses in dialing and post-dial sequence ................. 11
2.5.7 ISDN subaddresses ........................................ 11
2.5.8 T.33 subaddresses ........................................ 11
2.5.9 Data call parameters ..................................... 12
2.5.10 Telephony service provider identification ............... 13
2.5.11 Additional parameters ................................... 14
2.6 Examples of Use ............................................ 14
2.7 Rationale behind the syntax ................................ 15
2.7.1 Why distinguish between call types? ..................... 15
2.7.2 Why "tel" is "tel"? ..................................... 16
2.7.3 Why to use E.164-style numbering? ........................ 16
2.7.4 Not everyone has the same equipment as you ............... 17
2.7.5 Do not confuse numbers with how they are dialled ......... 17
3. Comments on usage ........................................... 17
4. References .................................................. 18
5. Security Considerations ..................................... 19
6. Acknowledgements ............................................ 20
7. Author's Address ............................................ 20
8. Full Copyright Statement .................................... 21
This specification defines three new URL schemes: "tel", "fax" and "modem". They are intended for describing a terminal that can be contacted using the telephone network. The description includes the subscriber (telephone) number of the terminal and the necessary parameters to be able to successfully connect to that terminal.
この仕様では、「Tel」、「Fax」、「Modem」の3つの新しいURLスキームが定義されています。それらは、電話ネットワークを使用して連絡できる端末を説明することを目的としています。説明には、サブスクライバー（電話）端末の番号とその端末に正常に接続できるようにする必要なパラメーターが含まれます。
The "tel" scheme describes a connection to a terminal that handles normal voice telephone calls, a voice mailbox or another voice messaging system or a service that can be operated using DTMF tones.
「Tel」スキームは、通常の音声電話、ボイスメールボックス、または別の音声メッセージングシステム、またはDTMFトーンを使用して操作できるサービスを処理する端末への接続について説明します。
The "fax" scheme describes a connection to a terminal that can handle telefaxes (facsimiles). The name (scheme specifier) for the URL is "fax" as recommended by [E.123].
「FAX」スキームは、テレファックス（ファクシミリ）を処理できる端末への接続を説明しています。URLの名前（スキーム指定子）は[e.123]が推奨する「ファックス」です。
The "modem" scheme describes a connection to a terminal that can handle incoming data calls. The term "modem" refers to a device that does digital-to-analog and analog-to-digital conversions; in addition to these, a "modem" scheme can describe a fully digital connection.
「モデム」スキームは、着信データ呼び出しを処理できる端末への接続を説明しています。「モデム」という用語は、デジタルからアナログとアナログからデジタルへの変換を行うデバイスを指します。これらに加えて、「モデム」スキームは完全にデジタル接続を記述できます。
The notation for phone numbers is the same which is specified in [RFC2303] and [RFC2304]. However, the syntax definition is a bit different due to the fact that this document specifies URLs whereas [RFC2303] and [RFC2304] specify electronic mail addresses. For example, "/" (used in URLs to separate parts in a hierarchical URL [RFC2396]) has been replaced by ";". In addition, this URL scheme has been synchronized with [RFC2543].
電話番号の表記は、[RFC2303]および[RFC2304]で指定されている同じです。ただし、[RFC2303]と[RFC2304]が電子メールアドレスを指定しているのに対し、このドキュメントがURLSを指定しているという事実により、構文定義は少し異なります。たとえば、 "/"（URLで使用されて階層URL [RFC2396]で部分を分離するために使用）は、「;」に置き換えられています。さらに、このURLスキームは[RFC2543]と同期されています。
When these URLs are used, the number of parameters should be kept to the minimum, unless this would make the context of use unclear. Having a short URL is especially important if the URL is intended to be shown to the end user, printed, or otherwise distributed so that it is visible.
これらのURLを使用する場合、パラメーターの数は、使用のコンテキストが不明確になる場合を除き、最小限に抑える必要があります。URLがエンドユーザーに表示され、印刷された、またはその他の方法で表示されるように分布することを意図している場合、短いURLを持つことは特に重要です。
The ABNF (augmented Backus-Naur form) notation used in formal definitions follows [RFC2234]. This specification uses elements from the 'core' definitions (Appendix A of [RFC2234]). Some elements have been defined in previous RFCs. If this is the case, the RFC in question has been referenced in comments.
正式な定義で使用されているABNF（Backus-Naur形式の増強）表記は[RFC2234]に続きます。この仕様では、「コア」定義（[RFC2234]の付録A）の要素を使用します。いくつかの要素は、以前のRFCで定義されています。この場合、問題のRFCがコメントで参照されています。
Note on non-unreserved characters [RFC2396] in URLs: the ABNF in this document specifies strings of raw, unescaped characters. If those characters are present in a URL, and are not unreserved [RFC2396], they MUST be escaped as explained in [RFC2396] prior to using the URL. In addition, when parsing a URL, it must be noted that some characters may have been escaped.
URLSの非控えめな文字[RFC2396]に関する注意：このドキュメントのABNFは、生の無効な文字の文字列を指定します。これらの文字がURLに存在し、予約されていない[RFC2396]の場合、URLを使用する前に[RFC2396]で説明されているように逃げる必要があります。さらに、URLを解析する場合、一部の文字が逃げられた可能性があることに注意する必要があります。
An example: ABNF notation "%x20" means a single octet with a hexadecimal value of "20" (in US-ASCII, a space character). This must be escaped in a URL, and it becomes "%20".
例：ABNF表記「％x20」とは、「20」の16進価値を持つ単一のオクテットを意味します（US-ASCIIでは、スペース文字）。これはURLで逃げる必要があり、「％20」になります。
In addition, the ABNF in this document only uses lower case. The URLs are case-insensitive (except for the <future-extension> parameter, whose case-sensitivity is application-specific).
さらに、このドキュメントのABNFは小文字のみを使用します。URLはケース非感受性です（<Future-Extension>パラメーターを除き、そのケース感受性はアプリケーション固有です）。
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 [RFC2119].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
Compliant software MUST follow this specification.
準拠したソフトウェアは、この仕様に従う必要があります。
In this document, "local entity" means software and hardware that can detect and parse one or more of these URLs and possibly place a call to a remote entity, or otherwise utilize the contents of the URL.
このドキュメントでは、「ローカルエンティティ」とは、これらのURLの1つ以上を検出および解析し、リモートエンティティへの呼び出しを行う、またはURLのコンテンツを利用できるソフトウェアとハードウェアを意味します。
These URL schemes are used to direct the local entity to place a call using the telephone network, or as a method to transfer or store a phone number plus other relevant data. The network in question may be a landline or mobile phone network, or a combination of these. If the phone network differentiates between (for example) voice and data calls, or if the local entity has several different telecommunications equipment at its disposal, it is possible to specify which kind of call (voice/fax/data) is requested. The URL can also contain information about the capabilities of the remote entity, so that the connection can be established successfully.
これらのURLスキームは、現地エンティティに電話ネットワークを使用して電話をかけるように指示するため、または電話番号とその他の関連データを転送または保存する方法として使用されます。問題のネットワークは、固定電話または携帯電話ネットワーク、またはこれらの組み合わせである場合があります。電話ネットワークが（たとえば）音声呼び出しとデータコールを区別する場合、またはローカルエンティティがいくつかの異なる通信機器を自由に使用できる場合、どの種類の呼び出し（音声/ファックス/データ）が要求されるかを指定することができます。URLには、リモートエンティティの機能に関する情報も含めることができるため、接続を正常に確立できます。
The "tel", "fax" and "modem" URL schemes defined here do not use the hierarchical URL syntax; there are no applicable relative URL forms. The URLs are always case-insensitive, except for the <future-extension> parameter (see below), whose case-sensitivity is application specific. Characters in the URL MUST be escaped when needed as explained in [RFC2396].
ここで定義されている「Tel」、「Fax」、および「Modem」URLスキームは、階層のURL構文を使用しません。適用可能な相対URLフォームはありません。URLは、<Future-Extension>パラメーター（以下を参照）を除き、常にケース非感受性です。[RFC2396]で説明されているように、必要に応じてURL内の文字を脱出する必要があります。
The URL syntax is formally described as follows. For the basis of this syntax, see [RFC2303].
URL構文は、正式に次のように説明されています。この構文の基礎については、[RFC2303]を参照してください。
telephone-url = telephone-scheme ":"
telephone-subscriber
telephone-scheme = "tel"
telephone-subscriber = global-phone-number / local-phone-number
global-phone-number = "+" base-phone-number [isdn-subaddress]
[post-dial] *(area-specifier /
service-provider / future-extension)
base-phone-number = 1*phonedigit
local-phone-number = 1*(phonedigit / dtmf-digit /
pause-character) [isdn-subaddress]
[post-dial] area-specifier
*(area-specifier / service-provider /
future-extension)
isdn-subaddress = ";isub=" 1*phonedigit
post-dial = ";postd=" 1*(phonedigit /
dtmf-digit / pause-character)
area-specifier = ";" phone-context-tag "=" phone-context-ident
phone-context-tag = "phone-context"
phone-context-ident = network-prefix / private-prefix
network-prefix = global-network-prefix / local-network-prefix
global-network-prefix = "+" 1*phonedigit
local-network-prefix = 1*(phonedigit / dtmf-digit / pause-character)
private-prefix = (%x21-22 / %x24-27 / %x2C / %x2F / %x3A /
%x3C-40 / %x45-4F / %x51-56 / %x58-60 /
%x65-6F / %x71-76 / %x78-7E)
*(%x21-3A / %x3C-7E)
; Characters in URLs must follow escaping rules
; as explained in [RFC2396]
; See sections 1.2 and 2.5.2
service-provider = ";" provider-tag "=" provider-hostname
provider-tag = "tsp"
provider-hostname = domain ; <domain> is defined in [RFC1035]
; See section 2.5.10
future-extension = ";" 1*(token-char) ["=" ((1*(token-char)
["?" 1*(token-char)]) / quoted-string )]
; See section 2.5.11 and [RFC2543]
token-char = (%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
/ %x41-5A / %x5E-7A / %x7C / %x7E)
; Characters in URLs must follow escaping rules
; as explained in [RFC2396]
; See sections 1.2 and 2.5.11
quoted-string = %x22 *( "\" CHAR / (%x20-21 / %x23-7E
/ %x80-FF )) %x22
; Characters in URLs must follow escaping rules
; as explained in [RFC2396]
; See sections 1.2 and 2.5.11
phonedigit = DIGIT / visual-separator
visual-separator = "-" / "." / "(" / ")"
pause-character = one-second-pause / wait-for-dial-tone
one-second-pause = "p"
wait-for-dial-tone = "w"
dtmf-digit = "*" / "#" / "A" / "B" / "C" / "D"
The URL starts with <telephone-scheme>, which tells the local entity that what follows is a URL that should be parsed as described in this document. After that, the URL contains the phone number of the remote entity. Phone numbers can also contain subaddresses, which are used to identify different remote entities under the same phone number. If a subaddress is present, it is appended to the phone number after ";isub=". Phone numbers can also contain a post-dial sequence. This is what is often used with voice mailboxes and other services that are controlled by dialing numbers from your phone keypad while the call is in progress. The <post-dial> sequence describes what and when the local entity should send to the phone line.
URLは<thonele-scheme>で始まります。これは、このドキュメントで説明されているように解析されるべきURLであることをローカルエンティティに伝えます。その後、URLにはリモートエンティティの電話番号が含まれています。電話番号には、同じ電話番号の下で異なるリモートエンティティを識別するために使用されるサブアドレスも含めることができます。サブアドレスが存在する場合、「; isub =」の後に電話番号に追加されます。電話番号には、ダイヤル後のシーケンスも含めることができます。これは、通話が進行中に電話キーパッドから番号をダイヤルすることで制御されるボイスメールボックスやその他のサービスでよく使用されるものです。<ポストダイアル>シーケンスは、現地エンティティが電話回線に送信するものを説明します。
Phone numbers can be either "global" or "local". Global numbers are unambiguous everywhere. Local numbers are usable only within a certain area, which is called "context", see section 2.5.2.
電話番号は、「グローバル」または「ローカル」のいずれかです。グローバル数はどこでも明確です。ローカル番号は、「コンテキスト」と呼ばれる特定の領域内でのみ使用可能です。セクション2.5.2を参照してください。
Local numbers always have an <area-specifier>, which specifies the context in which the number is usable (the same number may have different interpretation in different network areas). The context can be indicated with three different prefixes. A <global-network-prefix> indicates that the number is valid within a numbering area whose global numbers start with <global-network-prefix>. Similarly, <local-network-prefix> means that the number is valid within a numbering area whose numbers (or dial strings) start with it. A <private-prefix> is a name of a context. The local entity must have knowledge of this private context to be able to deduce whether it can use the number, see section 2.5.2. Additional information about the phone number's usage can be included by adding the name of the telephony services provider in <service-provider>, see section 2.5.10.
ローカル数には常に<エリアスペシファー>があります。これは、数値が使用可能なコンテキストを指定します（同じ数字が異なるネットワーク領域で異なる解釈を持つ場合があります）。コンテキストは、3つの異なるプレフィックスで示すことができます。A <Global-Network-Prefix>は、グローバル数が<Global-Network-Prefix>で始まる番号付け領域内で数値が有効であることを示します。同様に、<local-network-prefix>は、数値（またはダイヤル文字列）が開始される番号付け領域内で数値が有効であることを意味します。a <プライベート - プリフィックス>はコンテキストの名前です。ローカルエンティティは、数値を使用できるかどうかを推測できるように、このプライベートコンテキストに関する知識を持っている必要があります。セクション2.5.2を参照してください。電話番号の使用に関する追加情報は、<service-provider>にテレフォニーサービスプロバイダーの名前を追加することで含めることができます。セクション2.5.10を参照してください。
The <future-extension> mechanism makes it possible to add new parameters to this URL scheme. See section 2.5.11.
<Future-Extension>メカニズムにより、このURLスキームに新しいパラメーターを追加できます。セクション2.5.11を参照してください。
The <private-prefix>, <token-char> and <quoted-string> nonterminals may seem a bit complex at first, but they simply describe the set of octets that are legal in those nonterminals. Some octets may have to be escaped, see [RFC2396].
<private-prefix>、<token-char>、および<Quoted-string>非ターミナルは、最初は少し複雑に見えるかもしれませんが、それらの非末端で合法的なオクテットのセットを単に説明しています。いくつかのオクテットを逃がす必要があるかもしれません、[RFC2396]を参照してください。
The URL syntax is formally described as follows (the definition reuses nonterminals from the above definition). For the basis of this syntax, see [RFC2303] and [RFC2304].
URL構文は、次のように正式に説明されています（定義は上記の定義から非末端を再利用します）。この構文の基礎については、[RFC2303]および[RFC2304]を参照してください。
fax-url = fax-scheme ":" fax-subscriber
fax-scheme = "fax"
fax-subscriber = fax-global-phone / fax-local-phone
fax-global-phone = "+" base-phone-number [isdn-subaddress]
[t33-subaddress] [post-dial]
*(area-specifier / service-provider /
future-extension)
fax-local-phone = 1*(phonedigit / dtmf-digit /
pause-character) [isdn-subaddress]
[t33-subaddress] [post-dial]
area-specifier
*(area-specifier / service-provider /
future-extension)
t33-subaddress = ";tsub=" 1*phonedigit
The fax: URL is very similar to the tel: URL. The main difference is that in addition to ISDN subaddresses, telefaxes also have an another type of subaddress, see section 2.5.8.
ファックス：URLはTel：URLに非常に似ています。主な違いは、ISDNサブアドレスに加えて、テレファックスに別のタイプのサブアドレスもあることです。セクション2.5.8を参照してください。
The URL syntax is formally described as follows (the definition reuses nonterminals from the above definitions). For the basis of this syntax, see [RFC2303].
URL構文は、次のように正式に説明されています（定義は上記の定義から非末端を再利用します）。この構文の基礎については、[RFC2303]を参照してください。
modem-url = modem-scheme ":" remote-host
modem-scheme = "modem"
remote-host = telephone-subscriber *(modem-params
/ recommended-params)
modem-params = ";type=" data-capabilities
recommended-params = ";rec=" data-capabilities
data-capabilities = accepted-modem ["?" data-bits parity
stop-bits]
accepted-modem = "V21" / "V22" / "V22b" /
"V23" / "V26t" / "V32" /
"V32b" / "V34" / "V90" /
"V110" / "V120" / "B103" /
"B212" / "X75" /
"vnd." vendor-name "." modem-type
data-bits = "7" / "8"
parity = "n" / "e" / "o" / "m" / "s"
stop-bits = "1" / "2"
vendor-name = 1*(ALPHA / DIGIT / "-" / "+")
modem-type = 1*(ALPHA / DIGIT / "-" / "+")
The modem: URL scheme is also very similar to both the tel: and fax: schemes, but it adds the description of the capabilities of the remote entity. Minimum required compliance is listed in <modem-params> and recommended compliance is listed in <recommended-params>. For details, see section 2.5.9.
モデム：URLスキームは、Tel：and Fax：スキームの両方にも非常に似ていますが、リモートエンティティの機能の説明を追加します。必要な最小コンプライアンスは<modem-params>にリストされており、推奨コンプライアンスは<commessed-params>にリストされています。詳細については、セクション2.5.9を参照してください。
The type of call is specified by the scheme specifier. "Tel" means that a voice call is opened. "Fax" indicates that the call should be a facsimile (telefax) call. "Modem" means that it should be a data call. Not all networks differentiate between the types of call; in this case, the scheme specifier indicates the telecommunications equipment type to use.
呼び出しのタイプは、スキーム仕様によって指定されます。「Tel」とは、音声通話が開かれることを意味します。「ファックス」は、通話がファクシミリ（テレファックス）の呼び出しであることを示しています。「モデム」とは、それがデータコールであることを意味します。すべてのネットワークが呼び出しの種類を区別するわけではありません。この場合、スキーム指定子は、使用する通信機器の種類を示します。
<telephone-subscriber> and <fax-subscriber> indicate the phone number to be dialed. The phone number can be written in either international or local notation. All phone numbers SHOULD always be written in the international form if there is no good reason to use the local form.
<Tholephone-subscriber>および<fax-subscriber>は、電話番号をダイヤルすることを示します。電話番号は、国際的またはローカル表記で書くことができます。すべての電話番号は、ローカルフォームを使用する正当な理由がない場合は、常に国際形式で記述する必要があります。
Not all numbers are valid within all numbering areas. The <area-specifier> parameter, which is mandatory for local numbers, is used to indicate the locale within which this number is valid, or to qualify the phone number so that it may be used unambiguously. The
すべての数字領域内ですべての数値が有効であるわけではありません。ローカル番号に必須である<エリアスペシファー>パラメーターは、この番号が有効なロケールを示すために使用されるか、電話番号を適格にして、明確に使用できるようにするために使用されます。
<area-specifier> can take three forms: <global-network-prefix>, <local-network-prefix> or <private-prefix>. These are used to describe the validity area of the phone number either in global numbering plan, local numbering plan, or in a private numbering plan, respectively.
<エリアスペシファー> <Global-Network-Prefix>、<Local-Network-Prefix>、または<Private-Prefix>の3つのフォームを取得できます。これらは、グローバルナンバリングプラン、ローカルナンバリングプラン、またはプライベート番号計画のいずれかで、電話番号の有効性領域を説明するために使用されます。
If <area-specifier> is present, the local entity MUST NOT attempt to call out using the phone number if it cannot originate the call within the specified locale. If a <local-phone-number> is used, an <area-specifier> MUST be included as well.
<Arie-specifier>が存在する場合、ローカルエンティティが指定されたロケール内で呼び出しを発信できない場合、電話番号を使用して呼び出そうとしないでください。<local-phone-number>を使用する場合は、<エリアスペシファー>も含める必要があります。
There can be multiple instances of <area-specifier>. In this case, the number is valid in all of the given numbering areas.
<エリアスペシファー>の複数のインスタンスがあります。この場合、数字はすべての指定された番号領域で有効です。
The global prefix form is intended to act as the outermost context for a phone number, so it will start with a "+", followed by some part of an E.164 number. It also specifies the region in which the phone number is valid. For example, if <global-network-prefix> is "+358", the given number is valid only within Finland (country code 358) - even if it is a <global-phone-number>.
グローバルプレフィックスフォームは、電話番号の最も外側のコンテキストとして機能することを目的としているため、 ""で開始され、E.164番号の一部が続きます。また、電話番号が有効な領域も指定します。たとえば、<Global-Network-Prefix>の場合、「358」の場合、指定された数値はフィンランド（国コード358）内でのみ有効です。
The local prefix form is intended to act as an intermediate context in those situations where the outermost context for a phone number is given by another means. One example of use is where the local entity is known to originate calls only within the North American Number Plan Area, so an "outermost" phone context can be assumed. The local context could, for example, be used to indicate the area code within which an associated phone number is situated. Thus "tel:456- 7890;phone-context=213" would suffice to deliver a call to the telephone number "+1-213-456-7890". Note that the version including the <phone-context> implies further that the call can only be originated within the "area code 213" region.
ローカルプレフィックスフォームは、電話番号の最も外側のコンテキストが別の手段によって与えられる状況で中間コンテキストとして機能することを目的としています。使用の1つの例は、ローカルエンティティが北米数計画領域内でのみ呼び出しを発信することが知られている場合、「最も外側の」電話コンテキストを想定できることです。たとえば、ローカルコンテキストを使用して、関連する電話番号が位置する市外局番を示すことができます。したがって、「Tel：456-7890; Phone-Context = 213」では、電話番号に電話をかけるのに十分で十分です」。<phone-context>を含むバージョンは、コールが「市内コード213」リージョン内でのみ発信されることをさらに示唆していることに注意してください。
The <private-prefix> form is intended for use in those situations where the context cannot be expressed with a start of a global phone number or a dialing string. The <private-prefix> is actually a name of a private context. The creator of the URL and the local entity have been configured to recognize this name, and as such they can interpret the number and know how they can utilize the number. For example, a private network numbering plan may be indicated by the name "X-COMPANY-NET", but the private dialling plan from the locales of the sender of the telephony URL and the local entity are different. The syntax of these tokens will be left for future specification. The ABNF above specifies the accepted characters that can be a part of <private-prefix>.
<private-prefix>フォームは、グローバルな電話番号またはダイヤリング文字列の開始でコンテキストを表現できない状況で使用することを目的としています。<private-prefix>は、実際にはプライベートコンテキストの名前です。URLとローカルエンティティの作成者は、この名前を認識するように構成されているため、数値を解釈し、数値をどのように利用できるかを知ることができます。たとえば、プライベートネットワーク番号の計画は「X-Company-net」という名前で示される場合がありますが、テレフォニーURLとローカルエンティティの送信者のロケールからのプライベートダイヤルプランは異なります。これらのトークンの構文は、将来の仕様のために残されます。上記のABNFは、<private-prefix>の一部になる可能性のある受け入れられた文字を指定します。
Unless the sender is absolutely sure that they share the same private network access digit string with the local entity, then they MUST NOT use a dialling plan number (a local phone number, or one qualified by a local context), as the result may be incorrect. Instead, they SHOULD use a global number, or if that is not possible, a private context as the last resort. If the local entity does not support dialling into the private network indicated by that context, then the request MUST be rejected. If it does, then it will use the access digit string appropriate for its locale.
送信者がローカルエンティティと同じプライベートネットワークアクセスの数字文字列を共有していることを絶対に確信していない限り、ダイヤルプラン番号（ローカルの電話番号、またはローカルコンテキストで資格のあるもの）を使用してはなりません。正しくない。代わりに、彼らはグローバルな数値を使用する必要があります。または、それが不可能な場合は、最後のリゾートとしてプライベートコンテキストです。ローカルエンティティがそのコンテキストで示されたプライベートネットワークへのダイヤルをサポートしていない場合、リクエストを拒否する必要があります。もしそうなら、ロケールに適したアクセス数字文字列を使用します。
Note that the use of <area-specifier> is orthogonal to use of the telephony service provider parameter (see 2.5.10); it qualifies the phone number, whilst the <service-provider> parameter indicates the carrier to be used for the call attempt.
<エリアスペシファー>の使用は、テレフォニーサービスプロバイダーパラメーターの使用に直交することに注意してください（2.5.10を参照）。<service-provider>パラメーターは、コールの試行に使用されるキャリアを示しますが、電話番号の資格があります。
For example, a large company may have private network interconnections between its sites, as well as connections to the Global Switched Telephone Network. A phone number may be given in "public network" form, but with a <service-provider> indicating that the call should be carried over the corporate network.
たとえば、大企業は、サイト間のプライベートネットワークの相互接続、およびグローバルスイッチド電話ネットワークへの接続を持っている場合があります。電話番号は「パブリックネットワーク」形式で提供される場合がありますが、<service-provider>では、コールをコーポレートネットワークに渡す必要があることを示しています。
Conversely, it would be possible to represent a phone number in private network form, with a private context to indicate this, but indicate a public telephony service provider. This would request that the user agent convert the private network number plan address into a form that can be carried using the selected service provider.
逆に、これを示すためにプライベートコンテキストを備えたプライベートネットワーク形式で電話番号を表すことが可能ですが、公開テレフォニーサービスプロバイダーを示します。これにより、ユーザーエージェントがプライベートネットワーク番号計画アドレスを選択したサービスプロバイダーを使用して運ぶことができるフォームに変換することが要求されます。
Any telephone number MUST contain at least one <phonedigit> or <dtmf-digit>, that is, subscriber numbers consisting only of pause characters are not allowed.
電話番号には、少なくとも1つの<phonedigit>または<dtmf-digit>、つまり、一時停止文字が許可されていないサブスクライバー番号が含まれている必要があります。
International numbers MUST begin with the "+" character. Local numbers MUST NOT contain that character. International numbers MUST be written with the country (CC) and national (NSN) numbers as specified in [E.123] and [E.164]. International numbers have the property of being totally unambiguous everywhere in the world if the local entity is properly configured.
国際的な数字は、「」キャラクターから始めなければなりません。ローカル番号にそのキャラクターが含まれてはなりません。[E.123]および[E.164]で指定されているように、国際数は国（CC）および国家（NSN）数を記述する必要があります。国際的な数字には、現地のエンティティが適切に構成されている場合、世界中のどこでも完全に明確になるという特性があります。
Local numbers MAY be used if the number only works from inside a certain geographical area or a network. Note that some numbers may work from several networks but not from the whole world - these SHOULD be written in international form, with a set of <area-specifier> tags and optional <service-provider> parameters. URLs containing local phone numbers should only appear in an environment where all local entities can get the call successfully set up by passing the number to the dialing entity "as is". An example could be a company intranet, where all local entities are located under a the same private telephone exchange. If local phone numbers are used, the document in which they are present SHOULD contain an indication of the context in which they are intended to be used, and an appropriate <area-specifier> SHOULD be present in the URL.
特定の地理的領域またはネットワーク内からのみが機能する場合、数字が使用される場合があります。一部の数字はいくつかのネットワークから機能する可能性がありますが、全世界では機能しないことに注意してください。これらは、<AREAM-Specifier>タグとオプションの<Service-Provider>パラメーターのセットを使用して、国際的な形で記述する必要があります。ローカルの電話番号を含むURLは、すべてのローカルエンティティが「現状のまま」ダイヤルエンティティに番号を渡すことにより、すべてのローカルエンティティがコールを正常に設定できる環境にのみ表示する必要があります。例は、すべてのローカルエンティティが同じプライベート電話交換の下にある会社のイントラネットです。ローカルの電話番号が使用されている場合、それらが存在するドキュメントには、それらを使用することを意図したコンテキストの兆候を含める必要があり、適切な<エリアスペシファー>がURLに存在する必要があります。
In some regions, it is popular to write phone numbers using alphabetic characters which correspond to certain numbers on the telephone keypad. Letters in <dtmf-digit> characters do not have anything to do with this, nor is this method supported by these URL schemes.
一部の地域では、電話キーパッドの特定の番号に対応するアルファベット文字を使用して電話番号を書くことが人気があります。<dtmf-digit>文字の文字は、これとは何の関係もありませんし、これらのURLスキームによってサポートされているこの方法もありません。
It should also be noted that implementations MUST NOT assume that telephone numbers have a maximum, minimum or fixed length, or that they would always begin with a certain number. Implementors are encouraged to familiarize themselves with the international standards.
また、実装は、電話番号が最大、最小、または固定された長さを持っていると仮定してはならないこと、または常に特定の数で開始することを想定してはならないことに注意する必要があります。実装者は、国際的な基準に精通することをお勧めします。
All <visual-separator> characters MUST be ignored by the local entity when using the URL. These characters are present only to aid readability: they MUST NOT have any other meaning. Note that although [E.123] recommends the use of space (SP) characters as the separators in printed telephone numbers, spaces MUST NOT be used in phone numbers in URLs as the space character cannot be used in URLs without escaping it.
URLを使用する場合、すべての<ビジュアルセパレーター>文字は、ローカルエンティティによって無視する必要があります。これらのキャラクターは、読みやすさを支援するためだけに存在します。他の意味を持たないはずです。[E.123]は、印刷された電話番号のセパレーターとしてスペース（SP）文字を使用することを推奨していますが、スペース文字はURLで使用できないため、URLの電話番号でスペースを使用しないでください。
After the telephone number has been extracted, it can be converted to the local dialing convention. (For example, the "+" character might be replaced by the international call prefix, or the international and trunk prefixes might be removed to place a local call.) Numbers that have been specified using <local-phone> or <fax-local-phone> MUST be used by the local entity "as is", without any conversions, unless the local entity decides to utilize the information in an optional <service-provider> parameter.
電話番号が抽出された後、ローカルダイヤル条約に変換できます。（たとえば、「」文字は、国際的なコールプレフィックスに置き換えられる場合があります。または、国際的なコールとトランクのプレフィックスを削除してローカルコールを配置する場合があります。）<Local-Phone>または<Fax-Local--を使用して指定された数字があります。電話>は、ローカルエンティティがオプションの<service-provider>パラメーターで情報を利用することを決定しない限り、コンバージョンなしで「現状のまま」で使用する必要があります。
The number may contain a <post-dial> sequence, which MUST be dialled using Dual Tone Multifrequency (DTMF) in-band signalling or pulse dialing after the call setup is complete. If the user agent does not support DTMF or pulse dialing after the call has been set up, <post-dial> MUST be ignored. In that case, the user SHOULD be notified.
数値には<ポストダイアル>シーケンスが含まれている場合があります。これは、コールのセットアップが完了した後、デュアルトーンマルチフェーク（DTMF）インバンドシグナリングまたはパルスダイヤルを使用してダイヤルする必要があります。ユーザーエージェントがコールが設定された後にDTMFまたはパルスダイヤルをサポートしていない場合、<ポストダイアル>を無視する必要があります。その場合、ユーザーに通知する必要があります。
A local phone number or a post-dial sequence may contain <pause-character> characters which indicate a pause while dialing ("p"), or a wait for dial tone ("w").
ローカルの電話番号またはダイヤル（ "P"）またはダイヤルトーン（ "w"）の待機中の一時停止を示す<pause-character>文字が含まれる場合があります。
Local entities MAY support this method of dialing, and the final interpretation of these characters is left to the local entity. It is RECOMMENDED that the length of each pause is about one second.
ローカルエンティティはこのダイヤル方法をサポートする場合があり、これらのキャラクターの最終的な解釈はローカルエンティティに委ねられます。各一時停止の長さは約1秒であることをお勧めします。
If it is not supported, local entities MUST ignore everything in the dial string after the first <pause-character> and the user SHOULD be notified. The user or the local entity MAY opt not to place a call if this feature is not supported and these characters are present in the URL.
サポートされていない場合、ローカルエンティティは、最初の<Pause-Character>の後にダイヤル文字列内のすべてを無視する必要があり、ユーザーに通知する必要があります。ユーザーまたはローカルエンティティは、この機能がサポートされておらず、これらの文字がURLに存在する場合、電話をかけないことを選択できます。
Any <dtmf-digit> characters and all dial string characters after the first <pause-character> or <dtmf-digit> SHOULD be sent to line using DTMF (Dual Tone Multifrequency) in-band signaling, even if dialing is done using direct network signaling (a digital subscriber loop or a mobile phone). If the local infrastructure does not support DTMF codes, the local entity MAY opt to use pulse dialing. However, it should be noted that certain services which are controlled using DTMF tones cannot be controlled with pulse dialing. If pulse dialing is used, the user SHOULD be notified.
最初の<Pause-Character>または<dtmf-digit>の後の<dtmf-digit>文字とすべてのダイヤル文字列文字は、ダイヤル化が直接使用されていても、dtmf（デュアルトーンマルチフェーク）を使用してLineに送信する必要があります。ネットワークシグナリング（デジタルサブスクライバーループまたは携帯電話）。ローカルインフラストラクチャがDTMFコードをサポートしていない場合、ローカルエンティティはパルスダイヤルを使用することを選択できます。ただし、DTMFトーンを使用して制御される特定のサービスは、パルスダイヤルで制御できないことに注意する必要があります。Pulseダイヤルを使用する場合は、ユーザーに通知する必要があります。
A phone number MAY also contain an <isdn-subaddress> which indicates an ISDN subaddress. The local entity SHOULD support ISDN subaddresses. These addresses are sent to the network by using a method available to the local entity (typically, ISDN subscribers send the address with the call setup signalling). If ISDN subaddressing is not supported by the caller, <isdn-subaddress> MUST be ignored and the user SHOULD be notified. The user or the local entity MAY opt not to place a call if this feature is not supported.
電話番号には、ISDNサブアドレスを示す<isdn-subaddress>も含まれている場合があります。ローカルエンティティは、ISDNサブアドレスをサポートする必要があります。これらのアドレスは、ローカルエンティティで利用可能な方法を使用してネットワークに送信されます（通常、ISDNサブスクライバーは、コールセットアップシグナリングでアドレスを送信します）。ISDNサブアドレスが発信者によってサポートされていない場合、<ISDN-SUBADDRESS>を無視する必要があり、ユーザーに通知する必要があります。ユーザーまたはローカルエンティティは、この機能がサポートされていない場合、通話を行わないことを選択する場合があります。
A fax number MAY also contain a <t33-subaddress>, which indicates the start of a T.33 subaddress [T.33]. Local entities SHOULD support this. Otherwise <t33-subaddress> MUST be ignored and the user SHOULD be notified. The user or the local entity MAY opt not to place a call if this feature is not supported.
FAX番号には、<T33-Subaddress>も含まれている場合があります。これは、T.33サブアドレスの開始を示しています[T.33]。ローカルエンティティはこれをサポートする必要があります。それ以外の場合は、<T33-Subaddress>を無視する必要があり、ユーザーに通知する必要があります。ユーザーまたはローカルエンティティは、この機能がサポートされていない場合、通話を行わないことを選択する場合があります。
<modem-params> indicate the minimum compliance required from the local entity to be able to connect to the remote entity. The minimum compliance is defined as being equal to or a superset of the capabilities of the listed modem type. There can be several <modem-param> parameters, in which case compliance to any one of them will be accepted. <recommended-params> indicates the recommended compliance required from the local entity. This is typically the fastest and/or the most reliable modem type supported by the modem pool. The local entity can use this information to select the best number from a group of modem URLs. There can be several recommended modem types, which are equally desirable from the modem pool's point of view. <recommended-params> MAY NOT conflict with <modem-params>. If they do, the local entity MUST ignore the <recommended-params>.
<Modem-Params>は、リモートエンティティに接続できるようにローカルエンティティから必要な最小コンプライアンスを示しています。最小コンプライアンスは、リストされているモデムタイプの機能の等またはスーパーセットであると定義されます。いくつかの<modem-param>パラメーターがあります。その場合、それらのいずれかへのコンプライアンスが受け入れられます。<推奨パラム>は、ローカルエンティティから必要な推奨コンプライアンスを示します。これは通常、モデムプールでサポートされる最速および/または最も信頼性の高いモデムタイプです。ローカルエンティティは、この情報を使用して、モデムURLのグループから最適な数字を選択できます。モデムプールの観点からも同様に望ましい、推奨されるモデムタイプがいくつかあります。<mosed-params> <modem-params>と矛盾しない場合があります。もしそうなら、ローカルエンティティは<推奨パラム>を無視する必要があります。
The local entity MUST call out using compatible hardware, or request that the network provides such a service.
ローカルエンティティは、互換性のあるハードウェアを使用して呼び出すか、ネットワークがそのようなサービスを提供することを要求する必要があります。
For example, if the local entity only has access to a V.22bis modem and the URL indicates that the minimum acceptable connection is V.32bis, the local entity MUST NOT try to connect to the remote host since V.22bis is a subset of V.32bis. However, if the URL lists V.32 as the minimum acceptable connection, the local entity can use V.32bis to create a connection since V.32bis is a superset of V.32.
たとえば、ローカルエンティティがV.22BISモデムにのみアクセスし、URLが最小許容接続がV.32BISであることを示している場合、v.22bisはのサブセットであるため、ローカルエンティティはリモートホストに接続しようとしてはなりません。v.32bis。ただし、V.32bisはV.32のスーパーセットであるため、URLが最小許容接続としてV.32をリストする場合、v.32bisを使用して接続を作成できます。
This feature is present because modem pools often have separate numbers for slow modems and fast modems, or have different numbers for analog and ISDN connections, or may use proprietary modems that are incompatible with standards. It is somewhat analogous to the connection type specifier (typecode) in FTP URLs [RFC1738]: it provides the local entity with information that can not be deduced from the scheme specifier, but is helpful for successful operation.
モデムプールには、遅いモデムと高速モデムの個別の数値があるか、アナログとISDN接続の異なる数値があるか、標準と互換性のない独自のモデムを使用する可能性があるため、この機能が存在します。これは、FTP URLS [RFC1738]の接続タイプ指定子（TypeCode）に多少類似しています。これは、スキーム指定子から推定できないが、操作を成功させるのに役立つ情報をローカルエンティティに提供します。
This also means that the number of data and stop bits and parity MUST be set according to the information given in the URL, or to default values given in this document, if the information is not present.
これはまた、情報が存在しない場合は、URLに記載されている情報、またはこのドキュメントで指定されたデフォルト値に従って、データと停止ビットとパリティの数を設定する必要があることを意味します。
The capability tokens are listed below. If capabilities suggest that it is impossible to create a connection, the connection MUST NOT be created.
トークンを以下にリストします。機能を作成することが不可能であることが示唆されている場合、接続を作成してはなりません。
If new modem types are standardized by ITU-T, this list can be extended with those capability tokens. Tokens are formed by taking the number of the standard and joining together the first letter (for example, "V"), number (for example, 22) and the first letter of the postfix (for example "bis" would become "b").
新しいモデムタイプがITU-Tによって標準化されている場合、このリストはそれらの機能トークンで拡張できます。トークンは、標準の番号を取得し、最初の文字（「V」など）、番号（22）、およびポストフィックスの最初の文字（たとえば「bis」が「b」になると結合することによって形成されます。）。
Proprietary modem types MUST be specified using the 'vendor naming tree', which takes the form "vnd.x.y", in which "x" is the name of the entity from which the specifications for the modem type can be acquired and "y" is the type or model of the modem. Vendor names MUST share the same name space with vendor names used in MIME types [RFC2048]. Submitting the modem types to ietf-types list for review is strongly recommended.
独自のモデムタイプは、「vnd.x.y」という形式を採用する「ベンダーネーミングツリー」を使用して指定する必要があります。「x」は、モデムタイプの仕様を取得して「y」できるエンティティの名前です。モデムのタイプまたはモデルです。ベンダー名は、MIMEタイプで使用されるベンダー名[RFC2048]と同じ名前スペースを共有する必要があります。レビューのためにモデムタイプをIETFタイプリストに送信することを強くお勧めします。
New capabilities MUST always be documented in an RFC, and they MUST refer to this document or a newer version of it. The documentation SHOULD also list the existing modem types with which the newly defined modem type is compatible with.
新しい機能は常にRFCに文書化する必要があり、このドキュメントまたは新しいバージョンを参照する必要があります。ドキュメントには、新しく定義されたモデムタイプが互換性のある既存のモデムタイプもリストする必要があります。
Capability Explanation
能力の説明
V21 ITU-T V.21
V22 ITU-T V.22
V22b ITU-T V.22bis
V23 ITU-T V.23
V26t ITU-T V.26ter
V32 ITU-T V.32
V32b ITU-T V.32bis
V34 ITU-T V.34
V90 ITU-T V.90
V110 ITU-T V.110
V120 ITU-T V.120
X75 ITU-T X.75
B103 Bell 103
B212 Bell 212
Data bits: "8" or "7" The number of data bits. If not
specified, defaults to "8".
Parity: "n", "e", "o", Parity. None, even, odd, mark or
"m", "s" space parity, respectively. If
not specified, defaults to "n".
Stop bits: "1" or "2" The number of stop bits. If not
specified, defaults to "1".
It is possible to indicate the identity of the telephony service provider for the given phone number. <service-provider> MAY be used by the user-agent to place the call using this network, to enhance the user interface, for billing estimates or to otherwise optimize its functionality. It MAY also be ignored by the user-agent. <service-provider> consists of a fully qualified Internet domain name of the telephony service provider, for example ";tsp=terrifictelecom.com". The syntax of the domain name follows Internet domain name rules and is defined in [RFC1035].
指定された電話番号のテレフォニーサービスプロバイダーの身元を示すことができます。<Service-Provider>は、ユーザーAgentがこのネットワークを使用してコールを配置したり、ユーザーインターフェイスを強化したり、見積もりを請求したり、その機能を最適化したりするために使用できます。また、ユーザーエージェントによって無視される場合があります。<Service-Provider>は、「; TSP = terrifictelecom.com」など、テレフォニーサービスプロバイダーの完全に適格なインターネットドメイン名で構成されています。ドメイン名の構文は、インターネットドメイン名ルールに従い、[RFC1035]で定義されています。
In addition to T.33 and ISDN subaddresses, modem types and area specifiers, future extensions to this URL scheme may add other additional parameters (<future-extension> in the BNF) to these URLs. These parameters are added to the URL after a semicolon (";"). Implementations MUST be prepared to handle additional and/or unknown parameters gracefully. Implementations MUST NOT use the URL if it contains unknown parameters, as they may be vital for the correct interpretation of the URL. Instead, the implementation SHOULD report an error.
T.33およびISDNサブアドレス、モデムタイプ、およびエリア指定器に加えて、このURLスキームへの将来の拡張は、これらのURLに他の追加パラメーター（<Future-Extension>）を追加する場合があります。これらのパラメーターは、セミコロン（ ";"）の後にURLに追加されます。実装は、追加および/または未知のパラメーターを優雅に処理するために準備する必要があります。URLの正しい解釈に不可欠である可能性があるため、不明なパラメーターが含まれている場合、実装はURLを使用してはなりません。代わりに、実装はエラーを報告する必要があります。
For example, <future-extension> 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. Whenever a <future-extension> is used in an open environment, its syntax and usage MUST be properly documented in an RFC.
たとえば、<future-Extension>を使用して、電話番号、その使用、または数に適用された変換に関するアプリケーション固有の追加データを保存できます。a <future-extension>がオープン環境で使用される場合はいつでも、その構文と使用はRFCで適切に文書化する必要があります。
<future-extension> nonterminal a rephrased version of, and compatible with the <other-param> as defined in [RFC2543] (which actually borrows BNF from an earlier version of this specification).
<future-extension>非末端は、[RFC2543]で定義されている<dother-Param>と互換性があります（実際には、この仕様の以前のバージョンからBNFを借用します）。
tel:+358-555-1234567
Tel：358-555-1234567
This URL points to a phone number in Finland capable of receiving voice calls. The hyphens are included to make the number more human-readable: country and area codes have been separated from the subscriber number.
このURLは、音声通話を受けることができるフィンランドの電話番号を指しています。ハイフンは、数値をより人間読みやすくするために含まれています。国と地域のコードは、加入者数から分離されています。
fax:+358.555.1234567
ファックス：358.555.1234567
The above URL describes a phone number which can receive fax calls. It uses dots instead of hyphens as separators, but they have no effect on the functionality.
上記のURLは、FAXコールを受信できる電話番号について説明しています。ハイフンの代わりにセパレーターとしてドットを使用しますが、機能には影響しません。
modem:+3585551234567;type=v32b?7e1;type=v110
This phone number belongs to an entity which is able to receive data calls. The local entity may opt to use either a ITU-T V.32bis modem (or a faster one, which is compatible with V.32bis), using settings of 7 data bits, even parity and one stop bit, or an ISDN connection using ITU-T V.110 protocol.
この電話番号は、データコールを受信できるエンティティに属します。ローカルエンティティは、7つのデータビット、パリティとワンストップビットの設定、または使用したISDN接続を使用して、ITU-T V.32BISモデム（またはv.32bisと互換性のあるより高速なモデム）を使用することを選択できます。ITU-T V.110プロトコル。
tel:+358-555-1234567;postd=pp22
The above URL instructs the local entity to place a voice call to +358-555-1234567, then wait for an implementation-dependent time (for example, two seconds) and emit two DTMF dialing tones "2" on the line (for example, to choose a particular extension number, or to invoke a particular service).
上記のURLは、ローカルエンティティに358-555-1234567にボイスコールを配置し、実装依存時間（たとえば、2秒）を待ち、ライン上の2つのDTMFダイヤルトーン「2」を発します（たとえば、特定の拡張番号を選択するか、特定のサービスを呼び出すため）。
tel:0w003585551234567;phone-context=+3585551234
This URL places a voice call to the given number. The number format is intended for local use: the first zero opens an outside line, the "w" character waits for a second dial tone, and the number already has the international access code appended to it ("00"). This kind of phone number MUST NOT be used in an environment where all users of this URL might not be able to successfully dial out by using this number directly. However, this might be appropriate for pages in a company intranet. The <area-specifier> which is present hints that the number is usable only in an environment where the local entity's phone number starts with the given string (perhaps singling out a company-wide block of telephone numbers).
このURLは、指定された番号に音声通話を配置します。数字形式はローカルの使用を目的としています。最初のゼロは外側の行を開き、「w」文字は2番目のダイヤルトーンを待機し、数値には既に国際アクセスコードが追加されています（ "00"）。この種の電話番号は、このURLのすべてのユーザーがこの番号を直接使用して正常にダイヤルアウトできない環境で使用してはなりません。ただし、これは会社のイントラネットのページに適している可能性があります。存在する<エリアスペシファー>は、数字が指定された文字列から始まる環境でのみ使用可能であることを示唆しています（おそらく、全社的な電話番号のブロックをシングルアウトしています）。
tel:+1234567890;phone-context=+1234;vnd.company.option=foo
The URL describes a phone number which, even if it is written in its international form, is only usable within the numbering area where phone numbers start with +1234. There is also a proprietary extension "vnd.company.option", which has the value "foo". The meaning of this extension is application-specific. Note that the order of these parameters (phone-context and vnd.company.option) is irrelevant.
URLは、電話番号が1234で始まる番号付け領域内でのみ使用できる電話番号を説明しています。「フー」。この拡張機能の意味はアプリケーション固有です。これらのパラメーターの順序（Phone-context and vnd.company.option）は無関係であることに注意してください。
URLs locate resources, which in this case is some telecommunications equipment at a given phone number. However, it is not necessarily enough to know the subscriber number in order to successfully communicate with that equipment. Digital phone networks distinguish between voice, fax and data calls (and possibly other types of calls, not discussed in this specification). To be able to successfully connect to, say, a fax machine, the caller may have to specify that a fax call is being made. Otherwise the call might be routed to the voice number of the subscriber. In this sense, the call type is an integral part of the 'location' of the target resource.
URLはリソースを見つけます。この場合、特定の電話番号にある通信機器があります。ただし、その機器と正常に通信するために、サブスクライバー数を知るだけでは必ずしも十分ではありません。デジタル電話ネットワークは、音声、FAX、およびデータコールを区別します（この仕様では議論されていない他の種類の呼び出し）。たとえば、ファックスマシンに正常に接続できるようにするには、発信者がファックスコールが行われていることを指定する必要がある場合があります。それ以外の場合、コールはサブスクライバーの音声番号にルーティングされる場合があります。この意味で、呼び出しタイプは、ターゲットリソースの「位置」の不可欠な部分です。
The reason to have the call type in the scheme specifier is to make the URL simple to remember and use. Making it a parameter, much like the way modem parameters are handled now, will substantially reduce the human readability of this URL.
スキーム仕様に呼び出しタイプを作成する理由は、URLを簡単に覚えて使用できるようにすることです。モデムパラメーターの処理方法と同様に、パラメーターにすることで、このURLの人間の読みやすさが大幅に低下します。
There has been discussion on whether the scheme name "tel" is appropriate. To summarize, these are the points made against the other proposals.
スキーム名「Tel」が適切かどうかについて議論がありました。要約すると、これらは他の提案に対して行われたポイントです。
callto URL schemes locate a resource and do not specify an action to be taken. telephone Too long. Also, "tel" considered to be a more international form. phone Was countered on the basis that "tel" is more internationally acceptable.
Callto URLスキームはリソースを見つけ、実行するアクションを指定しません。電話が長すぎる。また、「Tel」はより国際的な形であると考えられています。「電話」はより国際的に受け入れられることに基づいて、電話は反論されました。
E.164 refers to international telephone numbers, and the string of digits after the country code is usually a national matter. In any case, phone numbers are usually written as a simple string of numbers everywhere. Because of this, the syntax in this specification is intuitively clear to most people. This is the usual way to write phone numbers in business cards, advertisements, telephone books and so on.
E.164は国際的な電話番号を指し、国のコード後の一連の数字は通常、国家問題です。いずれにせよ、電話番号は通常、どこでも単純な数字の文字列として書かれています。このため、この仕様の構文は、ほとんどの人にとって直感的に明確です。これは、名刺、広告、電話帳などで電話番号を書く通常の方法です。
It should be noted that phone numbers may have 'hierarchical' characteristics, so that one could build a 'forest' of phone numbers with country codes as roots, area codes as branches and subscriber numbers as leaves. However, this is not always the case. Not all areas have area codes; some areas may have different area codes depending on how one wants to route the call; some numbers must always be dialled "as is", without prepending area or country codes (notably emergency numbers); and area codes can and do change.
電話番号には「階層的な」特性がある可能性があるため、国コードを使用して電話番号の「森林」を、枝としての面積コード、およびサブスクライバー数を葉として構築できるようにすることに注意する必要があります。ただし、これは必ずしもそうではありません。すべてのエリアにエリアコードがあるわけではありません。一部のエリアでは、通話のルーティング方法に応じて、異なるエリアコードがある場合があります。いくつかの数字は、常にエリアコードや国コード（特に緊急番号）を準備せずに「現状のまま」ダイヤルする必要があります。エリアコードは変更できます。
Usually, if something has a hierarchical structure, the URL syntax should reflect that fact. These URLs are an exception.
通常、何かが階層構造を持っている場合、URL構文はその事実を反映する必要があります。これらのURLは例外です。
Also, when writing the phone number in the form described in this specification, the writer does not need to know which part of the number is the country code and which part is the area code. If a hierarchical URL would be used (with a "/" character separating the parts of the phone numbers), the writer of the URL would have to know which parts are which.
また、この仕様で説明されているフォームで電話番号を書くとき、ライターは、番号のどの部分が国コードであり、どの部分が市外局番であるかを知る必要はありません。階層的なURLを使用する場合（電話番号の部分を分離する「/」文字を使用して、URLのライターはどの部分がどの部分であるかを知る必要があります。
Finally, when phone numbers are written in the international form as specified here, they are unambiguous and can always be converted to the local dialing convention, given that the user agent has the knowledge of the local country and area codes.
最後に、ここで指定されているように電話番号が国際的な形で記述されると、ユーザーエージェントが地元の国とエリアコードの知識を持っていることを考えると、それらは明確であり、常にローカルダイヤル条約に変換できます。
There are several ways for the subscriber to dial a phone number:
サブスクライバーが電話番号をダイヤルする方法はいくつかあります。
- By pulse dialing. Typically old telephone exchanges. Usually this dialing method has only to be used to set up the call; after connecting to the remote entity, <post-dial> can be sent to the line using DTMF, because it will typically be processed by the remote entity, not the telephone network.
- パルスダイヤルによる。通常、古い電話交換。通常、このダイヤル方法は、呼び出しのセットアップにのみ使用する必要があります。リモートエンティティに接続した後、<ポストダイアル>は、通常、電話ネットワークではなくリモートエンティティによって処理されるため、DTMFを使用してラインに送信できます。
- By DTMF. These are the 'beeps' that you hear when you dial on most phones.
- DTMFによって。これらは、ほとんどの電話でダイヤルするときに聞こえる「ビープ音」です。
- By direct network signalling. ISDN subscribers and mobile phone users usually have this. There is no dial tone (or if there is, it is generated locally by the equipment), and the number of the called party is communicated to the telephone network using some network signalling method. After setting up the call, <post-dial> sequences are usually sent using DTMF codes.
- 直接ネットワークシグナリングによる。ISDNのサブスクライバーと携帯電話のユーザーは通常、これを持っています。ダイヤルトーンはありません（または、ある場合、機器によってローカルに生成されます）、および呼び出された当事者の数は、何らかのネットワークシグナル伝達方法を使用して電話ネットワークに通知されます。コールを設定した後、<ポストダイアル>シーケンスは通常、DTMFコードを使用して送信されます。
As an example, +123456789 will be dialled in many countries as 00123456789, where the leading "00" is a prefix for international calls. However, if a URL contains a local phone number 00123456789, the user-agent MUST NOT assume that this number is equal to a global phone number +123456789. If a user-agent received a telephony URL with a local number in it, it MUST make sure that it knows the context in which the local phone number is to be processed, or else the number MUST NOT be used. Equally, anyone sending a telephony URL MUST take into consideration that the recipient may have insufficient information about the phone number's context.
例として、123456789は多くの国で00123456789としてダイヤルされ、主要な「00」は国際呼び出しの接頭辞です。ただし、URLにローカル電話番号00123456789が含まれている場合、ユーザーエージェントは、この番号がグローバルな電話番号123456789に等しいと仮定してはなりません。ローカルの電話番号を処理するコンテキストを知っていることを確認してください。そうしないと、番号を使用してはなりません。同様に、テレフォニーURLを送信する人は誰でも、受信者が電話番号のコンテキストに関する情報が不十分である可能性があることを考慮する必要があります。
These are examples of the recommended usage of this URL in HTML documents.
これらは、HTMLドキュメントでこのURLを推奨する使用の例です。
First of all, the number SHOULD be visible to the end user, if it is conceivable that the user might not have a local entity which is able to use these URLs.
まず第一に、ユーザーがこれらのURLを使用できるローカルエンティティを持っていないと考えられる場合は、エンドユーザーに数値を表示する必要があります。
Telephone: <a href="tel:+3585551234567">+358-555-1234567</a>
Second, on a public HTML page, the telephone number in the URL SHOULD always be in the international form, even if the text of the link uses some local format.
第二に、公開HTMLページでは、リンクのテキストがローカル形式を使用している場合でも、URLの電話番号は常に国際的な形式である必要があります。
Telephone: <a href="tel:+3585551234567">(0555) 1234567</a>
or even
あるいは
For more info, call <a href="tel:+15554383785965">1-555-IETF-RULZ-OK</a>.
詳細については、<a href="tel:15554383785965"> 1-555-ietf-rulz-ok </a>にお電話ください。
Moreover, if the number is a <local-phone-number>, and the scope of the number is not clear from the context in which the URL is displayed, a human-readable explanation SHOULD be included.
さらに、数値が<ローカルフォン番号>であり、数字の範囲がURLが表示されるコンテキストから明確でない場合、人間の読み取り可能な説明を含める必要があります。
For customer service, dial <a href="tel:1234;phone-context=+358555">1234</a> (only from Terrific Telecom mobile phones).
カスタマーサービスについては、<a href="tel:1234; phone-context= 358555"> 1234 </a>をダイヤルしてください（素晴らしいテレコム携帯電話からのみ）。
[RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。
[RFC1738] Berners-Lee, T., et al., "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[RFC1738] Berners-Lee、T.、et al。、「Uniform Resource Locators（URL）」、RFC 1738、1994年12月。
[RFC1866] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language - 2.0", RFC 1866, November 1995.
[RFC1866] Berners -Lee、T。およびD. Connolly、「Hypertext Markup Language -2.0」、RFC 1866、1995年11月。
[RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, November 1996.
[RFC2048] Freed、N.、Klensin、J。およびJ. Postel、「多目的インターネットメールエクステンション（MIME）パート4：登録手順」、RFC 2048、1996年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月。
[RFC2234] Crocker, D. and P. Overall, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC2234] Crocker、D。およびP.全体的に、「構文仕様のためのBNFの増強：ABNF」、RFC 2234、1997年11月。
[RFC2303] Allocchio, C., "Minimal PSTN Address Format in Internet Mail", RFC 2303, March 1998.
[RFC2303] Allocchio、C。、「インターネットメールの最小PSTNアドレス形式」、RFC 2303、1998年3月。
[RFC2304] Allocchio, C., "Minimal FAX Address Format in Internet Mail", RFC 2304, March 1998.
[RFC2304] Allocchio、C。、「インターネットメールの最小ファックスアドレス形式」、RFC 2304、1998年3月。
[RFC2396] Berners-Lee, T., R. Fielding and L. Manister, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC2396] Berners-Lee、T.、R。FieldingおよびL. Manister、「Uniform Resource Identiers（URI）：Generic Syntax」、RFC 2396、1998年8月。
[RFC2543] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[RFC2543] Handley、M.、Schulzrinne、H.、Schooler、E。and J. Rosenberg、「SIP：Session Intiation Protocol」、RFC 2543、1999年3月。
[E.123] ITU-T Recommendation E.123: Telephone Network and ISDN Operation, Numbering, Routing and Mobile Service: Notation for National and International Telephone Numbers. 1993.
[E.123] ITU-Tの推奨事項E.123：電話ネットワークとISDNの操作、番号付け、ルーティングとモバイルサービス：国内および国際的な電話番号の表記。1993年。
[E.164] ITU-T Recommendation E.164/I.331 (05/97): The International Public Telecommunication Numbering Plan. 1997.
[E.164] ITU-Tの推奨事項E.164/i.331（05/97）：国際的な電気通信番号計画。1997年。
[T.33] ITU-T Recommendation T.33: Facsimile Routing Utilizing the Subaddress. 1996.
[T.33] ITU-Tの推奨T.33：サブアドレスを利用したファクシミリルーティング。1996年。
It should be noted that the local entity SHOULD NOT call out without the knowledge of the user because of associated risks, which include
関連するリスクのために、ユーザーの知識なしではローカルエンティティが呼び出さないでください。
- call costs (including long calls, long distance calls, international calls and premium rate calls, or calls which do not terminate due to <post-dial> sequences that have been left out by the local entity)
- コールコスト（長距離通話、長距離コール、国際的な呼び出し、プレミアムレートコール、または現地エンティティによって除外された<ポストダイアル>シーケンスのために終了しないコールを含む）
- wrong numbers inserted on web pages by malicious users, or sent via e-mail, perhaps in direct advertising
- 悪意のあるユーザーによってWebページに挿入された間違った番号、またはおそらく直接広告で電子メールで送信される
- making the user's phone line unavailable (off-hook) for a malicious purpose
- ユーザーの電話回線を悪意のある目的のために利用できないようにする
- opening a data call to a remote host, thus possibly opening a back door to the user's computer
- リモートホストへのデータコールを開くため、ユーザーのコンピューターへのバックドアを開く可能性があります
- revealing the user's (possibly unlisted) phone number to the remote host in the caller identification data, and correlating the local entity's phone number with other information such as the e-mail or IP address
- 発信者識別データのリモートホストにユーザーの（おそらく非公開の）電話番号を明らかにし、ローカルエンティティの電話番号を電子メールやIPアドレスなどの他の情報と相関させる
- using the same local number in different contexts, in which the number may have a different meaning
- 異なるコンテキストで同じローカル数を使用すると、数字が異なる意味を持つ可能性があります
All of these risks MUST be taken into consideration when designing the local entity.
これらのリスクはすべて、ローカルエンティティを設計する際に考慮する必要があります。
The local entity SHOULD have some mechanism that the user can use to filter out unwanted numbers. The local entity SHOULD NOT use rapid redialing of the number if it is busy to avoid the congestion of the (signaling) network. Also, the local entity SHOULD detect if the number is unavailable or if the call is terminated before the dialing string has been completely processed (for example, the call is terminated while waiting for user input) and not try to call again, unless instructed by the user.
ローカルエンティティには、ユーザーが不要な数値を除外するために使用できるメカニズムが必要です。（シグナリング）ネットワークの輻輳を回避するのに忙しい場合、ローカルエンティティは、数の迅速な再編成を使用すべきではありません。また、ローカルエンティティは、番号が利用できないかどうか、またはダイヤル文字列が完全に処理される前にコールが終了するかどうかを検出する必要があります（たとえば、ユーザーの入力を待っている間に呼び出しが終了します）ユーザー。
Writing this specification would not have been possible without extensive support from many people.
この仕様を書くことは、多くの人々からの広範なサポートなしでは不可能でした。
Contributors include numerous people from IETF FAX, PINT, URI and URLREG mailing lists, as well as from World Wide Web Consortium and several companies, plus several individuals. Thanks to all people who offered criticism, corrections and feedback.
貢献者には、IETF Fax、Pint、URI、URLREGメーリングリスト、World Wide Webコンソーシアムや複数の企業、および複数の個人の多くの人々が含まれます。批判、修正、フィードバックを提供してくれたすべての人々に感謝します。
All phone numbers and company names used in the examples of this specification are fictional. Any similarities to real entities are coincidental.
この仕様の例で使用されているすべての電話番号と会社名は架空のものです。実際のエンティティとの類似点は偶然です。
Antti Vaha-Sipila (quoted-printable: Antti V=E4h=E4-Sipil=E4) Nokia Mobile Phones P. O. Box 68 FIN-33721 Tampere Finland
antti vaha-sipila（引用プリント可能：antti v = e4h = e4-sipil = e4）Nokia携帯電話P. O. Box 68 Fin-33721 Tampere Finland
EMail: avs@iki.fi
antti.vaha-sipila@nokia.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。