RFC2806 日本語訳
2806 URLs for Telephone Calls. A. Vaha-Sipila. April 2000. (Format: TXT=50647 bytes) (Obsoleted by RFC3966) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Vaha-Sipila Request for Comments: 2806 Nokia Category: Standards Track April 2000
Vaha-Sipilaがコメントのために要求するワーキンググループA.をネットワークでつないでください: 2806年のノキアカテゴリ: 標準化過程2000年4月
URLs for Telephone Calls
通話のためのURL
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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(Uniform Resource Locator)計画"tel"、「ファックス」、および「モデム」を指定します。 この仕様は音声通話(通常の電話、留守番電話、および声のメッセージシステム)をカバーしています、そして、ファクシミリ(テレファックス)は呼びます、そして、データは電話をします、POTSとデジタルであるか可動の加入者のために。
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
1. 序論… 2 1.1 新しいURL計画… 2 1.2 正式な定義… 3 1.3の要件… 3 2. URLは通話を計画します… 3 2.1の適用性… 3 2.2"tel"URL計画… 4 2.3はURL計画を「ファックスします」… 6 2.4「モデム」URL計画… 6 2.5 構文解析電話、ファックス、およびモデムURL… 7 2.5 .1 タイプに電話をしてください… 7 2.5 .2の電話番号とそれらの範囲… 7 2.5 電話番号の.3の分離符… 10 2.5 .4 地方のナンバリングスキームに数を変換します… 10 2.5 .5 呼び出しの後にポストダイヤル系列を送って、セットアップしてください… 10 2.5 .6 ダイヤルするのとポストダイヤル系列では、止まります… 11 2.5 .7ISDN「副-アドレス」… 11
Vaha-Sipila Standards Track [Page 1] RFC 2806 URLs for Telephone Calls April 2000
Vaha-Sipila規格は2000年4月に通話のためにRFC2806URLを追跡します[1ページ]。
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
2.5.8 T.33 subaddresses… 11 2.5 .9のデータ呼び出しパラメタ… 12 2.5 .10 電話サービスプロバイダー識別… 13 2.5 .11の追加パラメタ… 14 使用に関する2.6の例… 14 構文の後ろの2.7原理… 15 2.7 .1 なぜ呼び出しタイプを見分けますか? ..................... 15 2.7 .2 "tel"が"tel"である理由? ..................................... 16 2.7 .3 なぜ付番を使用にE.164流行に合わせますか? ........................ 16 2.7 .4 皆には、あなたと同じ設備があるというわけではありません… 17 2.7 .5 それらがどうダイヤルされるかに数を間違えないでください… 17 3. 用法のコメント… 17 4. 参照… 18 5. セキュリティ問題… 19 6. 承認… 20 7. 作者のアドレス… 20 8. 完全な著作権宣言文… 21
1. Introduction
1. 序論
1.1 New URL schemes
1.1 新しいURL計画
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.
この仕様は3つの新しいURL計画を定義します: "tel"、「ファックス」、および「モデム。」 彼らは、電話網を使用することで接触できる端末について説明するために意図します。 記述は、首尾よくその端末に接続できるように端末と必要なパラメタの加入者(電話)番号を含んでいます。
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].
「ファックス」計画はテレファックス(ファクシミリ)を扱うことができる端末に接続について説明します。 [E.123]によって推薦されるようにURLのための名前(計画特許説明書の作成書)は「ファックス」です。
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.
「モデム」計画は受信データ呼び出しを扱うことができる端末に接続について説明します。 「モデム」という用語はアナログにデジタルである状態でする装置とA/D変換について言及します。 これらに加えて、「モデム」計画は完全にデジタルの接続について説明できます。
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]で指定されます)。 しかしながら、構文定義はこのドキュメントがURLを指定するという事実で少し異なっていますが、[RFC2303]と[RFC2304]は電子メールアドレスを指定します。 「例えば」、/、」、取り替えた、(URLでは、階層的なURL[RFC2396]で部品を切り離すために、使用されます)」、;、」 さらに、このURL計画は[RFC2543]と同期しました。
Vaha-Sipila Standards Track [Page 2] RFC 2806 URLs for Telephone Calls April 2000
Vaha-Sipila規格は2000年4月に通話のためにRFC2806URLを追跡します[2ページ]。
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を持っているのが特に重要であるので、それは目に見えます。
1.2 Formal definitions
1.2 正式な定義
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(BN記法を増大させる)記法は[RFC2234]に続きます。 この仕様は'コア'定義([RFC2234]の付録A)から要素を使用します。 いくつかの要素が前のRFCsで定義されました。 これがそうであるなら、問題の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.
URLに非無遠慮な性格に[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インチ(米国-ASCIIにおける間隔文字)」の16進値があるただ一つの八重奏を意味します。 %20インチ「URLでこれから逃げなければなりません、そして、なります」。
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は大文字と小文字を区別しないです(ケース感度がアプリケーション特有である<の今後の拡大している>パラメタを除いた)。
1.3 Requirements
1.3 要件
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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Compliant software MUST follow this specification.
対応するソフトウェアはこの仕様に従わなければなりません。
2. URL schemes for telephone calls
2. 通話のURL計画
2.1 Applicability
2.1 適用性
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
電話網を使用することで電話をするようローカル要素に指示するのに使用されるか、電話番号を移すか、または格納する方法と他の関連データとしてこれらのURL計画があります。 問題のネットワークはそうです。
Vaha-Sipila Standards Track [Page 3] RFC 2806 URLs for Telephone Calls April 2000
Vaha-Sipila規格は2000年4月に通話のためにRFC2806URLを追跡します[3ページ]。
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はリモート実体の能力の情報を含むことができます、首尾よく接続を確立できるように。
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"、「ファックス」、および「モデム」URL計画は階層的なURL構文を使用しません。 どんな適切な相対的なURLフォームもありません。URLはいつも大文字と小文字を区別しないです、ケース感度がアプリケーション特有である<の今後の拡大している>パラメタ(以下を見る)を除いて。 [RFC2396]で説明されるように必要であると、URLのキャラクターから逃げなければなりません。
2.2 "tel" URL scheme
2.2 "tel"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]
「電話-urlは電話計画と等しい」:、」 電話加入者電話計画は「+」 "tel"電話加入者=ローカルのグローバルな電話番号/電話番号グローバルな電話番号=ベース電話番号isdn-subaddressポストダイヤル*(今後の領域特許説明書の作成書/サービスプロバイダー/拡大)ベース電話番号=1*phonedigitとローカルの電話番号で等しいです; 「=1*(くぎりphonedigit / dtmf-ケタ/キャラクタ)isdn-subaddressポストダイヤル領域特許説明書の作成書*(今後の領域特許説明書の作成書/サービスプロバイダー/拡大)isdn-subaddress=」 」 1*phonedigitポストダイヤルisub==、」、;、postdが」 1*(くぎりphonedigit / dtmf-ケタ/キャラクタ)領域特許説明書の作成書=と等しい 」、;、」 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) ; 規則から逃げて、URLのキャラクターは従わなければなりません。 説明されたコネとして[RFC2396]
Vaha-Sipila Standards Track [Page 4] RFC 2806 URLs for Telephone Calls April 2000
Vaha-Sipila規格は2000年4月に通話のためにRFC2806URLを追跡します[4ページ]。
; 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"
; 「セクション1.2と2.5.2サービスプロバイダー=を見てください」;、」 プロバイダータグ「=」プロバイダーホスト名プロバイダータグは「ティースプーンフル」プロバイダーホスト名=ドメインと等しいです。 <ドメイン>は[RFC1035]で定義されます。 「セクション2.5.10の今後の拡大が等しいのを確実にしてください」;、」 1*(象徴炭)[「=」(1*(象徴炭)[“?"1*(象徴炭)])/引用文字列]。 (%x21/%x23-27/%x2A-2B/%x2D-2E/%x30-39/%x41-5A/%x5E-7A/%x7C/%x7E)は、セクション2.5.11と[RFC2543]象徴炭が等しいのを見ます。 規則から逃げて、URLのキャラクターは従わなければなりません。 [RFC2396]で説明されるように。 %x22*(「\」炭/(%x20-21/%x23-7E/%x80-ff))%x22は、セクション1.2と2.5.11引用文字列が等しいのを見ます。 規則から逃げて、URLのキャラクターは従わなければなりません。 [RFC2396]で説明されるように。 「セクション1.2と2.5.11が=視覚DIGIT/分離符視覚分離符=「-」/をphonedigitするのを見てください」、」 ダイヤルトーンのための2分の1つのくぎり/待ちの2分の1つの「(「/」)」という/くぎりキャラクタ=くぎりは/「B」/「p」ダイヤルトーンのための待ち=「w」dtmf-ケタ=「*」/「#」/「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は<電話計画>から始まります。(>は続くことが本書では説明されるように分析されるべきである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
市内番号には、>が<領域特許説明書の作成書のためにいつもあります(数が使用可能である文脈を指定します)(同じ数は異なったネットワーク部門に異なった解釈を持っているかもしれません)。 3つの異なった接頭語で文脈を示すことができます。 <のグローバルなネットワークの接頭語の>は、数がグローバルな番号が<のグローバルなネットワークの接頭語の>から始まる付番領域の中で有効であることを示します。 同様に、<のローカルのネットワークの接頭語の>は、数がaの中で有効であることを意味します。
Vaha-Sipila Standards Track [Page 5] RFC 2806 URLs for Telephone Calls April 2000
Vaha-Sipila規格は2000年4月に通話のためにRFC2806URLを追跡します[5ページ]。
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.
番号(ストリングにダイヤルする)がそれから始まる領域に付番します。 <の個人的な接頭語の>は文脈の名前です。 ローカル要素には、それが数を使用できるか否かに関係なく、できる推論するこの個人的な関係に関する知識がなければなりません、とセクション2.5.2は見ます。 <サービスプロバイダー>の電話サービスプロバイダーの名前を加えることによって、電話番号の用法に関する追加情報を含むことができます、とセクション2.5.10は見ます。
The <future-extension> mechanism makes it possible to add new parameters to this URL scheme. See section 2.5.11.
<の今後の拡大している>メカニズムで、この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].
<の個人的な接頭語>、<象徴炭の>、および<引用文字列>「非-端末」は初めに、少し複雑に見えるかもしれませんが、彼らは単にそれらの「非-端末」で法的な八重奏のセットについて説明します。 [RFC2396]は、いくつかの八重奏逃げられなければならないかもしれないのを見ます。
2.3 "fax" URL scheme
2.3 「ファックス」URL計画
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
「ファックス-urlはファックス計画と等しい」:、」 「ファックスで地方の電話を送っているファックスグローバルなファックスで計画を送っているファックス加入者=「ファックス」=ファックスグローバルなファックス加入者電話/電話は「+」 ファックスで地方の電話を送っているベース電話番号[isdn-subaddress][t33-subaddress][ポストダイヤル]*(今後の領域特許説明書の作成書/サービスプロバイダー/拡大)=1*(くぎりphonedigit / dtmf-ケタ/キャラクタ)[isdn-subaddress][t33-subaddress][ポストダイヤル]領域特許説明書の作成書*(今後の領域特許説明書の作成書/サービスプロバイダー/拡大)t33-subaddress=と等しい」; 」 1tsub=*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.
fax: URLはtel:と非常に同様です。 URL。 主な違いはまた、ISDN「副-アドレス」に加えてテレファックスが別のタイプの「副-アドレス」を持っているということです、とセクション2.5.8が見ます。
2.4 "modem" URL scheme
2.4 「モデム」URL計画
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]を見てください。
Vaha-Sipila Standards Track [Page 6] RFC 2806 URLs for Telephone Calls April 2000
Vaha-Sipila規格は2000年4月に通話のためにRFC2806URLを追跡します[6ページ]。
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 / "-" / "+")
「モデム-urlはモデム計画と等しい」:、」 」 データ能力データ「リモートホストモデム計画は「モデム」 リモートホスト=電話加入者*(お勧めのモデム-params/params)は=をモデムでparamsすること」と等しいです; タイプは」 データ能力お勧めのparams=と等しい」; recする=能力は受け入れられたモデム“?"データ・ビットパリティストップビット受け入れられたモデム=「V21"/」と等しいです; 「X75"/は「. 」 業者名をvndします」。」(アルファ/ケタ/「-」/「+」)
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:と非常に同様です。 そして、ファックスで以下を送ってください。 しかし、計画、それはリモート実体の能力の記述を加えます。 最小の必要な承諾は<モデム-paramsに記載されていて、>とお勧めのコンプライアンスが<のお勧めのparamsの>に記載されているということです。 詳細に関しては、セクション2.5.9を見てください。
2.5 Parsing telephone, fax and modem URLs
2.5 構文解析電話、ファックス、およびモデムURL
2.5.1 Call type
2.5.1 タイプに電話をしてください。
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"は、音声通話が開かれることを意味します。 「ファックス」は、呼び出しがファクシミリ(テレファックス)電話することであるべきであることを示します。 「モデム」は、それがデータ電話することであるべきであることを意味します。 すべてのネットワークが呼び出しのタイプを区別するというわけではありません。 この場合、計画特許説明書の作成書は使用する通信機器タイプを示します。
2.5.2 Phone numbers and their scope
2.5.2 電話番号とそれらの範囲
<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.
<電話加入者>と<ファックス加入者>は、ダイヤルされるために電話番号を示します。 国際的であるかローカルの記法で電話番号を書くことができます。 SHOULDが地方を使用するためにもっともな理由が全くなければ国際的で形成されるといつも書かれているすべての電話番号が形成されます。
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
すべての数がどんなすべての付番領域の中で有効であるというわけではありません。 >パラメタ(市内番号に義務的である)が使用されている<領域特許説明書の作成書がこの数が有効である現場を示すか、または資格を与えるように電話番号に資格を与えるのに、明白に使用されてください。 The
Vaha-Sipila Standards Track [Page 7] RFC 2806 URLs for Telephone Calls April 2000
Vaha-Sipila規格は2000年4月に通話のためにRFC2806URLを追跡します[7ページ]。
<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.
<領域特許説明書の作成書>は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.
<領域特許説明書の作成書>が存在しているなら、ローカル要素は、指定された現場の中で呼び出しを溯源できないなら電話番号を使用することで大声で叫ぶのを試みてはいけません。 <のローカルの電話番号の>が使用されているなら、また、含まれていて、>がそうしなければならない<領域特許説明書の作成書です。
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番号の何らかの部分が「+」から始めるためにあとに続くのに機能することを意図します。 また、それは電話番号が有効である領域を指定します。 例えば、<のグローバルなネットワークの接頭語の>が「+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つの例がローカル要素が北米のNumber Plan Areaだけの中で呼び出しを溯源するのが知られているので「一番はずれ」の電話文脈を思うことができるところです。 例えば、ローカルの関係は、関連電話番号が位置している市外局番を示すのに使用されるかもしれません。 したがって、「tel:456電話7890;文脈=213」は、「+1-213-456-7890」という電話番号への要求を提供するために十分でしょう。 <電話文脈>を含むバージョンが、「市外局番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>.
<の個人的な接頭語の>フォームはそれらの状況における使用のためにぎくっとして文脈を言い表すことができないところでグローバルな電話番号かダイヤルするストリングについて意図します。 <の個人的な接頭語>は実際に個人的な関係の名前です。 URLの創造者とローカル要素がこの名前を認識するために構成されて、彼らは、そういうものとして、数を解釈して、どうしたら数を利用できるかを知ることができます。 例えば、個人的なネットワーク付番プランは名前「X会社のネット」によって簡単に述べられるかもしれませんが、電話URLの送付者の現場からの個人的なダイヤルするプランとローカル要素は異なっています。 これらの象徴の構文は将来の仕様に残されるでしょう。 上のABNFは<の個人的な接頭語の>の一部であるかもしれない受け入れられたキャラクタを指定します。
Vaha-Sipila Standards Track [Page 8] RFC 2806 URLs for Telephone Calls April 2000
Vaha-Sipila規格は2000年4月に通話のためにRFC2806URLを追跡します[8ページ]。
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.
送付者が彼らが同じ個人的なネットワークアクセスケタストリングをローカル要素と共有して、次に、ダイヤルすることを使用してはいけないのを絶対に確信していない場合、数(ローカルの電話番号、またはローカルの関係によって資格があったもの)を計画してください、結果が不正確であるかもしれないので。 代わりにそれら、SHOULDが使用する、グローバルな数かそれが可能でないかどうか、切り札としての個人的な関係。 ローカル要素が、その文脈によって示された私設のネットワークにダイヤルするのを支持しないなら、要求を拒絶しなければなりません。 そうすると、それは現場に、適切なアクセスケタストリングを使用するでしょう。
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、)、。 それは電話番号に資格を与えますが、<サービスプロバイダー>パラメタは、呼び出し試みに使用されるために運送業者を示します。
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.
例えば、大企業はサイトの間に個人的なネットワーク相互接続を持っているかもしれません、Global Switched Telephone Networkとの接続と同様に。 電話番号は、「公衆通信回線」フォームで与えますが、<サービスプロバイダー>が、呼び出しが企業ネットワークの上まで運ばれるべきであるのを示していて、与えるかもしれません。
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ケタの>を含まなければなりません、すなわち、くぎりのキャラクタだけから成る加入者番号は許容されていません。
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.
国際数は「+」キャラクタと共に始まらなければなりません。 市内番号はそのキャラクタを含んではいけません。 指定されるとしての国(CC)と国家の(NSN)番号が[E.123]と[E.164]にある状態で、国際数を書かなければなりません。 ローカル要素が適切に構成されるなら、国際数は世界のいたる所に完全に明白であることの特性を持っています。
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,
数が、ある一定の地理的な領域かネットワークの中から働いているだけであるなら、市内番号は使用されるかもしれません。 数個の数がいくつかのネットワークから働くかもしれないことに注意しますが、全世界から注意するというわけではなくなってください--これらのSHOULDが国際的なフォームに書かれていて、aで、パラメタは<領域特許説明書の作成書の>タグと任意の<サービスプロバイダー>にセットしていました。 ローカルの電話番号を含むURLは環境ですべてのローカル要素で「そのままで」ダイヤルする実体に数を通過することによって呼び出しを首尾よくセットアップできるところに現れるだけであるはずです。 例は会社のイントラネットであるかもしれません。(そこでは、すべてのローカル要素が同じ私設電話機交換で位置しています)。 ローカルの電話番号が使用されているなら
Vaha-Sipila Standards Track [Page 9] RFC 2806 URLs for Telephone Calls April 2000
Vaha-Sipila規格は2000年4月に通話のためにRFC2806URLを追跡します[9ページ]。
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.
それらが現在のSHOULDが現在のコネがURLであったなら彼らが使用されることを意図する文脈のしるし、および適切な<領域特許説明書の作成書>SHOULDを含んでいるということであるドキュメント。
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-ケタにおける手紙には、何もこれを処理するものがありません、そして、この方法はこれらの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.
また、実現が、電話番号には最大の、または、最小の、または、固定された長さがあるか、またはいつもある数で始まると仮定してはいけないことに注意されるべきです。 作成者が世界規格に慣れるよう奨励されます。
2.5.3 Separators in phone numbers
2.5.3 電話番号の分離符
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の電話番号に空間を使用してはいけないことに注意してください。
2.5.4 Converting the number to the local numbering scheme
2.5.4 地方のナンバリングスキームに数を変換すること。
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.
電話番号が抜粋された後に、地方のダイヤルするコンベンションにそれを変えることができます。 (例えば、「+」キャラクタを国際電話接頭語に取り替えるか、または市内通話を置くために国際的、そして、トランク接頭語を移すかもしれません。) ローカル要素で「そのままで」<の地方の電話>か<のファックス地方の電話>を使用することで指定された数を使用しなければなりません、少しも変換なしで、ローカル要素が、任意の<サービスプロバイダー>パラメタの情報を利用すると決めない場合。
2.5.5 Sending post-dial sequence after call setup
2.5.5 呼び出しセットアップの後にポストダイヤル系列を送ること。
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.
数はダイヤル>を掲示している<系列を含むかもしれません。(呼び出しセットアップが完全になった後にバンドにおけるDual利根Multifrequency(DTMF)合図かパルスのダイヤルすることを使用して、それにダイヤルしなければなりません)。 呼び出しがセットアップされた後にユーザエージェントがDTMFかパルスのダイヤルすることを支持しないなら、<ポストダイヤル>を無視しなければなりません。 その場合、ユーザSHOULD、通知されてください。
Vaha-Sipila Standards Track [Page 10] RFC 2806 URLs for Telephone Calls April 2000
Vaha-Sipila規格は2000年4月に通話のためにRFC2806URLを追跡します[10ページ]。
2.5.6 Pauses in dialing and post-dial sequence
2.5.6 ダイヤルすることにおけるくぎりとポストダイヤル系列
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」)のための待ちを含むかもしれません。
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秒であることはRECOMMENDEDです。
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.
支持されて、地方の実体がすべてを無視しなければならないということでないなら、最初の<くぎりキャラクタ>とユーザSHOULDの後のダイヤルストリングで通知されてください。 ユーザかローカル要素が、この特徴が支持されないで、これらのキャラクタが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.
どんな<dtmf-ケタにも、>キャラクタとすべてが最初の<くぎりキャラクタ>の後にストリングキャラクタにダイヤルするか、またはバンドにおけるDTMF(二元的な利根Multifrequency)シグナリングを使用することで立ち並ぶために<dtmf-ケタ>SHOULDを送って、ダイヤルするのがされた使用であってもネットワークシグナリング(デジタル加入者輪か携帯電話)を指示してください。 ローカルのインフラストラクチャがDTMFコードをサポートしないなら、ローカル要素は、パルスのダイヤルすることを使用するために選ばれるかもしれません。 しかしながら、パルスのダイヤルすることでDTMFトーンを使用することで制御されたあるサービスは制御できないことに注意されるべきです。 ダイヤルするのはパルスであるなら使用されていて、ユーザはSHOULDです。通知されます。
2.5.7 ISDN subaddresses
2.5.7 ISDN「副-アドレス」
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>を含むかもしれません。 ローカル要素SHOULDはISDN「副-アドレス」を支持します。 ローカル要素に利用可能な方法を使用することによって、これらのアドレスをネットワークに送ります(呼び出しセットアップが合図している状態で、通常、ISDN加入者はアドレスを送ります)。 ISDN副記述が訪問者によって支持されないで、<isdn-subaddress>を無視しなければならないということであり、ユーザがSHOULDであるなら、通知されてください。 ユーザかローカル要素が、この特徴が支持されないなら電話をしないように選ばれるかもしれません。
2.5.8 T.33 subaddresses
2.5.8 T.33 subaddresses
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.
また、ファックス番号は<t33-subaddress>を含むかもしれません。(>はT.33 subaddress[T.33]の始まりを示します)。 ローカル要素SHOULDはこれを支持します。 さもなければ、<t33-subaddress>は無視されていてユーザSHOULDであるに違いありません。通知されます。 ユーザかローカル要素が、この特徴が支持されないなら電話をしないように選ばれるかもしれません。
Vaha-Sipila Standards Track [Page 11] RFC 2806 URLs for Telephone Calls April 2000
Vaha-Sipila規格は2000年4月に通話のためにRFC2806URLを追跡します[11ページ]。
2.5.9 Data call parameters
2.5.9 データ呼び出しパラメタ
<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>.
>が、最小のコンプライアンスが、ローカル要素からリモート実体に接続できるのを必要としたのを示す<モデム-params。 最小のコンプライアンスは等しくて、記載されたモデムタイプの能力のスーパーセットであると定義されます。 そこでは、数個<モデム-paramが>パラメタであったなら受け入れることができて、その場合、それらのどれかへのコンプライアンスを受け入れるでしょう。 <のお勧めのparamsの>は、お勧めのコンプライアンスがローカル要素から必要であることを示します。 これは通常最も速い、そして/または、モデムプールによって支持される中で最も頼もしいモデムタイプです。 ローカル要素は、モデムURLのグループから最も良い数を選択するのにこの情報を使用できます。 いくつかのお勧めのモデムタイプがあることができます。(タイプはモデムプールの観点から等しく望ましいです)。 <モデム-paramsとの衝突ではなく、<のお勧めのparamsの>5月の>。 そうするなら、ローカル要素は<のお勧めの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の部分集合であるので、リモートホストに接しようとしてはいけません。 しかしながら、URLが最小の許容できる接続にV.32について記載するなら、ローカル要素は、V.32bisが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 URL[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)、および最初の手紙(例えば、「2回」「b」になる)を結合させることによって、形成されます。
Vaha-Sipila Standards Track [Page 12] RFC 2806 URLs for Telephone Calls April 2000
Vaha-Sipila規格は2000年4月に通話のためにRFC2806URLを追跡します[12ページ]。
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.
'業者命名木'(「x」が「y」がモデムのモデムタイプへの仕様を取得できて、タイプかモデルである実体の名前であるフォーム"vnd.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に記録しなければなりません、そして、彼らはそれのこのドキュメントか、より新しいバージョンを示さなければなりません。 また、新たに定義されたモデムタイプはどれと互換性があるかでドキュメンテーションSHOULDが既存のモデムタイプを記載します。
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".
V21 ITU-T V.21 V22 ITU-T V.22 V22b ITU-T V.22bis V23ITU-T V.23 V26t ITU-T V.26ter V32ITU-T V.32 V32b ITU-T V.32bis V34ITU-T V.34 V90 ITU-T V.90 V110 ITU-T V.110 V120 ITU-T V.120 X75 ITU-T X.75 B103ベル103・B212ベル212Dataビット: または、「8インチ、「7インチ、データ・ビットの数、」 指定..デフォルト..8インチ 同等: 「n」、「e」、「o」の同等。 それぞれなにもか同等の、そして、変なマークか「m」、「s」スペースの同等。 指定..デフォルト ストップビット: または、「1インチ、「2インチ、ストップビットの数、」 指定..デフォルト..1インチ
2.5.10 Telephony service provider identification
2.5.10 電話サービスプロバイダー識別
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].
与えられた電話番号のために電話サービスプロバイダーのアイデンティティを示すのは可能です。 <サービスプロバイダー>は、このネットワークを使用することで電話をするか、支払い見積りのためにユーザーインタフェースを高めるか、またはそうでなければ、機能性を最適化するのにユーザエージェントによって使用されるかもしれません。 また、それはユーザエージェントによって無視されるかもしれません。 「例えば、<サービスプロバイダー>は電話サービスプロバイダーの完全に適切なインターネットドメイン名から成る」; ティースプーンフルがterrifictelecom.comと等しい、」 ドメイン名の構文は、インターネットドメイン名前規則に従って、[RFC1035]で定義されます。
Vaha-Sipila Standards Track [Page 13] RFC 2806 URLs for Telephone Calls April 2000
Vaha-Sipila規格は2000年4月に通話のためにRFC2806URLを追跡します[13ページ]。
2.5.11 Additional parameters
2.5.11 追加パラメタ
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計画への今後の拡大は他の追加パラメタ(BNFの<未来延期>)をこれらのURLに追加するかもしれません。 これらのパラメタがセミコロンの後にURLに追加される、(「」、) 優雅に追加しているそして/または、未知のパラメタを扱うように実現を準備しなければなりません。 未知のパラメタを含んでいるなら、実現はURLを使用してはいけません、URLの正しい解釈に、それらが重大であるかもしれないので。 代わりに、実現SHOULDは誤りを報告します。
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.
例えば、数に適用された電話番号、意図している使用、またはどんな変換に関するアプリケーションの特定の追加データも格納するのに<未来延期>を使用できます。 <の今後の拡大している>がオープンな環境に使用されるときはいつも、適切にその構文と用法を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).
<の今後の拡大している>非終端記号、言い直されたバージョン、[RFC2543](実際にこの仕様の以前のバージョンからBNFを借りる)で定義される<の他にparamな>と互換性があります。
2.6 Examples of Use
2.6 使用に関する例
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
fax: +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はファックス呼び出しを受けることができる電話番号について説明します。 それは分離符としてのハイフンの代わりにドットを使用しますが、それらは機能性で効き目がありません。
modem:+3585551234567;type=v32b?7e1;type=v110
モデム: +3585551234567; タイプ=v32b--7e1; =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.
この電話番号はデータ呼び出しを受けることができる実体に属します。 ローカル要素は、ITU-T V.110プロトコルを使用することでITU-T V.32bisモデム(または、V.32bisと互換性があるより速いもの)、7データ・ビットの設定を使用する、偶数パリティ、および1つのストップビットかISDN接続のどちらかを使用するために選ばれるかもしれません。
Vaha-Sipila Standards Track [Page 14] RFC 2806 URLs for Telephone Calls April 2000
Vaha-Sipila規格は2000年4月に通話のためにRFC2806URLを追跡します[14ページ]。
tel:+358-555-1234567;postd=pp22
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インチ危う(例えば特定の内線電話番号を選ぶか、または特定のサービスを呼び出す)」状態でトーンにダイヤルする2DTMFを放つようローカル要素に命令します。
tel:0w003585551234567;phone-context=+3585551234
tel:0w003585551234567; 電話文脈は+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」キャラクタが一瞬ダイヤルトーンを待っていて、数で既に国際的なアクセスコードをそれに追加する、(「0インチ)」 このURLのすべてのユーザが首尾よく直接使用するのによるこの番号にダイヤルすることができるかもしれないというわけではない環境でこの種類の電話番号を使用してはいけません。 しかしながら、ページに、これは会社のイントラネットで適切であるかもしれません。 存在している<領域特許説明書の作成書>は、数がローカル要素の電話番号が与えられたストリングから始まる(恐らく電話番号の会社の全体のブロックを選び抜いて)ところで環境だけで使用可能であると暗示します。
tel:+1234567890;phone-context=+1234;vnd.company.option=foo
tel: +1234567890; 電話文脈=+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から始まる使用可能な電話番号について説明します。 また、独占拡大"vnd.company.option"があります。(それは、値の"foo"を持っています)。 この拡大の意味はアプリケーション特有です。 これらのパラメタ(電話文脈とvnd.company.option)の注文が無関係であることに注意してください。
2.7 Rationale behind the syntax
2.7 構文の後ろの原理
2.7.1 Why distinguish between call types?
2.7.1 なぜ呼び出しタイプを見分けますか?
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は与えられた電話番号にはいくらかの通信機器がこの場合あるリソースの場所を見つけます。 しかしながら、それは、その設備で首尾よく交信するために加入者番号を知るために必ず十分であるというわけではありません。 デジタル電話ネットワークは声、ファックス、およびデータ要求(そして、この仕様で議論しなかったことによると他のタイプの呼び出し)を見分けます。 首尾よくたとえば、ファックス装置に接続できるように、訪問者は、ファックス電話をかけていると指定しなければならないかもしれません。 さもなければ、呼び出しは加入者の声の番号に発送されるかもしれません。 この意味で、呼び出しタイプは目標リソースの'位置'の不可欠の部分です。
Vaha-Sipila Standards Track [Page 15] RFC 2806 URLs for Telephone Calls April 2000
Vaha-Sipila規格は2000年4月に通話のためにRFC2806URLを追跡します[15ページ]。
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の人間の読み易さはかなり減少するでしょう。
2.7.2 Why "tel" is "tel"?
2.7.2 "tel"が"tel"である理由?
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計画は、リソースの場所を見つけて、取るために動作を指定しません。長い間、Tooに電話をしてください。 また、"tel"は、より国際的なフォームであると考えました。電話Wasは、ベースで"tel"が、より国際的に許容できると反対しました。
2.7.3 Why to use E.164-style numbering?
2.7.3 なぜ付番を使用にE.164流行に合わせますか?
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.
電話番号には'階層的な'特性があるかもしれないことに注意されるべきです、人が葉としてルーツとしての国名略号、ブランチとしての市外局番、および加入者番号で電話番号の'森林'を建てることができるように。 しかしながら、これはいつもそうであるというわけではありません。 すべての領域には、市外局番があるというわけではありません。 いくつかの領域には、人がどう呼び出しを発送したがっているかによる異なった市外局番があるかもしれません。 領域か国名略号(著しく緊急電話番号)をprependingしないで、いつも「そのままで」いくつかの番号にダイヤルしなければなりません。 そして、市外局番は、変化して、変化できます。
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が使用されるだろう、(a」/、」、電話番号の部分を切り離しているキャラクタ)、URLの作家が、部品がどれであるかを知らなければならないだろう、どれですか?
Vaha-Sipila Standards Track [Page 16] RFC 2806 URLs for Telephone Calls April 2000
Vaha-Sipila規格は2000年4月に通話のためにRFC2806URLを追跡します[16ページ]。
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.
最終的に、電話番号がここで指定されるとして国際的なフォームに書かれると、それらは、明白であり、いつも地方のダイヤルするコンベンションに変えることができます、ユーザエージェントに地方の国と市外局番に関する知識があるなら。
2.7.4 Not everyone has the same equipment as you
2.7.4 皆には、あなたと同じ設備があるというわけではありません。
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コードを使用させます。
2.7.5 Do not confuse numbers with how they are dialled
2.7.5 それらがどうダイヤルされるかに数を間違えないでください。
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として多くの国でダイヤルされるでしょう、どこ。主な「0インチは国際電話のためのa接頭語です」。 しかしながら、URLがローカルの電話番号00123456789を含んでいるなら、ユーザエージェントは、この数がグローバルな電話番号+123456789と等しいと仮定してはいけません。 市内番号がそれにある状態でユーザエージェントが電話URLを受けたなら、処理されるローカルの電話番号がことである文脈を知っているのを確実にしなければなりませんか、または数を使用してはいけません。 等しく、電話URLを送るだれでも、受取人には電話番号の文脈に関する不十分な情報があるかもしれないのを考慮に入れなければなりません。
3. Comments on usage
3. 用法のコメント
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.
SHOULDに付番してください。まず、エンドユーザにとって目に見えてください、ユーザにはこれらのURLを使用できるローカル要素がないのが想像できるなら。
Telephone: <a href="tel:+3585551234567">+358-555-1234567</a>
電話: <a hrefが等しい、「tel: +3585551234567 「>+358-555-1234567</a>」
Vaha-Sipila Standards Track [Page 17] RFC 2806 URLs for Telephone Calls April 2000
Vaha-Sipila規格は2000年4月に通話のためにRFC2806URLを追跡します[17ページ]。
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.
2番目に、国際的なフォームで公共のHTML形式のページでは、いつもURL SHOULDの電話番号はそうです、リンクのテキストが何らかの地方の形式を使用しても。
Telephone: <a href="tel:+3585551234567">(0555) 1234567</a>
電話: <a hrefが等しい、「tel: +3585551234567 「>(0555)1234567</a>」
or even
または、同等
For more info, call <a href="tel:+15554383785965">1-555-IETF-RULZ-
OK</a>.
詳しい情報に関して、<をhref=と呼んでください、「tel: +15554383785965 「>1-555IETF-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が表示される文脈から明確でなく、人間読み込み可能な説明はSHOULDです。含まれています。
For customer service, dial <a href="tel:1234;phone-
context=+358555">1234</a> (only from Terrific Telecom mobile
phones).
顧客サービスのために、<a href=にダイヤルしてください、「tel:1234; +358555 「>1234</a>(単にTerrificテレコム携帯電話からの)」という文脈=に電話をしてください。
4. References
4. 参照
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris、P.、「ドメイン名--、実現と仕様、」、STD13、RFC1035、11月1987日
[RFC1738] Berners-Lee, T., et al., "Uniform Resource Locators (URL)",
RFC 1738, December 1994.
[RFC1738] バーナーズ・リー、T.、他、「Uniform Resource Locator(URL)」、RFC1738、1994年12月。
[RFC1866] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language
- 2.0", RFC 1866, November 1995.
そして、[RFC1866]バーナーズ・リー、T.、D.コノリー、「2インチ、RFC1866、1995年ハイパーテキストマークアップランゲージ--11月。」
[RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose
Internet Mail Extensions (MIME) Part Four: Registration
Procedures", RFC 2048, November 1996.
解放された[RFC2048]、N.、Klensin、J.、およびJ.ポステル、「マルチパーパスインターネットメールエクステンション(MIME)は4を分けます」。 「登録手順」、RFC2048、1996年11月。
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2234] Crocker, D. and P. Overall, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
全体的に見て[RFC2234]クロッカー、D.、およびP.、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[RFC2303] Allocchio, C., "Minimal PSTN Address Format in Internet
Mail", RFC 2303, March 1998.
[RFC2303] Allocchio、C.、「インターネットメールにおける最小量のPSTNアドレス形式」、RFC2303、1998年3月。
[RFC2304] Allocchio, C., "Minimal FAX Address Format in Internet
Mail", RFC 2304, March 1998.
[RFC2304] Allocchio、C.、「インターネットメールにおける最小量のファックスアドレス形式」、RFC2304、1998年3月。
Vaha-Sipila Standards Track [Page 18] RFC 2806 URLs for Telephone Calls April 2000
Vaha-Sipila規格は2000年4月に通話のためにRFC2806URLを追跡します[18ページ]。
[RFC2396] Berners-Lee, T., R. Fielding and L. Manister, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[RFC2396]バーナーズ・リー、T.、R.フィールディングとL.Manister、「Uniform Resource Identifier(URI):」 「一般的な構文」、RFC2396、1998年8月。
[RFC2543] Handley, M., Schulzrinne, H., Schooler, E. and J.
Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
March 1999.
[RFC2543] ハンドレー、M.、Schulzrinne、H.、学生、E.、およびJ.ローゼンバーグは「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC2543、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: Subaddressを利用するルート設定を電送してください。 1996.
5. Security Considerations
5. セキュリティ問題
It should be noted that the local entity SHOULD NOT call out without the knowledge of the user because of associated risks, which include
ローカル要素SHOULD NOTが関連リスク、どのインクルードでユーザに関する知識なしで大声で叫ぶかに注意されるべきです。
- 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
- メールを通して、恐らく直接顧客に配布される広告でウェブページで悪意あるユーザーによって挿入されるか、または送られた間違った数
- 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.
ローカル要素を設計するとき、これらのリスクのすべてを考慮に入れなければなりません。
Vaha-Sipila Standards Track [Page 19] RFC 2806 URLs for Telephone Calls April 2000
Vaha-Sipila規格は2000年4月に通話のためにRFC2806URLを追跡します[19ページ]。
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.
ローカル要素SHOULDには、ユーザが求められていない数を無視するのに使用できる何らかのメカニズムがあります。 (シグナリング)ネットワークの混雑を避けるのが忙しいなら、ローカル要素SHOULD NOTは数について急速な再ダイヤルすることを使用します。 また、ローカル要素SHOULDはダイヤルするストリングが完全に処理される(例えば、呼び出しはユーザ入力を待つ間、終えられます)前に数が入手できないかどうか、または呼び出しが終えられるかどうか検出して、再び電話をしようとしません、ユーザによって命令されない場合。
6. Acknowledgements
6. 承認
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メーリングリストからの多数の人々を入れます、よくワールドワイドウェブコンソーシアム、いくつかの会社、および何人かの個人のように。 批評、修正、およびフィードバックを提供したすべての人々をありがとうございます。
All phone numbers and company names used in the examples of this specification are fictional. Any similarities to real entities are coincidental.
この仕様に関する例で使用されるすべての電話番号と会社名は作り事です。 本当の実体へのどんな類似性も暗合的です。
7. Author's Address
7. 作者のアドレス
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、(4)E E: Antti V=4h=4-Sipil=Eの引用されて印刷可能なノキア携帯電話私書箱68フィン-33721タンペレフィンランド
EMail: avs@iki.fi
antti.vaha-sipila@nokia.com
メール: avs@iki.fi antti.vaha-sipila@nokia.com
Vaha-Sipila Standards Track [Page 20] RFC 2806 URLs for Telephone Calls April 2000
Vaha-Sipila規格は2000年4月に通話のためにRFC2806URLを追跡します[20ページ]。
8. Full Copyright Statement
8. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Vaha-Sipila Standards Track [Page 21]
Vaha-Sipila標準化過程[21ページ]
一覧
スポンサーリンク
