[要約] RFC 3968は、SIPヘッダーフィールドパラメータレジストリのためのIANA(Internet Assigned Number Authority)の役割と目的を定義しています。このRFCの目的は、SIPプロトコルのヘッダーフィールドパラメータの一貫性と一意性を確保するために、IANAがパラメータの登録と管理を行うことです。

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

The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)

セッション開始プロトコル (SIP) の Internet Assigned Number Authority (IANA) ヘッダー フィールド パラメーター レジストリ

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.

この文書は、インターネット コミュニティ向けのインターネットの現在のベスト プラクティスを指定し、改善のための議論と提案を求めます。このメモの配布は無制限です。

Copyright Notice

著作権表示

Copyright (C) The Internet Society (2004).

著作権 (C) インターネット協会 (2004)。

Abstract

概要

This document creates an Internet Assigned Number Authority (IANA) registry for the Session Initiation Protocol (SIP) header field parameters and parameter values. It also lists the already existing parameters and parameter values to be used as the initial entries for this registry.

このドキュメントでは、Session Initiation Protocol (SIP) ヘッダー フィールドのパラメーターとパラメーター値用の Internet Assigned Number Authority (IANA) レジストリを作成します。また、このレジストリの初期エントリとして使用される既存のパラメータとパラメータ値もリストされます。

Table of Contents

目次

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  2
   3.  Use of the Registry  . . . . . . . . . . . . . . . . . . . . .  2
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  3
       4.1.  Header Field Parameters Sub-Registry . . . . . . . . . .  3
       4.2.  Registration Policy for SIP Header Field Parameters. . .  6
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  7
   7.  Normative References . . . . . . . . . . . . . . . . . . . . .  7
       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  7
       Full Copyright Statement . . . . . . . . . . . . . . . . . . .  8
        
1. Introduction
1. はじめに

RFC 3261 [3] allows new header field 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 [3] では、新しいヘッダフィールドパラメータと新しいパラメータ値を定義できます。ただし、RFC 3261 では、それらの IANA レジストリが省略されています。このドキュメントではそのようなレジストリを作成します。

RFC 3427 [4] documents the process to extend SIP. This document updates RFC 3427 by specifying how to define and register new SIP header field parameters and parameter values.

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

2. Terminology
2. 用語

In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations.

この文書では、「しなければならない」、「してはならない」、「必須」、「しなければならない」、「してはならない」、「すべきである」、「すべきではない」、「推奨される」、「推奨されない」、「してもよい」というキーワードが使用されます。、および「OPTIONAL」は、BCP 14、RFC 2119 [1] に記載されているように解釈され、準拠する実装の要件レベルを示します。

3. Use of the Registry
3. レジストリの使用

SIP header field parameters and parameter values MUST be documented in an RFC in order to be registered by IANA. This documentation MUST fully explain the syntax, intended usage, and semantics of the parameter or parameter value. 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 ヘッダー フィールドのパラメーターとパラメーター値を 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 [4] 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 [4] は、セキュリティを損なう可能性、プロトコルの大幅な複雑性の増加、またはその両方を引き起こす可能性のある新しい SIP 拡張機能に関する懸念を文書化しています。こうした懸念があるため、新しいパラメータとパラメータ値を RFC で文書化する必要があります。

RFCs defining SIP header field parameters or parameter values MUST register them with IANA as described below.

SIP ヘッダフィールドのパラメータまたはパラメータ値を定義する RFC は、以下に説明するように、それらを IANA に登録しなければなりません (MUST)。

Registered SIP header field parameters and parameter values are to be considered "reserved words". In order to preserve interoperability, registered parameters and parameter values MUST be used in a manner consistent with that described in their defining RFC. Implementations MUST NOT utilize "private" or "locally defined" SIP header field parameters or parameter values that conflict with registered parameters.

登録された SIP ヘッダー フィールドのパラメーターとパラメーター値は「予約語」とみなされます。相互運用性を維持するために、登録されたパラメータとパラメータ値は、定義された RFC に記載されている方法と一致する方法で使用されなければなりません (MUST)。実装では、登録されたパラメータと競合する「プライベート」または「ローカルに定義された」SIP ヘッダー フィールド パラメータやパラメータ値を利用してはなりません。

Note that although unregistered SIP header field parameters and parameter values may be used in implementations, developers are cautioned that usage of such parameters is risky. New SIP header field parameters and parameter values may be registered at any time, and there is no assurance that these new registered parameters or parameter values will not conflict with unregistered parameters currently in use.

