RFC3969 日本語訳
3969 The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session InitiationProtocol (SIP). G. Camarillo. December 2004. (Format: TXT=12119 bytes) (Updates RFC3427) (Also BCP0099) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Camarillo Request for Comments: 3969 Ericsson Updates: 3427 December 2004 BCP: 99 Category: Best Current Practice
コメントを求めるワーキンググループG.キャマリロの要求をネットワークでつないでください: 3969のエリクソンアップデート: 3427 2004年12月のBCP: 99カテゴリ: 最も良い現在の習慣
The Internet Assigned Number Authority (IANA)
Uniform Resource Identifier (URI) Parameter Registry
for the Session Initiation Protocol (SIP)
セッション開始プロトコルのためのISOCの機関の一つで(IANA)Uniform Resource Identifier(URI)パラメタ登録(一口)
Status of This Memo
このメモの状態
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(2004)。
Abstract
要約
This document creates an Internet Assigned Number Authority (IANA) registry for the Session Initiation Protocol (SIP) and SIPS Uniform Resource Identifier (URI) parameters, and their values. It also lists the already existing parameters to be used as initial values for that registry.
このドキュメントはSession Initiationプロトコル(SIP)、SIPS Uniform Resource Identifier(URI)パラメタ、およびそれらの値のためにISOCの機関の一つで(IANA)登録を作成します。 また、それは、その登録に初期の値として使用されるために既に既存のパラメタをリストアップします。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Use of the Registry. . . . . . . . . . . . . . . . . . . . . . 2
4. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 3
4.1. SIP and SIPS URI Parameters Sub-Registry . . . . . . . . 3
4.2. Registration Policy for SIP and SIPS URI Parameters. . . 4
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 4
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4
7. Normative References . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 5
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 6
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語。 . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. 登録の使用。 . . . . . . . . . . . . . . . . . . . . . 2 4. IANA問題。 . . . . . . . . . . . . . . . . . . . . . 3 4.1. サブ登録.34.2にURIパラメタをちびちび飲んで、ちびちび飲みます。 一口と一口URIパラメタのための登録方針。 . . 4 5. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 4 6. 承認. . . . . . . . . . . . . . . . . . . . . . . 4 7。 引用規格. . . . . . . . . . . . . . . . . . . . . 5作者のアドレスの.5の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 6
Camarillo Best Current Practice [Page 1] RFC 3969 IANA URI Parameter Registry for SIP December 2004
一口2004年12月のためのキャマリロの最も良い現在の習慣[1ページ]RFC3969IANA URIパラメタ登録
1. Introduction
1. 序論
RFC 3261 [1] allows new SIP URI and SIPS URI parameters, and new parameter values to be defined. However, RFC 3261 omitted an IANA registry for them. This document creates such a registry.
RFC3261[1]は、新しいSIP URI、SIPS URIパラメタ、および新しいパラメタ値が定義されるのを許容します。 しかしながら、RFC3261はそれらのためにIANA登録を省略しました。 このドキュメントはそのような登録を作成します。
RFC 3427 [2] documents the process to extend SIP. This document updates RFC 3427 by specifying how to define and register new SIP and SIP URI parameters and their values.
RFC3427[2]は、SIPを広げるために過程を記録します。 どのように新しいSIP、SIP URIパラメタ、およびそれらの値を定義して、示すかを指定することによって、このドキュメントはRFC3427をアップデートします。
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 [3] and indicate requirement levels for compliant SIP implementations.
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTが解釈されるのは中でBCP14について説明しました、RFC2119[3]ということであり、対応する一口実現のために要件レベルを示すべきであるかをさせましょう。
3. Use of the Registry
3. 登録の使用
SIP and SIPS URI parameters and values for these parameters MUST be documented in a standards-track RFC 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によって登録されるように、これらのパラメタのためのSIP、SIPS URIパラメタ、および値を標準化過程RFCに記録しなければなりません。 このドキュメンテーションで、構文、意図している用法、およびパラメタの意味論が完全にわからなければなりません。 この要件の意図は、独立している実現の間の相互運用性を保証して、異なった特徴の実現の間の偶然の名前空間衝突を防ぐことです。
Note that this registry, unlike other protocol registries, only
deals with parameters and parameter values defined in RFCs (i.e.,
it lacks a vendor-extension tree). RFC 3427 [2] documents
concerns with regards to new SIP extensions which may damage
security, greatly increase the complexity of the protocol, or
both. New parameters and parameter values need to be documented
in RFCs as a result of these concerns.
この登録が他のプロトコル登録と異なってRFCsで定義されたパラメタとパラメタ値に対処するだけであることに注意してください(すなわち、それは業者拡大木を欠いています)。 RFC3427[2]はセキュリティを破損するかもしれない新しいSIP拡張子にあいさつがある関心を記録して、プロトコル、または両方の複雑さを大いに増加させてください。 新しいパラメタとパラメタ値は、これらの関心の結果、RFCsに記録される必要があります。
RFCs defining SIP URI, SIPS URI parameters, or parameter values MUST register them with IANA as described below.
SIP URIを定義するRFCs、SIPS URIパラメタ、またはパラメタ値が以下で説明されるようにIANAにそれらを登録しなければなりません。
Registered SIP and SIPS URI parameters and their values are to be considered "reserved words". In order to preserve interoperability, registered parameters MUST be used in a manner consistent with that described in their defining RFC. Implementations MUST NOT utilize "private" or "locally defined" URI parameters that conflict with registered parameters.
登録されたSIP、SIPS URIパラメタ、およびそれらの値は「リザーブドワード」であると考えられることです。 相互運用性を保存するために、RFCを定義する際に説明されるそれと一致した方法で登録されたパラメタを使用しなければなりません。 実現は登録されたパラメタと衝突する「個人的である」か「局所的に定義された」URIパラメタを利用してはいけません。
Camarillo Best Current Practice [Page 2] RFC 3969 IANA URI Parameter Registry for SIP December 2004
一口2004年12月のためのキャマリロの最も良い現在の習慣[2ページ]RFC3969IANA URIパラメタ登録
Note that although unregistered SIP and SIPS URI parameters may be
used in implementations, developers are cautioned that usage of
such parameters is risky. New SIP and SIPS URI parameters and new
values for them may be registered at any time, and there is no
assurance that these new registered URI parameters will not
conflict with unregistered parameters currently in use.
登録されていないSIPとSIPS URIパラメタが実現に使用されるかもしれませんが、開発者がそのようなパラメタの用法が危険であると警告されることに注意してください。 それらのための新しいSIP、SIPS URIパラメタ、および新しい値はいつでも示されるかもしれません、そして、これらの新しい登録されたURIパラメタが現在使用中の登録されていないパラメタと衝突しないという保証が全くありません。
Some SIP and SIPS URI parameters only accept a set of predefined parameter values. For example, a parameter indicating the transport protocol in use may only accept the predefined tokens TCP, UDP, and SCTP as valid values. Registering all parameter values for all SIP and SIPS URI parameters of this type would require a large number of subregistries. 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. References to RFCs defining parameter values appear in double brackets in the registry.
いくらかのSIPとSIPS URIパラメタは1セットの事前に定義されたパラメタ値を受け入れるだけです。 例えば、使用中のトランスポート・プロトコルを示すパラメタは有効値として事前に定義された象徴のTCP、UDP、およびSCTPを認めるだけであるかもしれません。 このタイプのすべてのSIPとSIPS URIパラメタのためにすべてのパラメタ値を示すのは多くの副登録を必要とするでしょう。 代わりに、私たちは、参照でURIパラメタ値を示すのを選びました。 すなわち、与えられたURIパラメタのためのURIパラメタ登録のエントリーはそのパラメタの新しい値を定義するRFCsの参照を含んでいます。 パラメタ値を定義するRFCsの参照は登録の二重括弧に現れます。
So, the SIP and SIPS URI parameter registry contains a column that indicates whether or not each parameter only accepts a set of predefined values. Implementers of parameters with a "yes" in that column need to find all the valid parameter values in the RFCs provided as references.
それで、SIPとSIPS URIパラメタ登録は各パラメタが1セットの事前に定義された値を受け入れるだけであるかどうかを示すコラムを含んでいます。 「はい」がそのコラムにあるパラメタのImplementersは、参照として提供されたRFCsですべての有効なパラメタ値を見つける必要があります。
4. IANA Considerations
4. IANA問題
Section 27 of RFC 3261 [1] creates an IANA registry for method names, header field names, warning codes, status codes, and option tags. This specification creates a new sub-registry under the SIP Parameters registry.
RFC3261[1]のセクション27は方法名、ヘッダーフィールド名、警告コード、ステータスコード、およびオプションタグのためのIANA登録を作成します。 この仕様はSIP Parameters登録の下の新しいサブ登録を作成します。
o SIP/SIPS URI Parameters
o 一口/一口URIパラメタ
4.1. SIP and SIPS URI Parameters Sub-Registry
4.1. 一口と一口URIパラメタサブ登録
New SIP and SIPS URI parameters and new parameter values are registered by the IANA. When registering a new SIP or SIPS parameter or a new value for a parameter, the following information MUST be provided.
新しいSIP、SIPS URIパラメタ、および新しいパラメタ値はIANAによって示されます。 パラメタのために新しいSIP、SIPSパラメタまたは新しい値を示すとき、以下の情報を提供しなければなりません。
o Name of the parameter.
o パラメタの名前。
o Whether the parameter only accepts a set of predefined values.
o パラメタは1セットの事前に定義された値を受け入れるのであるだけであるかどうか
o Reference to the RFC defining the parameter and to any RFC that
defines new values for the parameter. References to RFCs
defining parameter values appear in double brackets in the
registry.
o パラメタを定義するRFCとパラメタのために新しい値を定義するどんなRFCの参照。 パラメタ値を定義するRFCsの参照は登録の二重括弧に現れます。
Camarillo Best Current Practice [Page 3] RFC 3969 IANA URI Parameter Registry for SIP December 2004
一口2004年12月のためのキャマリロの最も良い現在の習慣[3ページ]RFC3969IANA URIパラメタ登録
Table 1 contains the initial values for this sub-registry.
テーブル1はこのサブ登録への初期の値を含んでいます。
Parameter Name Predefined Values Reference
____________________________________________
comp Yes [RFC 3486]
lr No [RFC 3261]
maddr No [RFC 3261]
method Yes [RFC 3261]
transport Yes [RFC 3261]
ttl No [RFC 3261]
user Yes [RFC 3261]
事前に定義されたパラメタ名は参照を評価します。____________________________________________ はい、はい、はい、コンピュータmaddrの[RFC3486]lrノー[RFC3261]ノー[RFC3261]方法[RFC3261]輸送[RFC3261]ttl、いいえ[RFC3261]、ユーザ、はい。[RFC3261]
Table 1: IANA SIP and SIPS URI parameter sub-registry
テーブル1: IANA SIPとSIPS URIパラメタサブ登録
Note that any given parameter name is registered both as a SIP and as a SIPS URI parameter. Still, some parameters may not apply to one of the schemes. We have chosen to register any parameter as both a SIP and SIPS URI parameter anyway to avoid having two parameters with the same name, one applicable to SIP URIs and one to SIPS URIs, but with different semantics. Implementors are urged to read the parameter specifications for a detailed description of the semantics of any parameter.
どんな与えられたパラメタ名もSIPとしてSIPS URIパラメタとして登録されることに注意してください。 それでも、いくつかのパラメタは計画の1つに適用されないかもしれません。 私たちは、同じ名前、SIP URIに適切な1つ、およびSIPS URIへの1にもかかわらず、異なった意味論で2つのパラメタを持っているのを避けるためにSIPとSIPS URIパラメタの両方としてとにかくどんなパラメタも示すのを選びました。 作成者がどんなパラメタの意味論の詳述のためのパラメタ仕様も読むよう促されます。
4.2. Registration Policy for SIP and SIPS URI Parameters
4.2. 一口と一口URIパラメタのための登録方針
As per the terminology in RFC 2434 [4], the registration policy for SIP and SIPS URI parameters shall be "Specification Required".
RFC2434[4]の用語に従って、SIPのための登録方針とSIPS URIパラメタは「仕様が必要です」でしょう。
For the purposes of this registry, the parameter for which IANA registration is requested MUST be defined by a standards-track RFC.
この登録の目的のために、標準化過程RFCはIANA登録が要求されているパラメタを定義しなければなりません。
5. Security Considerations
5. セキュリティ問題
The registry in this document does not in itself have security considerations. However, as mentioned in RFC 3427, 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 this specification MUST provide detailed security considerations for them.
登録には、本来、セキュリティ問題が本書ではありません。 しかしながら、IETFがSIPの拡大を管理する重要な理由はRFC3427で言及されるようにすべての拡大とパラメタが安全な用法を提供できるのを保証することです。 パラメタ登録証明書がこの仕様を説明したので、支持しているRFC刊行物は詳細なセキュリティ問題をそれらに提供しなければなりません。
6. Acknowledgements
6. 承認
Jonathan Rosenberg, Henning Schulzrinne, Rohan Mahy, Dean Willis, and Allison Mankin provided useful comments on this document.
ジョナサン・ローゼンバーグ、ヘニングSchulzrinne、Rohanマーイ、ディーン・ウィリス、およびアリソン・マンキンはこのドキュメントの役に立つコメントを提供しました。
Camarillo Best Current Practice [Page 4] RFC 3969 IANA URI Parameter Registry for SIP December 2004
一口2004年12月のためのキャマリロの最も良い現在の習慣[4ページ]RFC3969IANA URIパラメタ登録
7. Normative References
7. 引用規格
[1] 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.
[1] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[2] 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.
[2] マンキン、A.、ブラドナー、S.、マーイ、R.、ウィリス、D.、オット、J.、およびB.ローゼンは「セッション開始プロトコル(一口)のために過程を変えます」、BCP67、RFC3427、2002年12月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[4]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
Author's Address
作者のアドレス
Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland
ゴンサロキャマリロエリクソンは合図研究研究室を進めました。 フィン-02420Jorvasフィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メール: Gonzalo.Camarillo@ericsson.com
Camarillo Best Current Practice [Page 5] RFC 3969 IANA URI Parameter Registry for SIP December 2004
一口2004年12月のためのキャマリロの最も良い現在の習慣[5ページ]RFC3969IANA URIパラメタ登録
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機能のための基金は現在、インターネット協会によって提供されます。
Camarillo Best Current Practice [Page 6]
キャマリロの最も良い現在の習慣[6ページ]
一覧
スポンサーリンク
