[要約] RFC 5341は、IANAが管理するtel URIパラメータレジストリに関するものであり、その目的は、tel URIスキームのパラメータの一貫性と一意性を確保することです。
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
インターネットが割り当てられた番号機関（IANA）Telユニフォームリソース識別子（URI）パラメーターレジストリ
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）パラメーターとその値のインターネット割り当てされた番号局（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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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に登録する必要があります。このようなパラメーターのIANA登録ポリシーは、「必要な仕様、指定された専門家」であり、セクション4.2でさらに説明します。
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.
一部のTELURIパラメーターは、事前定義されたパラメーター値のセットのみを受け入れますが、他のパラメーターはあらゆる値を取ることができます。価値がないパラメーターもあります。それらはフラグとして使用されます。
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またはその他の永続的で容易に利用可能なパブリック仕様を参照して、受け入れられた値のセットを見つける必要があります。列の「値なし」は、パラメーターがフラグとして使用されるか、事前定義された値のセットがないことを意味します。付随する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.
o パラメーターと新しい値を定義するRFCまたはその他の永続的で容易に利用可能なパブリック仕様への参照。
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.
o RFCまたはその他の永続的で容易に利用可能なパブリック仕様を参照して、新しい価値を提供します。
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は、検討中のパラメーターを使用して、セッション開始プロトコル（SIP [5]）やH.323 [7]などの他のシグナル伝達プロトコルが使用する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.
このドキュメントの構造は[6]に由来します。これは、レジストリを確立するためにSIPドメインで行われた同等の作業です。Ted Hardie、Alfred Hoenes、Jon Peterson、およびJonathan Rosenbergは、この文書を改善した実質的なコメントを提供しました。
Brian Carpenter, Lars Eggert, Pasi Eronen, Chris Newman, and Glen Zorn provided feedback during IESG review and Gen-ART review.
ブライアン・カーペンター、ラース・エガート、パシ・エロネン、クリス・ニューマン、グレン・ゾーンは、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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] Mankin、A.、Bradner、S.、Mahy、R.、Willis、D.、Ott、J。、およびB. Rosen、「セッション開始プロトコルの変更プロセス（SIP）」、BCP 67、RFC 3427、12月2002年。
[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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INTIATION Protocol"、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] Camarillo、G。、「インターネットは、セッション開始プロトコル（SIP）のための数字権権（IANA）のユニフォームリソース識別子（URI）パラメーターレジストリを割り当てました」、BCP 99、RFC 3969、2004年12月。
[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、「シグナリングシステムNo. 7：ISDNユーザーパーツシグナリング手順」、1999年12月。
Authors' Addresses
著者のアドレス
Cullen Jennings Cisco Systems 170 West Tasman Drive Mailstop SJC-21/2 San Jose, CA 95134 USA
Cullen Jennings Cisco Systems 170 West Tasman Drive Mailstop SJC-21/2 San Jose、CA 95134 USA
Phone: +1 408 902-3341
EMail: fluffy@cisco.com
Vijay K. Gurbani Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane Room 9F-546 Lisle, IL 60532 USA
Vijay K. Gurbani Bell Laboratories、Alcatel-Lucent 2701 Lucent Lane Room 9F-546 Lirle、IL 60532 USA
Phone: +1 630 224-0216
EMail: vkg@alcatel-lucent.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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への情報をお問い合わせください。