未登録の SIP ヘッダー フィールド パラメータおよびパラメータ値が実装で使用される可能性がありますが、開発者はそのようなパラメータの使用には危険が伴うことに注意してください。新しい SIP ヘッダー フィールド パラメータおよびパラメータ値はいつでも登録できますが、これらの新しく登録されたパラメータまたはパラメータ値が、現在使用されている未登録のパラメータと競合しないという保証はありません。

Some SIP header field 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 header field parameters of this type would require a large number of subregistries. Instead, we have chosen to register parameter values by reference. That is, the entry in the parameter registry for a given header field parameter contains references to the RFCs defining new values of the parameter. References to RFCs defining parameter values appear in double brackets in the registry.

一部の SIP ヘッダー フィールド パラメーターは、事前定義されたパラメーター値のセットのみを受け入れます。たとえば、使用中のトランスポート プロトコルを示すパラメータは、事前定義されたトークン TCP、UDP、および SCTP のみを有効な値として受け入れることができます。このタイプのすべての SIP ヘッダー フィールド パラメータのすべてのパラメータ値を登録するには、多数のサブレジストリが必要になります。代わりに、パラメータ値を参照によって登録することを選択しました。つまり、特定のヘッダー フィールド パラメータのパラメータ レジストリのエントリには、パラメータの新しい値を定義する RFC への参照が含まれています。パラメータ値を定義する RFC への参照は、レジストリ内で二重括弧内に表示されます。

So, the header field 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.

したがって、ヘッダー フィールドのパラメーター レジストリには、各パラメーターが事前定義された値のセットのみを受け入れるかどうかを示す列が含まれています。その列に「はい」が含まれているパラメータの実装者は、参照として提供されている RFC 内の有効なパラメータ値をすべて見つける必要があります。

4. IANA Considerations
4. IANAの考慮事項

Section 27 of RFC 3261 [3] creates an IANA registry for method names, header field names, warning codes, status codes, and option tags. This specification creates a new sub-registry for header field parameters under the SIP Parameters registry.

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

4.1. Header Field Parameters Sub-Registry
4.1. ヘッダーフィールドパラメータのサブレジストリ

The majority of the SIP header fields can be extended by defining new parameters. New SIP header field parameters are registered by the IANA. When registering a new parameter for a header field or a new value for a parameter, the following information MUST be provided.

SIP ヘッダー フィールドの大部分は、新しいパラメータを定義することで拡張できます。新しい SIP ヘッダー フィールド パラメータは IANA によって登録されます。ヘッダーフィールドの新しいパラメータまたはパラメータの新しい値を登録するときは、次の情報を提供する必要があります。

o Header field in which the parameter can appear.

o パラメーターを表示できるヘッダー フィールド。

o Name of the header field parameter being registered.

o 登録されているヘッダーフィールドパラメータの名前。

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

o パラメーターが事前定義された値のセットのみを受け入れるかどうか。

o A reference to the RFC where the parameter is defined 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 への参照は、レジストリ内で二重括弧内に表示されます。

Parameters that can appear in different header fields MAY have the same name. However, parameters that can appear in the same header field MUST have different names.

異なるヘッダーフィールドに表示されるパラメーターは同じ名前を持つことができます (MAY)。ただし、同じヘッダーフィールドに表示できるパラメータには異なる名前を付ける必要があります。

The following are the initial values for this sub-registry.

