Network Working Group A. Vaha-Sipila
Request for Comments: 2806 Nokia
Category: Standards Track April 2000
URLs for Telephone Calls
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.
著作権（C）インターネット協会（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」、「ファックス」と「モデム」を指定し、そのエンティティへの接続に使用できる接続タイプ（動作モード） 。この仕様は、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
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」、「ファックス」と「モデム」：この仕様は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].
「ファックス」のスキームは、テレファックス（ファクシミリ）を扱うことができ、端末への接続について説明します。 [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.
「モデム」のスキームは、着信データコールを処理できる端末への接続について説明します。用語「モデム」は、デジタル - アナログ行い、アナログ - デジタル変換装置を指します。これらに加えて、「モデム」のスキームは、完全にデジタル接続を記述することができます。
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]のに対し、URLを指定しているという事実に少し異なっています。 「;」、例えば、「/」は、（階層的なURL [RFC2396]に部品を分離するためのURLで使用される）により置換されています。また、この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（拡張バッカス正規形）表記[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.
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」は（US-ASCIIで、スペース文字）、「20」の16進数値を有する単一のオクテットを意味します。これは、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は大文字と小文字を区別しない（その場合は感度のアプリケーション固有の<将来拡張>パラメータを除く）です。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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の一つ以上を解析し、おそらくリモートエンティティに電話をかける、あるいは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スキームは、電話網を使って電話をかけるために、ローカルエンティティを指示するために使用されている、または方法として転送したり、電話番号に加えて、他の関連データを格納します。問題のネットワークは、固定電話や携帯電話網、またはこれらの組み合わせであってもよいです。電話ネットワークは、（例えば）を区別し、音声とデータの呼び出し、またはローカルエンティティがその処分で、いくつかの異なった通信機器を持っている場合、要求されたコールのどの種類（音声/ FAX /データ）を指定することが可能です。接続が正常に確立できるように、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の文字はエスケープする必要があります。
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-サブアドレス] [ポストダイヤル] *（領域指定子/サービスプロバイダ/将来の拡張）ベースの電話番号= 1 * phonedigitローカル電話番号= 1 *（phonedigit / DTMF桁/一時停止文字）[ISDN-サブアドレス] [ポストダイヤル]領域指定子*（領域指定子/サービスプロバイダ/将来の拡張）ISDN-サブアドレス= "; Isubは=" 1 * phonedigit後ダイヤル= "; postd =" 1 *（phonedigit / DTMF桁/一時停止文字）領域指定子= ";"電話・コンテキスト・タグ=「電話コンテキスト」電話文脈のident =ネットワークプレフィックス/プライベート・プレフィックスのネットワークプレフィックス=グローバル・ネットワーク・プレフィックス/ローカル・ネットワーク「=」電話文脈のident電話コンテキストタグ-prefixグローバル・ネットワーク・プレフィックス= "+" 1 * phonedigitローカルネットワークプレフィックス= 1 *（phonedigit / DTMF桁/一時停止文字）プライベート・プレフィックス=（％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]で説明したように
; 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サービスプロバイダー=「;」プロバイダータグ「=」プロバイダーホスト名プロバイダータグ=「TSP」プロバイダーホスト名=ドメイン; <ドメイン>は、[RFC1035]で定義されています。 =セクション2.5.10将来の拡張を参照してください「;」を1 *（トークンチャー） "="（（1 *（トークンCHAR）1 *（トークンCHAR）]）/引用符で囲まれた文字列 "？"）]。セクション2.5.11と[RFC2543]を参照トークンチャー=（％X21 /％x23-27 /％X2A-2B /％x2D-2E /％x30-39 /％x41-5A /％x5E-7A /％のx7C / ％のx7E）。 URL内の文字はエスケープ規則に従う必要があります。 [RFC2396]で説明したように。参照セクション1.2および2.5.11引用符で囲んだ文字列=％X22 *（ "\" CHAR /（％x20-21 /％x23-7E /％X80-FF））％のX22; URL内の文字はエスケープ規則に従う必要があります。 [RFC2396]で説明したように。参照セクション1.2および2.5.11 phonedigit = DIGIT /ビジュアルセパレータビジュアル・セパレータ= " - " "" / /「（」/「）、」一時停止文字= 1秒休止/待ちダイヤルトーンを1秒休止=「P」待ちトーンダイヤル=「W」DTMF桁を= " *" / "＃" / "あいうえお"
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 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つの異なるプレフィックスで示すことができます。 <グローバル・ネットワーク・プレフィックス>は、数はそのグローバルな数字<グローバル・ネットワーク・プレフィックス>で始まる番号のエリア内で有効であることを示しています。同様に、<ローカルネットワークプレフィックス>は、番号がその番号（またはダイヤル文字列）それで始まる番号のエリア内で有効であることを意味します。 <プライベート・プレフィックス>は、コンテキストの名前です。地元企業は、セクション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]を参照してください、エスケープする必要があります。
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 =ファックス・スキーム "：" ファックス加入者のFAX-スキーム= "FAX" のFAX-加入者=ファックス・グローバル・電話/ファックス-ローカル電話ファックス・グローバル・フォン= "+" ベース・電話番号[ ISDNサブアドレス] [T33-サブアドレス] [ポスト・ダイアル] *（エリア指定子/サービスプロバイダ/将来の拡張）、ファックス、ローカル電話= 1 *（phonedigit / DTMF桁/一時停止文字）[isdn-サブアドレス] [T33-サブアドレス] [ポストダイヤル]領域指定子*（領域指定子/サービスプロバイダ/将来の拡張）T33-サブアドレス= "; 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：URLはTELと非常によく似ています。主な違いは、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 / "-" / "+")
モデムのurl =モデムスキーム "：" リモートホストモデムスキーム= "モデム" リモートホスト=電話加入者*（モデムのparams /推奨-のparams）モデムのparams = ";タイプ=" データ機能を推奨-params =「; REC =」「？」データ能力データ機能=受け付けモデム[データビットパリティストップビット]受け付けモデム= "V21" / "V22" / "V22B" / "V23" / "V26t" / "V32" / "V32b" / "V34" / "V90" /「V110 "/ "V120"/ "B103"/ "B212"/ "X75"/ "VND。"業者名 "。"モデムタイプのデータビット= "7" / "8" パリティ= "N" / "E" / "O" / "M" / "S" ストップビット= "1" / "2" ベンダ名= 1 *（ALPHA / DIGIT / " - " / "+"）モデムタイプ= 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の両方に非常に似てスキームが、それは、リモートエンティティの機能の説明を追加します。最低必要なコンプライアンスは<モデムのparams>にリストされ、推奨されるコンプライアンスは、<推奨の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.
コールのタイプは、スキーム指定子で指定されています。 「電話番号は、」音声通話が開かれることを意味します。 「ファックス」コールがファクシミリ（ファックス）の呼び出しでなければならないことを示しています。 「モデム」とは、データの呼び出しでなければならないことを意味します。すべてのネットワークは、コールの種類を区別わけではありません。この場合には、スキーム指定子は、使用する通信機器の種類を示します。
<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.
<電話加入者>と<ファックス加入者>ダイヤルする電話番号を示しています。電話番号は、国際またはローカル表記で書くことができます。地元のフォームを使用する正当な理由がない場合はすべての電話番号は、常に国際的な形式で記述する必要があります。
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.
<グローバル・ネットワーク・プレフィックス>、<ローカル・ネットワーク・プレフィックス>または<プライベート・プレフィックス>：<エリア指定子は> 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.
ローカルプレフィックスフォームは電話番号の最も外側のコンテキストが別の手段によって与えられるような状況において、中間コンテキストとして作用することが意図されています。ローカルエンティティが唯一の北米番号計画エリア内で通話を発信することが知られているので、「最も外側の」電話のコンテキストを想定することができる場所を使用の一例です。ローカルコンテキストは、例えば、関連する電話番号が位置する内のエリアコードを示すために使用することができます。したがって、「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-COMPANY-NET」で示すことができるが、テレフォニーURLとローカルエンティティの送信者のロケールからプライベートダイヤルプラン異なります。これらのトークンの構文は将来の仕様のために残されます。 ABNFは、上記<プライベート・プレフィックス>の一部にすることができ受け入れの文字を指定します。
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.
送信者は、彼らは地元のエンティティと同じプライベートネットワークアクセス数字列を共有することが確実でない限り、結果によっては、それらは、ダイヤルプラン番号（ローカル電話番号、またはローカルコンテキストによって修飾1）を使用してはなりません正しくありません。代わりに、彼らはグローバル番号を使用するか、または必要があることが不可能な場合は、最後の手段として民間の文脈。ローカルエンティティがそのコンテキストで示さプライベートネットワークにダイヤルサポートしていない場合、その要求を拒絶しなければなりません。それがない場合、それはそのロケールの適切なアクセス数字列を使用します。
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.
例えば、大企業は、そのサイト間のプライベートネットワークの相互接続を有することができるだけでなく、グローバルへの接続は、交換電話網。電話番号は、コールが企業ネットワークを介して実施されるべきであることを示すが、<サービスプロバイダー>と、「公衆網」の形で与えられてもよいです。
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.
任意の電話番号は、少なくとも一つの<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）および[E.164] [E.123]で指定されたとして、国家（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.
番号のみ、特定の地域やネットワーク内部から動作するかどうかローカル番号が使用されるかもしれません。いくつかの数字は、いくつかのネットワークから動作する可能性がありますが、全世界からではない - これらは、<エリア指定子>タグとオプションの<サービスプロバイダー>パラメータのセットで、国際的な形式で記述する必要があります。ローカルの電話番号を含む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桁>の文字は文字がこれを行うには何も持って、またこれらの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.
電話番号が抽出された後、それは地元のダイヤル規則に変換することができます。 （例えば、「+」の文字は、国際電話のプレフィックスに置き換えられるかもしれない、あるいは国際的なトランクプレフィックスはローカル電話をかけるために削除される可能性があります。）<ローカル電話>または<ファックス-ローカルを使用して指定されている数字を-Phone>ローカルエンティティは、オプションの<サービスプロバイダー>パラメータの情報を利用することを決定しない限り、任意の変換なしに、「そのまま」ローカルエンティティによって使用されなければなりません。
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」）ダイヤルトーン待ちが含まれていてもよいです。
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.
それがサポートされていない場合は、ローカルエンティティは、最初の<ポーズ文字>の後にダイヤル文字列のすべてを無視しなければなりませんし、ユーザーが通知する必要があります。ユーザーまたはローカルエンティティは、この機能がサポートされており、これらの文字が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桁を>ダイヤルを直接使用して行われても、DTMF（デュアルトーン多重周波数）帯域内シグナリングを使用して回線に送信されてくださいネットワークシグナリング（デジタル加入者ループまたは携帯電話）。地域のインフラはDTMFコードをサポートしていない場合は、ローカルエンティティは、パルスダイヤルを使用することを選ぶことができます。しかし、DTMFトーンを使用して制御されている特定のサービスは、パルスダイヤルで制御することができないことに留意すべきです。パルスダイヤルを使用する場合、ユーザーは通知する必要があります。
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-サブアドレス>を含むかもしれません。ローカルエンティティは、ISDNのサブアドレスをサポートする必要があります。これらのアドレスは、ローカルエンティティ（通常は、ISDNの加入者が呼設定シグナリングにアドレスを送信）で利用可能なメソッドを使用してネットワークに送信されます。 ISDNのサブアドレスが呼び出し元でサポートされていない場合は、<ISDNサブアドレス>無視されなければならないとユーザーが通知する必要があります。ユーザーまたはローカルエンティティは、この機能がサポートされていない場合、コールを配置しないように選ぶことができます。
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.
ファックス番号もT.33サブアドレス[T.33]の開始を示す<T33-サブアドレス>を含んでいてもよいです。ローカルエンティティはこれをサポートすべきです。それ以外の場合は<T33-サブアドレス>は無視しなければなりませんし、ユーザーが通知する必要があります。ユーザーまたはローカルエンティティは、この機能がサポートされていない場合、コールを配置しないように選ぶことができます。
<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>と競合しないかもしれません。彼らが行う場合は、ローカルエンティティは、<推奨の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]に接続型指定子（タイプコード）に幾分類似している：それはスキーム指定子から推定することができない情報をローカルエンティティを提供するが、正常な動作のために有用です。
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）の数とポストフィックスの最初の文字（例えば、「ビス」は、「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.
独自のモデムタイプは、「x」はモデムタイプの仕様を取得し、「Y」することが可能なエンティティの名前である形態「vnd.xy」をとる「ベンダー命名ツリー」を、使用して指定する必要がありモデムのタイプやモデルがあります。ベンダー名は、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".
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ベル103 B212ベル212データビット： "8" や "7"データビットの数。指定されていない場合は、「8」にデフォルト設定されています。パリティ： "n" は、 "E"、 "o" は、パリティ。それぞれなし、偶数、奇数、マークまたは「M」、「s」はスペースパリティ、。 「N」に、デフォルト値を指定しない場合。ストップビット：「1」又は「2」のストップビットの数。指定しない場合、「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].
与えられた電話番号のテレフォニーサービスプロバイダーのアイデンティティを示すことが可能です。 <サービスプロバイダー>は、課金の見積もりのために、ユーザーインターフェイスを強化するために、このネットワークを使用して電話をかけるか、そうでなければ、その機能を最適化するために、ユーザーエージェントによって使用されるかもしれません。また、ユーザーエージェントによって無視されるかもしれません。 <サービスプロバイダー>は、たとえば、テレフォニーサービスプロバイダーの完全修飾インターネットドメイン名で構成されて「; 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へ（BNFで<将来の拡張>）を追加することができます。これらのパラメータは、セミコロンの後に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.
例えば、<将来の拡張は、>電話番号、その使用目的、または番号に適用されている任意の変換に関するアプリケーション固有の追加データを格納するために使用することができます。 <将来の拡張>がオープンな環境で使用されるたびに、その構文と使用方法が正しく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).
<将来の拡張>非終端記号言い換えるのバージョン、および（実際に、本明細書の以前のバージョンからBNFを借り）[RFC2543]で定義されるように、<他の-PARAM>と互換。
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は、ファックス通話を受信できる電話番号を記述する。これは、セパレータとしてドットの代わりにハイフンを使用していますが、彼らは機能には影響しません。
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.
この電話番号は、データコールを受信することが可能であるエンティティに属しています。ローカルエンティティは、7データビット、偶数パリティ、1ストップビット、または使用してISDN接続の設定を使用して、ITU-T V.32bisモデム（またはV.32bisと互換性のある高速一つ）のいずれかを使用することを選ぶことができますITU-T V.110プロトコル。
tel:+358-555-1234567;postd=pp22
TEL：+ 358-555-1234567; 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は、次に、（例えば、2秒）実装依存の時間待つ二DTMFダイヤルトーンを発する、+ 358-555-1234567に音声通話を置くためにローカルエンティティに指示する「2」の行に（例えば）特定の内線番号を選択する、または特定のサービスを呼び出します。
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」の文字が第二ダイヤルトーンを待ち、その数は既にそれに追加国際アクセスコード（「00」）を有します。電話番号のこの種のは、この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で始まる番号のエリア内でのみ使用可能である電話番号を記述する。値「foo」を持っている独自の拡張子「vnd.company.option」もあります。この拡張の意味は、アプリケーション固有です。これらのパラメータ（電話コンテキストと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は、この場合には、いくつかの通信機器は、与えられた電話番号である、リソースを検索します。しかし、必ずしも成功している機器と通信するために、加入者番号を知るには十分ではありません。デジタル電話ネットワークは、音声、ファックス、データコール（および通話のおそらく他の種類の、本明細書では説明しません）を区別します。成功したファックス機、たとえば、に接続できるようにするには、呼び出し側は、ファックスコールが行われていることを指定する必要があります。そうしないと、コールは、加入者のボイス番号にルーティングされる可能性があります。この意味で、コールタイプは、ターゲット・リソースの「位置」の不可欠な部分です。
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」。電話は「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.
1つの葉のように枝や加入者番号などの根、市外局番などの国コードと電話番号の「森」を構築することができるように、電話番号は、「階層」特性を有していてもよいことに留意すべきです。しかし、これは必ずしもそうではありません。いないすべての領域は、エリアコードを持っています。一部の地域は、1つのコールをルーティングしたいかに応じて、異なるエリアコードを有していてもよいです。 「そのまま」いくつかの数字は、常に地域や国コード（特に緊急番号）を先頭に追加せずに、ダイヤルする必要があります。そして、エリアコードは、変更を行うことができます。
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を受け取った場合、それはローカルの電話番号を処理する、または他の数は使用してはいけませんされている文脈を知っていることを確認する必要があります。同様に、テレフォニー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>
電話：<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>
電話：<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]バーナーズ=リー、T.、ら、 "ユニフォームリソースロケータ（URL）"、RFC 1738、1994年12月。
[RFC1866] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language - 2.0", RFC 1866, November 1995.
[RFC1866]バーナーズ=リー、T.、およびD.コノリー、 "ハイパーテキストマークアップ言語 - 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]解放され、N.、Klensin、J.とJ.ポステル、 "多目的インターネットメール拡張（MIME）第四部：登録手順"、RFC 2048、1996年11月。
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2234] Crocker, D. and P. Overall, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC2234]クロッカー、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.、 "インターネットメールにおける最小のFAXアドレス形式"、RFC 2304、1998年3月。
[RFC2396] Berners-Lee, T., R. Fielding and L. Manister, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC2396]バーナーズ=リー、T.、フィールディングR.とL. Manister、 "統一資源識別子（URI）：一般的な構文"、RFC 2396、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.ローゼンバーグ、 "SIP：セッション開始プロトコル"、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メーリングリストから、だけでなく、ワールドワイドウェブコンソーシアムといくつかの企業から多数の人々に加え、いくつかの個人が含まれます。批判、修正やフィードバックを提供し、すべての人々に感謝します。
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
アンティワックスSIPILÄ（引用符で囲まれた印刷可能なアンティ= V = E 4H Sipil = E4-E4）、ノキア携帯電話、P. O.ボックス68 FIN-33721、タンペレ、フィンランド
EMail: avs@iki.fi antti.vaha-sipila@nokia.com
メールアドレス：avs@iki.fi antti.vaha-sipila@nokia.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。