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