このサブレジストリの初期値は次のとおりです。

   Header Field                  Parameter Name   Predefined  Reference
                                                    Values
   _____________________________________________________________________
   Accept                        q                    No     [RFC 3261]
   Accept-Encoding               q                    No     [RFC 3261]
   Accept-Language               q                    No     [RFC 3261]
   Authorization                 algorithm           Yes     [RFC 3261]
                                                            [[RFC 3310]]
   Authorization                 auts                 No     [RFC 3310]
   Authorization                 cnonce               No     [RFC 3261]
   Authorization                 nc                   No     [RFC 3261]
   Authorization                 nonce                No     [RFC 3261]
   Authorization                 opaque               No     [RFC 3261]
   Authorization                 qop                 Yes     [RFC 3261]
   Authorization                 realm                No     [RFC 3261]
   Authorization                 response             No     [RFC 3261]
   Authorization                 uri                  No     [RFC 3261]
   Authorization                 username             No     [RFC 3261]
   Authentication-Info           cnonce               No     [RFC 3261]
   Authentication-Info           nc                   No     [RFC 3261]
   Authentication-Info           nextnonce            No     [RFC 3261]
   Authentication-Info           qop                 Yes     [RFC 3261]
   Authentication-Info           rspauth              No     [RFC 3261]
   Call-Info                     purpose             Yes     [RFC 3261]
   Contact                       expires              No     [RFC 3261]
   Contact                       q                    No     [RFC 3261]
   Content-Disposition           handling            Yes     [RFC 3261]
   Event                         id                   No     [RFC 3265]
   From                          tag                  No     [RFC 3261]
   P-Access-Network-Info         cgi-3gpp             No     [RFC 3455]
   P-Access-Network-Info         utran-cell-id-3gpp   No     [RFC 3455]
   P-Charging-Function-Addresses ccf                  No     [RFC 3455]
   P-Charging-Function-Addresses ecf                  No     [RFC 3455]
   P-Charging-Vector             icid-value           No     [RFC 3455]
   P-Charging-Vector             icid-generated-at    No     [RFC 3455]
   P-Charging-Vector             orig-ioi             No     [RFC 3455]
   P-Charging-Vector             term-ioi             No     [RFC 3455]
      P-DCS-Billing-Info            called               No     [RFC 3603]
   P-DCS-Billing-Info            calling              No     [RFC 3603]
   P-DCS-Billing-Info            charge               No     [RFC 3603]
   P-DCS-Billing-Info            locroute             No     [RFC 3603]
   P-DCS-Billing-Info            rksgroup             No     [RFC 3603]
   P-DCS-Billing-Info            routing              No     [RFC 3603]
   P-DCS-LAES                    content              No     [RFC 3603]
   P-DCS-LAES                    key                  No     [RFC 3603]
   P-DCS-Redirect                count                No     [RFC 3603]
   P-DCS-Redirect                redirector-uri       No     [RFC 3603]
   Proxy-Authenticate            algorithm           Yes     [RFC 3261]
                                                            [[RFC 3310]]
   Proxy-Authenticate            domain               No     [RFC 3261]
   Proxy-Authenticate            nonce                No     [RFC 3261]
   Proxy-Authenticate            opaque               No     [RFC 3261]
   Proxy-Authenticate            qop                 Yes     [RFC 3261]
   Proxy-Authenticate            realm                No     [RFC 3261]
   Proxy-Authenticate            stale               Yes     [RFC 3261]
   Proxy-Authorization           algorithm           Yes     [RFC 3261]
                                                            [[RFC 3310]]
   Proxy-Authorization           auts                 No     [RFC 3310]
   Proxy-Authorization           cnonce               No     [RFC 3261]
   Proxy-Authorization           nc                   No     [RFC 3261]
   Proxy-Authorization           nonce                No     [RFC 3261]
   Proxy-Authorization           opaque               No     [RFC 3261]
   Proxy-Authorization           qop                 Yes     [RFC 3261]
   Proxy-Authorization           realm                No     [RFC 3261]
   Proxy-Authorization           response             No     [RFC 3261]
   Proxy-Authorization           uri                  No     [RFC 3261]
   Proxy-Authorization           username             No     [RFC 3261]
   Reason                        cause               Yes     [RFC 3326]
   Reason                        text                 No     [RFC 3326]
   Retry-After                   duration             No     [RFC 3261]
   Security-Client               alg                 Yes     [RFC 3329]
   Security-Client               ealg                Yes     [RFC 3329]
   Security-Client               d-alg               Yes     [RFC 3329]
   Security-Client               d-qop               Yes     [RFC 3329]
   Security-Client               d-ver                No     [RFC 3329]
   Security-Client               mod                 Yes     [RFC 3329]
   Security-Client               port1                No     [RFC 3329]
   Security-Client               port2                No     [RFC 3329]
   Security-Client               prot                Yes     [RFC 3329]
   Security-Client               q                    No     [RFC 3329]
   Security-Client               spi                  No     [RFC 3329]
   Security-Server               alg                 Yes     [RFC 3329]
   Security-Server               ealg                Yes     [RFC 3329]
   Security-Server               d-alg               Yes     [RFC 3329]
   Security-Server               d-qop               Yes     [RFC 3329]
      Security-Server               d-ver                No     [RFC 3329]
   Security-Server               mod                 Yes     [RFC 3329]
   Security-Server               port1                No     [RFC 3329]
   Security-Server               port2                No     [RFC 3329]
   Security-Server               prot                Yes     [RFC 3329]
   Security-Server               q                    No     [RFC 3329]
   Security-Server               spi                  No     [RFC 3329]
   Security-Verify               alg                 Yes     [RFC 3329]
   Security-Verify               ealg                Yes     [RFC 3329]
   Security-Verify               d-alg               Yes     [RFC 3329]
   Security-Verify               d-qop               Yes     [RFC 3329]
   Security-Verify               d-ver                No     [RFC 3329]
   Security-Verify               mod                 Yes     [RFC 3329]
   Security-Verify               port1                No     [RFC 3329]
   Security-Verify               port2                No     [RFC 3329]
   Security-Verify               prot                Yes     [RFC 3329]
   Security-Verify               q                    No     [RFC 3329]
   Security-Verify               spi                  No     [RFC 3329]
   Subscription-State            expires              No     [RFC 3265]
   Subscription-State            reason              Yes     [RFC 3265]
   Subscription-State            retry-after          No     [RFC 3265]
   To                            tag                  No     [RFC 3261]
   Via                           branch               No     [RFC 3261]
   Via                           comp                Yes     [RFC 3486]
   Via                           maddr                No     [RFC 3261]
   Via                           received             No     [RFC 3261]
   Via                           rport                No     [RFC 3581]
   Via                           ttl                  No     [RFC 3261]
   WWW-Authenticate              algorithm           Yes     [RFC 3261]
                                                            [[RFC 3310]]
   WWW-Authenticate              domain              Yes     [RFC 3261]
   WWW-Authenticate              nonce                No     [RFC 3261]
   WWW-Authenticate              opaque               No     [RFC 3261]
   WWW-Authenticate              qop                 Yes     [RFC 3261]
   WWW-Authenticate              realm                No     [RFC 3261]
   WWW-Authenticate              stale               Yes     [RFC 3261]
        
