Network Working Group C. Jennings
Request for Comments: 5341 Cisco Systems
Updates: 3966 V. Gurbani
Category: Standards Track Bell Laboratories, Alcatel-Lucent
September 2008
The Internet Assigned Number Authority (IANA)
tel Uniform Resource Identifier (URI) Parameter Registry
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）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
This document creates an Internet Assigned Number Authority (IANA) registry for tel Uniform Resource Identifier (URI) parameters and their values. It populates the registry with the parameters defined in the tel URI specification, along with the parameters in tel URI extensions defined for number portability and trunk groups.
この文書では、TEL用のURI（Uniform Resource Identifier）パラメータとその値のための番号機関（IANA）レジストリを割り当て、インターネットを作成します。これは、番号ポータビリティおよびトランクグループのために定義されたTEL URIの拡張子のパラメータとともに、TEL URIの仕様で定義されたパラメータを使用してレジストリを移入します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Use of the Registry . . . . . . . . . . . . . . . . . . . . . . 2
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3
4.1. tel URI Parameters Registry . . . . . . . . . . . . . . . . 3
4.2. Registration Policy for tel URI Parameters . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . . 5
The tel URI (RFC 3966 [1]), defines a URI that can be used to represent resources identified by telephone numbers. The tel URI, like many other URIs, provides extensibility through the definition of new URI parameters and new values for existing parameters. However, RFC 3966 did not specify an IANA registry where such parameters and values can be listed and standardized. This specification creates such a registry.
TEL URI（RFC 3966 [1]）は、電話番号によって識別されるリソースを表すために使用することができるURIを定義します。 TEL URIは、他の多くのURIと同様に、新しいURIパラメータと既存のパラメータの新しい値の定義によって拡張性を提供します。ただし、RFC 3966には、このようなパラメータと値が一覧表示され、標準化することができるIANAレジストリが指定されていませんでした。この仕様は、このようなレジストリを作成します。
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 [2].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[2]で説明されるように解釈されます。
The tel URI parameters and values for these parameters MUST be documented in a RFC or other permanent and readily available public specification in order to be registered by IANA. This documentation MUST fully explain the syntax, intended usage, and semantics of the parameter. The intent of this requirement is to assure interoperability between independent implementations, and to prevent accidental namespace collisions between implementations of dissimilar features.
これらのパラメータのTEL URIパラメータおよび値は、IANAによって登録されるためにRFCまたは他の永久的かつ容易に入手可能な公開された仕様に文書化されなければなりません。このドキュメントは、完全な構文、使用目的、およびパラメータの意味を説明しなければなりません。この要件の目的は、独立した実装間の相互運用性を確保するために、そして、異なる機能の実装間の偶発名前空間の衝突を防ぐためです。
Documents defining tel URI parameters or parameter values MUST register them with IANA, as described in Section 4. The IANA registration policy for such parameters is "Specification Required, Designated Expert," and is further discussed in Section 4.2.
TEL URIパラメータまたはパラメータ値を定義するドキュメントは、セクション4で説明したように、このようなパラメータのIANA登録ポリシー「は、仕様が必要で、指定された専門家」であり、さらに、セクション4.2で説明され、IANAに登録しなければなりません。
Some tel URI parameters only accept a set of predefined parameter values while others can take any value. There are also parameters that do not have any value; they are used as flags.
他の人が任意の値を取ることができながら、いくつかTEL URIパラメータは事前に定義されたパラメータ値のセットを受け入れます。任意の値を持たないパラメータもあります。彼らはフラグとして使用されています。
Those URI parameters that take on predefined values typically take on a large number of values. Registering each of those values, or creating a sub-registry for each such parameter is not appropriate. Instead, we have chosen to register URI parameter values by reference. That is, the entry in the URI parameter registry for a given URI parameter contains references to the RFCs defining new values of that parameter.
事前定義された値をとるものURIパラメータは、典型的には多数の値をとります。これらの値のそれぞれを登録する、またはそのような各パラメータのサブレジストリを作成することは適切ではありません。代わりに、我々は、参照することによってURIパラメータ値を登録することを選択しました。つまり、与えられたURIパラメータのURIパラメータレジストリのエントリは、そのパラメータの新しい値を定義するRFCへの参照が含まれています。
Accordingly, the tel URI parameter registry contains a column that indicates whether or not each parameter accepts a value. The column may contain "No value" or "Constrained". A "Constrained" in the column implies that certain predefined values exist for this parameter and the accompanying RFC or other permanent and readily available public specification should be consulted to find out the accepted set of values. A "No Value" in the column implies that the parameter is used either as a flag, or does not have a set of predefined values. The accompanying RFC or other permanent and readily available public specification should provide more information on the semantics of the parameter.
したがって、TEL URIパラメータレジストリは、各パラメータ値を受け入れるかどうかを示す列を含みます。列には、「値なし」または「制約」を含まなくてもよいです。列に「拘束」は、特定の定義済みの値は、値の許容セットを見つけるために相談されるべきで、このパラメータおよび添付RFCまたは他の永久的かつ容易に入手可能な公開された仕様のために存在することを意味します。カラムにて「No値は」パラメータはいずれかのフラグとして使用されることを意味していない、または事前に定義された値のセットを有していません。添付RFCまたはその他の永久的かつ容易に利用可能な公開された仕様は、パラメータの意味論に関する詳細な情報を提供する必要があります。
The specification creates a new IANA registry named "tel URI Parameters".
仕様は「TEL URIパラメータ」という名前の新しいIANAレジストリを作成します。
New tel URI parameters and new values for existing tel URI parameters MUST be registered with IANA.
既存のTEL URIパラメータのための新しいTEL URIパラメータと新しい値は、IANAに登録しなければなりません。
When registering a new tel URI parameter, the following information MUST be provided:
新しいTEL URIパラメータを登録する場合、以下の情報を提供しなければなりません。
o Name of the parameter.
Oパラメータの名前。
o Whether the parameter only accepts a set of predefined values.
パラメータは事前に定義された値のセットを受け入れるかどうか、O。
o Reference to the RFC or other permanent and readily available public specification defining the parameter and new values.
パラメータ値と新しい値を定義するRFCまたはその他の永久的かつ容易に利用可能な公開された仕様にOリファレンス。
When registering a new value for an existing tel URI parameter, the following information MUST be provided:
既存のTEL URIパラメータの新しい値を登録すると、以下の情報を提供しなければなりません。
o Name of the parameter.
Oパラメータの名前。
o Reference to the RFC or other permanent and readily available public specification providing the new value.
新たな価値を提供するRFCまたはその他の永久的かつ容易に利用可能な公開された仕様にOリファレンス。
Table 1 contains the initial values for this registry.
表1は、このレジストリの初期値が含まれています。
Parameter Name Predefined Values Reference
-------------- ----------------- ---------
isub Constrained [RFC3966]
isub-encoding Constrained [RFC4715]
ext Constrained [RFC3966]
phone-context Constrained [RFC3966]
enumdi No value [RFC4759]
npdi No value [RFC4694]
rn Constrained [RFC4694]
rn-context Constrained [RFC4694]
cic Constrained [RFC4694]
cic-context Constrained [RFC4694]
tgrp Constrained [RFC4904]
trunk-context Constrained [RFC4904]
Table 1: IANA tel URI parameter registry
表1：IANA TEL URIパラメータレジストリ
As per the terminology in [3] and actions accorded to such a role, the registration policy for tel URI parameters shall be "Specification Required, Designated Expert" (the former implicitly implies the latter).
このような役割に従う[3]とアクションで用語ごとに、TEL URIパラメータの登録ポリシーは「仕様が必要で、指定された専門家」（前者は暗黙的に後者を意味する）でなければなりません。
The Designated Expert, when deliberating on whether to include a new parameter in the tel URI registry, may use the criteria provided below to reach a decision (this is not an exhaustive list but representative of the issues to consider when rendering an equitable decision):
指定エキスパート、TEL URIレジストリに新しいパラメータを含めるかどうかについて審議する際、意思決定に到達するために以下に基準を使用することができます（これは公正な判断をレンダリングする際に考慮すべき問題の完全なリストではなく、代表ではありません）：
o If the tel URI -- with the parameter under consideration -- will be converted to a URI used by other signaling protocols such as the Session Initiation Protocol (SIP [5]) or H.323 [7], then the expert must consider whether this parameter merely encapsulates signaling information that is not meaningful to the processing of requests in the domain of the converted URI. For example, certain Integrated Services Digital Network (ISDN) User Part (ISUP, [8]) parameters have no equivalent corollary in SIP; thus, their presence or absence in a SIP URI will not hinder the normal rules for processing that URI. Other parameters may affect the normal processing rules associated with the URI; in such cases, the expert must carefully consider the ramifications, if any, of the presence of such parameters.
O TEL URI場合 - 考慮中のパラメーターとは - [7]、その後、専門家が考慮しなければならないようなセッション開始プロトコル（SIP [5]）またはH.323のような他のシグナリングプロトコルによって使用されるURIに変換されますこのパラメータは、単に変換URIのドメインにおける要求の処理に意味のない情報をシグナリングカプセル化するかどうか。例えば、特定の統合サービスデジタル網（ISDN）ユーザ部（ISUP、[8]）パラメータは、SIPに同等帰結を有していません。従って、SIP URIにおけるそれらの存在または不在は、そのURI処理の通常の規則を妨げないであろう。他のパラメータは、URIに関連付けられた通常の処理ルールに影響を及ぼし得ます。もしあればそのような場合には、専門家は慎重に、このようなパラメータの存在により、影響を考慮しなければなりません。
o Certain parameters of a tel URI can be optional. These parameters act as metadata about the identifier in the tel URI. Optional parameters should provide additional information to a service for which they apply instead of acting as enablers of that service in the first place. The service must continue to be invoked and operate normally even in the absence of these parameters.
O TEL URIの特定のパラメータはオプションであることができます。これらのパラメータは、TEL URI内の識別子に関するメタデータとして機能します。オプションのパラメータは、彼らが最初の場所でそのサービスのイネーブラとして機能するのではなく、適用されるサービスに追加情報を提供する必要があります。サービスが起動され、さらには、これらのパラメータが存在しない状態で正常に動作することを継続しなければなりません。
The registry in this document does not in itself have security considerations. However, as mentioned in [4], an important reason for the IETF to manage the extensions of SIP is to ensure that all extensions and parameters are able to provide secure usage. The supporting RFC publications for parameter registrations described in this specification MUST provide detailed security considerations for them.
この文書に記載されているレジストリは、それ自体ではセキュリティ上の配慮を持っていません。 [4]で述べたようしかし、IETFは、SIPの拡張機能を管理するための重要な理由は、すべての拡張機能およびパラメータが安全な使用を提供することができることを保証することです。本明細書に記載されたパラメータの登録のためのサポートRFCの出版物は、それらの詳細なセキュリティ上の考慮事項を提供しなければなりません。
The structure of this document comes from [6], which is the equivalent work done in the SIP domain to establish a registry. Ted Hardie, Alfred Hoenes, Jon Peterson, and Jonathan Rosenberg provided substantive comments that have improved this document.
このドキュメントの構造は、レジストリを確立するSIPドメインで行わ同等の仕事である、[6]から来ています。テッドハーディー、アルフレッドHoenes、ジョンピーターソン、およびジョナサンローゼンバーグはこの文書を改善している実質的なコメントを提供しました。
Brian Carpenter, Lars Eggert, Pasi Eronen, Chris Newman, and Glen Zorn provided feedback during IESG review and Gen-ART review.
ブライアン・カーペンター、ラースEggertの、パシEronen、クリス・ニューマン、およびグレンツォルンはIESGレビューとのGen-ARTのレビュー中にフィードバックを提供します。
[1] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[1] Schulzrinneと、H.、 "電話番号については、TEL URI"、RFC 3966、2004年12月に。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[3] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[4] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. Rosen, "Change Process for the Session Initiation Protocol (SIP)", BCP 67, RFC 3427, December 2002.
[4]マンキン、A.、ブラドナー、S.、マーイ、R.、ウィリス、D.、オット、J.、およびB.ローゼン、 "セッション開始プロトコル（SIP）のための変更処理"、BCP 67、RFC 3427、2002年12月。
[5] 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.
[5]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[6] Camarillo, G., "The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)", BCP 99, RFC 3969, December 2004.
[6]カマリロ、G.、BCP 99、RFC 3969、2004年12月 "セッション開始プロトコル（SIP）のための番号機関（IANA）のURI（Uniform Resource Identifier）パラメータレジストリの割り当てインターネット"。
[7] ITU-T H.323, "H.323: Packet-based multimedia communications systems", June 2006.
[7] ITU-T H.323、 "H.323：パケットベースのマルチメディア通信システム"、2006年6月。
[8] ITU-T Q.764, "Signaling System No. 7: ISDN User Part Signaling Procedures", December 1999.
[8] ITU-T Q.764、 "信号システム第7号：ISDNユーザパートシグナリング手順"、1999年12月。
Authors' Addresses
著者のアドレス
Cullen Jennings Cisco Systems 170 West Tasman Drive Mailstop SJC-21/2 San Jose, CA 95134 USA
カレンジェニングスシスコシステムズ170西タスマンドライブメールストップSJC-2分の21サンノゼ、CA 95134 USA
Phone: +1 408 902-3341 EMail: fluffy@cisco.com
電話：+1 408 902-3341 Eメール：fluffy@cisco.com
Vijay K. Gurbani Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane Room 9F-546 Lisle, IL 60532 USA
ビジェイK. Gurbaniベル研究所、アルカテル・ルーセント2701ルーセントレーンルーム9F-546ライル、IL 60532 USA
Phone: +1 630 224-0216 EMail: vkg@alcatel-lucent.com
電話：+1 630 224-0216 Eメール：vkg@alcatel-lucent.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。