RFC 3969 - The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP) 日本語訳

URL : https://tools.ietf.org/html/rfc3969
タイトル : RFC 3969 - セッション開始プロトコル（SIP）のためのURI（Uniform Resource Identifier）パラメータ登録番号機関（IANA）が割り当てられ、インターネット
翻訳編集 : 自動生成

Network Working Group                                       G. Camarillo
Request for Comments: 3969                                      Ericsson
Updates: 3427                                              December 2004
BCP: 99
Category: Best Current Practice

             The Internet Assigned Number Authority (IANA)
         Uniform Resource Identifier (URI) Parameter Registry
               for the Session Initiation Protocol (SIP)

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を指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。

著作権表示

著作権（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.

この文書では、セッション開始プロトコル（SIP）のための番号機関（IANA）レジストリを割り当て、インターネットを作成し、統一資源識別子（URI）のパラメータ、およびそれらの値をSIPS。また、そのレジストリの初期値として使用する既存のパラメータを示します。

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. 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.

RFC 3261 [1]は、新しいSIP URIを可能にし、URIパラメータをSIPS、新しいパラメータ値が定義されます。ただし、RFC 3261には、彼らのために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.

RFC 3427 [2]はSIPを拡張するプロセスを文書化。この文書は、新しいSIPおよびSIP URIパラメータとその値を定義して登録する方法を指定することにより、RFC 3427を更新します。

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"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" BCP 14、RFC 2119に記載されているように、[3]に解釈されるべきであり、準拠SIP実装の要求レベルを示します。

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.

これらのパラメータのURIパラメータおよび値はIANAによって登録されるために標準トラックRFCに文書化されなければならないSIPとSIPS。このドキュメントは、完全な構文、使用目的、およびパラメータの意味を説明しなければなりません。この要件の目的は、独立した実装間の相互運用性を確保するために、そして、異なる機能の実装間の偶発名前空間の衝突を防ぐためです。

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.

このレジストリは、他のプロトコルレジストリとは異なり、唯一のRFC（すなわち、それはベンダ拡張ツリーを欠く）で定義されたパラメータとパラメータ値を扱うことに留意されたいです。 RFC 3427 [2]セキュリティに損傷を与える可能性が新しいSIP拡張機能に関して有する文書の問題が、大幅プロトコルの複雑さを増加させる、またはその両方。新しいパラメータおよびパラメータ値は、これらの懸念の結果としてRFCで文書化する必要があります。

RFCs defining SIP URI, SIPS URI parameters, or parameter values MUST register them with IANA as described below.

SIP URIを定義するRFCは、URIパラメータをSIPS、または以下に説明するようにパラメータ値は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登録され、URIパラメータとその値が「予約語」と考えられるべきであるSIPS。相互運用性を維持するために、登録されたパラメータは、それらの定義RFCに記載されたものと一致した方法で使用されなければなりません。実装は、その登録されたパラメータと競合する「プライベート」または「ローカルに定義された」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 URIとパラメータをSIPSが実装で使用されてもよいが、開発者はそのようなパラメーターの使用が危険であることを警告されることに留意されたいです。新しいSIPおよびそれらのためのURIパラメータと新しい値をSIPSはいつでも登録されている場合があり、これらの新しい登録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パラメータは事前に定義されたパラメータ値のセットを受け入れます。例えば、使用中のトランスポートプロトコルを示すパラメータは、唯一の有効な値としてあらかじめ定義されたトークンのTCP、UDP、およびSCTPを受け入れることができます。すべてのSIPのためのすべてのパラメータ値を登録し、このタイプのURIパラメータはsubregistriesの多数を必要とSIPS。代わりに、我々は、参照することによってURIパラメータ値を登録することを選択しました。つまり、与えられたURIパラメータのURIパラメータレジストリのエントリは、そのパラメータの新しい値を定義するRFCへの参照が含まれています。パラメータ値を定義するRFCへの参照は、レジストリ内の二重括弧内に表示されます。

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 URIおよびパラメータレジストリをSIPS各パラメータのみ定義済みの値のセットを受け入れるか否かを示す列を含みます。その列の「はい」とパラメータの実装は、リファレンスとして提供するRFCのすべての有効なパラメータ値を見つける必要があります。

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.

RFC 3261のセクション27 [1]メソッド名、ヘッダフィールド名、警告コード、ステータスコード、およびオプションタグのIANAレジストリを作成します。この仕様は、SIPパラメータのレジストリの下に新しいサブレジストリを作成します。

o SIP/SIPS URI Parameters

SIP O / URIパラメータをSIPS

4.1. SIP and SIPS URI Parameters Sub-Registry

4.1. SIP URIおよびパラメータのサブレジストリをSIPS

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 URIとパラメータと新しいパラメータ値がIANAによって登録されているSIPS。新しいSIPまたはSIPSのパラメータまたはパラメータの新しい値を登録すると、次の情報が提供されなければなりません。

o Name of the parameter.

Oパラメータの名前。

o Whether the parameter only accepts a set of predefined values.

パラメータは事前に定義された値のセットを受け入れるかどうか、O。

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を参照。パラメータ値を定義するRFCへの参照は、レジストリ内の二重括弧内に表示されます。

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]

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パラメータとしての両方が登録されていることに留意されたいです。それでも、いくつかのパラメータは、スキームのいずれかに適用されない場合があります。私たちは、SIPの両方として任意のパラメータを登録することを選択し、同じ名前の2つのパラメータ、SIP URIに適用される1とSIPS URIに、しかし異なる意味を持つ1つを有する避けるために、とにかくURIパラメータをSIPSています。実装者は、任意のパラメータの意味の詳細については、パラメータの仕様を読むことを促しています。

4.2. Registration Policy for SIP and SIPS URI Parameters

4.2. SIPの登録ポリシーとURIパラメータをSIPS

As per the terminology in RFC 2434 [4], the registration policy for SIP and SIPS URI parameters shall be "Specification Required".

RFC 2434における用語に従って、[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.

このレジストリの目的のために、IANA登録が要求されているパラメータは、標準トラックRFCで定義されなければなりません。

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.

この文書に記載されているレジストリは、それ自体ではセキュリティ上の配慮を持っていません。 RFC 3427で述べたようにしかし、IETFはSIPの拡張を管理するための重要な理由は、すべての拡張機能やパラメータは、安全な使用方法を提供することが可能であることを確認することです。パラメータの登録のためのサポートRFCの出版物は、この仕様は、彼らのために、詳細なセキュリティ上の考慮事項を提供しなければならない説明しました。

6. Acknowledgements

6.謝辞

Jonathan Rosenberg, Henning Schulzrinne, Rohan Mahy, Dean Willis, and Allison Mankin provided useful comments on this document.

ジョナサン・ローゼンバーグ、ヘニングSchulzrinneと、ローハンマーイ、ディーンウィリス、そしてアリソンマンキンはこのドキュメントの役に立つコメントを提供しました。

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.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、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.ローゼン、 "セッション開始プロトコル（SIP）のための変更処理"、BCP 67、RFC 3427、2002年12月。

[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[3]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。

[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問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。

Author's Address

著者のアドレス

Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland

ゴンサロ・カマリロエリクソン高度なシグナリング研究所。 FIN-02420 Jorvasフィンランド

EMail: Gonzalo.Camarillo@ericsson.com

メールアドレス：Gonzalo.Camarillo@ericsson.com

Full Copyright Statement

完全な著作権声明

著作権（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.

この文書では、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 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が表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。

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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 IETF文書の権利に関するIETFの手続きの情報は、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に情報を記述してください。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。