4.2. Registration Policy for SIP Header Field Parameters
4.2. SIP ヘッダーフィールドパラメータの登録ポリシー

As per the terminology in RFC 2434 [2], the registration policy for SIP header field parameters and parameter values shall be "IETF Consensus."

RFC 2434 [2] の用語に従って、SIP ヘッダフィールドのパラメータとパラメータ値の登録ポリシーは「IETF コンセンサス」でなければなりません。

For the purposes of this registry, the parameter or the parameter value for which IANA registration is requested MUST be defined by an RFC. There is no requirement that this RFC be standards-track.

このレジストリの目的のために、IANA 登録が要求されるパラメータまたはパラメータ値は RFC によって定義されなければなりません (MUST)。この 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 出版物は、パラメータ登録に関する詳細なセキュリティ上の考慮事項を提供しなければなりません (MUST)。

6. Acknowledgements
6. 謝辞

Jonathan Rosenberg, Henning Schulzrinne, Rohan Mahy, Dean Willis, Aki Niemi, Bill Marshall, Miguel A. Garcia-Martin, Jean Francois Mule, and Allison Mankin provided useful comments on this document.

Jonathan Rosenberg、Henning Schulzrinne、Rohan Mahy、Dean Willis、Aki Niemi、Bill Marshall、Miguel A. Garcia-Martin、Jean Francois Mule、Allison Mankin がこの文書に関して有益なコメントを提供してくれました。

7. Normative References
7. 引用文献

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

[1] Bradner, S.、「要件レベルを示すために RFC で使用するキーワード」、BCP 14、RFC 2119、1997 年 3 月。

[2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

[2] Narten, T. および H. Alvestruct、「RFC で IANA 考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998 年 10 月。

[3] 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.

[3] Rosenberg, J.、Schulzrinne, H.、Camarillo, G.、Johnston, A.、Peterson, J.、Sparks, R.、Handley, M.、および E. Schooler、「SIP: セッション開始プロトコル」、RFC 3261、2002年6月。

[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年。

Author's Address

著者の連絡先

Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland

ゴンサロ・カマリロ・エリクソン・ヒルサランティエ 11 ジョルバス 02420 フィンランド

   EMail: Gonzalo.Camarillo@ericsson.com
        

Full Copyright Statement

完全な著作権に関する声明

Copyright (C) The Internet Society (2004).

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

この文書およびここに含まれる情報は「現状のまま」で提供され、寄稿者、寄稿者が代表または後援する組織(存在する場合)、インターネット協会およびインターネット エンジニアリング タスク フォースは、明示的または明示的または明示的に、すべての保証を否認します。ここに記載された情報の使用がいかなる権利も侵害しないことの黙示的な保証、または商品性や特定の目的への適合性の黙示的な保証を含みますが、これに限定されません。

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.

IETF 事務局に提出された IPR 開示のコピー、および利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような所有権の使用に対する一般ライセンスまたは許可を取得しようとする試みの結果を入手できます。IETF オンライン IPR リポジトリ (http://www.ietf.org/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 (ietf-ipr@ietf.org) に送信してください。

Acknowledgement

謝辞

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

RFC エディター機能の資金は現在、インターネット協会によって提供されています。