RFC5341 日本語訳
5341 The Internet Assigned Number Authority (IANA) tel UniformResource Identifier (URI) Parameter Registry. C. Jennings, V.Gurbani. September 2008. (Format: TXT=13944 bytes) (Updates RFC3966) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group C. Jennings
Request for Comments: 5341 Cisco Systems
Updates: 3966 V. Gurbani
Category: Standards Track Bell Laboratories, Alcatel-Lucent
September 2008
コメントを求めるワーキンググループC.ジョニングス要求をネットワークでつないでください: 5341のシスコシステムズアップデート: 3966年のV.Gurbaniカテゴリ: 標準化過程ベル研究所、アルカテル透明な2008年9月
The Internet Assigned Number Authority (IANA)
tel Uniform Resource Identifier (URI) Parameter Registry
ISOCの機関の一つで(IANA)tel Uniform Resource Identifier(URI)パラメタ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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
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 Uniform Resource Identifier(URI)パラメタとそれらの値のためにISOCの機関の一つで(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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . . 2 3。 登録. . . . . . . . . . . . . . . . . . . . . . 2 4の使用。 IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 3 4.1tel URI Parameters Registry. . . . . . . . . . . . . . . . 3 4.2。 tel URI Parameters. . . . . . . . 4 5のための登録Policy。 セキュリティ問題. . . . . . . . . . . . . . . . . . . . 5 6。 承認. . . . . . . . . . . . . . . . . . . . . . . . 5 7。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1。 引用規格. . . . . . . . . . . . . . . . . . . 5 7.2。 有益な参照. . . . . . . . . . . . . . . . . . 5
Jennings & Gurbani Standards Track [Page 1] RFC 5341 IANA Registry for TEL URI Parameters September 2008
ジョニングスとGurbani規格は2008年9月にTEL URIパラメタのためにRFC5341IANA登録を追跡します[1ページ]。
1. Introduction
1. 序論
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、(RFC3966[1])、電話番号によって特定されたリソースを表すのに使用できるURIを定義します。 他の多くのURIのように、tel URIは新しいURIパラメタと新しい値の定義で既存のパラメタに伸展性を提供します。 しかしながら、RFC3966はそのようなパラメタと値をリストアップして、標準化できるIANA登録を指定しませんでした。 この仕様はそのような登録を作成します。
2. Terminology
2. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[2]で説明されるように本書では解釈されることであるべきですか?
3. Use of the Registry
3. 登録の使用
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.
IANAによって登録されるように、RFCか他の永久的で容易に利用可能な公共の仕様にこれらのパラメタのためのtel URIパラメタと値を記録しなければなりません。 このドキュメンテーションで、構文、意図している用法、およびパラメタの意味論が完全にわからなければなりません。 この要件の意図は、独立している実現の間の相互運用性を保証して、異なった特徴の実現の間の偶然の名前空間衝突を防ぐことです。
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.
他のものがどんな値も取ることができる間、いくつかのtel URIパラメタが1セットの事前に定義されたパラメタ値を受け入れるだけです。 少しの値も持っていないパラメタもあります。 それらは旗として使用されます。
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パラメタ登録のエントリーはそのパラメタの新しい値を定義するRFCsの参照を含んでいます。
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
それに従って、tel URIパラメタ登録は各パラメタが値を受け入れるかどうかを示すコラムを含んでいます。 コラムが「値がありません」を含むかもしれませんか、または「抑制されました」。 コラムで「抑制されたこと」は、ある事前に定義された値がこれのために存在するのを含意します。
Jennings & Gurbani Standards Track [Page 2] RFC 5341 IANA Registry for TEL URI Parameters September 2008
ジョニングスとGurbani規格は2008年9月にTEL URIパラメタのためにRFC5341IANA登録を追跡します[2ページ]。
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.
パラメタと付随のRFCか他の永久的で容易に利用可能な公共の仕様が、受け入れられたセットの値を見つけるために相談されるべきです。 コラムの「いいえ値」は、パラメタには、旗として使用されるか、または1セットの事前に定義された値がないのを含意します。 付随のRFCか他の永久的で容易に利用可能な公共の仕様がパラメタの意味論に関する詳しい情報を提供するべきです。
4. IANA Considerations
4. IANA問題
The specification creates a new IANA registry named "tel URI Parameters".
仕様は「tel URI Parameters」という新しいIANA登録を作成します。
4.1. tel URI Parameters Registry
4.1. tel URI Parameters Registry
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 パラメタは1セットの事前に定義された値を受け入れるのであるだけであるかどうか
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はこの登録への初期の値を含んでいます。
Jennings & Gurbani Standards Track [Page 3] RFC 5341 IANA Registry for TEL URI Parameters September 2008
ジョニングスとGurbani規格は2008年9月にTEL URIパラメタのためにRFC5341IANA登録を追跡します[3ページ]。
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]
事前に定義されたパラメタ名は参照を評価します。-------------- ----------------- --------- isubをコード化しているisub Constrained[RFC3966]Constrained[RFC4715]ext Constrained[RFC3966]電話文脈Constrained[RFC3966]enumdiいいえ価値[RFC4759]のnpdiいいえ価値[RFC4694]のRn Constrained[RFC4694]Rn文脈Constrained[RFC4694]cic Constrained[RFC4694]cic-文脈Constrained[RFC4694]tgrp Constrained[RFC4904]トランク文脈Constrained[RFC4904]
Table 1: IANA tel URI parameter registry
テーブル1: IANA tel URIパラメタ登録
4.2. Registration Policy for tel URI Parameters
4.2. tel URI Parametersのための登録Policy
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登録に新しいパラメタを含むかどうかに関して検討するとき、Designated Expertは決断を下すために以下に提供された評価基準を使用するかもしれません(公正な決定を表すとき、これは完全なりストではなく、考える問題の代表です):
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がそうするなら、Session Initiationプロトコルなどの他のシグナリングプロトコルによって使用されるURIに変換されてください。(SIP[5])かH.323[7]、当時の専門家が、変換されたURIのドメインでの要求の処理に重要でない情報に合図しながら、このパラメタが単に要約されるかどうか考えなければなりません。 例えば、あるIntegrated Services Digital Network(ISDN)ユーザPart、([8]) ISUP、パラメタは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
o tel URIのあるパラメタは任意である場合があります。 これらのパラメタはtel URIにおける識別子に関するメタデータとして機能します。 そのサービスのイネーブラとして機能することの代わりにそれらがどれで適用するように、任意のパラメタは追加情報をサービスに提供するべきであるか。
Jennings & Gurbani Standards Track [Page 4] RFC 5341 IANA Registry for TEL URI Parameters September 2008
ジョニングスとGurbani規格は2008年9月にTEL URIパラメタのためにRFC5341IANA登録を追跡します[4ページ]。
the first place. The service must continue to be invoked and
operate normally even in the absence of these parameters.
1位。 サービスは、通常、これらのパラメタがないときでさえ呼び出されて、作動し続けなければなりません。
5. Security Considerations
5. セキュリティ問題
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.
登録には、本来、セキュリティ問題が本書ではありません。 しかしながら、IETFがSIPの拡大を管理する重要な理由は[4]で言及されるようにすべての拡大とパラメタが安全な用法を提供できるのを保証することです。 パラメタ登録証明書のためのRFC刊行物がこの仕様で説明した支持は詳細なセキュリティ問題をそれらに提供しなければなりません。
6. Acknowledgments
6. 承認
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]から来ます。([6]は登録を証明するためにSIPドメインで行われた同等な仕事です)。 テッド・ハーディー、アルフレッドHoenes、ジョン・ピーターソン、およびジョナサン・ローゼンバーグはこのドキュメントを改良した実質的なコメントを提供しました。
Brian Carpenter, Lars Eggert, Pasi Eronen, Chris Newman, and Glen Zorn provided feedback during IESG review and Gen-ART review.
ブライアンCarpenter、ラース・エッゲルト、パシEronen、クリス・ニューマン、およびGlenゾルンはIESGレビューとGen-ARTレビューの間、フィードバックを提供しました。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[1] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
December 2004.
[1]Schulzrinne、2004年12月のH.、「Telephone民数記のためのtel URI」RFC3966。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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問題部に書くためのガイドライン」、BCP26、RFC5226)は2008がそうするかもしれません。
7.2. Informative References
7.2. 有益な参照
[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.ローゼンは「セッション開始プロトコル(一口)のために過程を変えます」、BCP67、RFC3427、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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
Jennings & Gurbani Standards Track [Page 5] RFC 5341 IANA Registry for TEL URI Parameters September 2008
ジョニングスとGurbani規格は2008年9月にTEL URIパラメタのためにRFC5341IANA登録を追跡します[5ページ]。
[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.、「セッション開始プロトコル(一口)のためのISOCの機関の一つで(IANA)Uniform Resource Identifier(URI)パラメタ登録」、BCP99、RFC3969(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:」 1999年12月の「ISDNユーザ部分シグナリング手順。」
Authors' Addresses
作者のアドレス
Cullen Jennings Cisco Systems 170 West Tasman Drive Mailstop SJC-21/2 San Jose, CA 95134 USA
西タスマン・ドライブMailstop SJC-21/2カレンジョニングスシスコシステムズ170カリフォルニア95134サンノゼ(米国)
Phone: +1 408 902-3341 EMail: fluffy@cisco.com
以下に電話をしてください。 +1 408 902-3341 メールしてください: fluffy@cisco.com
Vijay K. Gurbani Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane Room 9F-546 Lisle, IL 60532 USA
ビジェイK.Gurbaniベル研究所、2701の9アルカテル透明な透明なレーン余地のF-546ライル糸、IL60532米国
Phone: +1 630 224-0216 EMail: vkg@alcatel-lucent.com
以下に電話をしてください。 +1 630 224-0216 メールしてください: vkg@alcatel-lucent.com
Jennings & Gurbani Standards Track [Page 6] RFC 5341 IANA Registry for TEL URI Parameters September 2008
ジョニングスとGurbani規格は2008年9月にTEL URIパラメタのためにRFC5341IANA登録を追跡します[6ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントは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, 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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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に情報を記述してください。
Jennings & Gurbani Standards Track [Page 7]
ジョニングスとGurbani標準化過程[7ページ]
一覧
スポンサーリンク
