[要約] RFC 3427は、SIPの変更プロセスに関するガイドラインであり、SIPプロトコルの改善と進化を促進することを目的としています。このRFCは、SIPの変更の提案、レビュー、承認、実装、およびデプロイメントに関する手順を提供しています。
Network Working Group A. Mankin
Request for Comments: 3427 Bell Labs, Lucent Corporation
BCP: 67 S. Bradner
Category: Best Current Practice Harvard University
R. Mahy
Cisco
D. Willis
dynamicsoft
J. Ott
ipDialog / Uni Bremen TZI
B. Rosen
Marconi
December 2002
Change Process for the Session Initiation Protocol (SIP)
セッション開始プロトコル（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.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
Abstract
概要
This memo documents a process intended to apply architectural discipline to the future development of the Session Initiation Protocol (SIP). There have been concerns with regards to new SIP proposals. Specifically, that the addition of new SIP features can be damaging towards security and/or greatly increase the complexity of the protocol. The Transport Area directors, along with the SIP and Session Initiation Proposal Investigation (SIPPING) working group chairs, have provided suggestions for SIP modifications and extensions.
このメモは、セッション開始プロトコル（SIP）の将来の開発に建築規律を適用することを目的としたプロセスを文書化しています。新しいSIP提案に関する懸念がありました。具体的には、新しいSIP機能の追加がセキュリティにダメージを与えたり、プロトコルの複雑さを大幅に向上させる可能性があります。輸送エリアのディレクターは、SIPおよびセッション開始提案調査（すすり回す）ワーキンググループチェアとともに、SIPの修正と拡張の提案を提供しています。
In this document, the key words "MAY", "MUST, "MUST NOT", "SHOULD", and "SHOULD NOT", are to be interpreted as described in Keywords [1].
このドキュメントでは、キーワードは「可能性があります」、「必要はない」、「そうでなければ」、「すべきではない」、「必要はない」は、キーワード[1]で説明されているように解釈されるべきではありません。
The IETF's Session Initiation Protocol (SIP) [3] was originally developed for initiation of multimedia sessions. Internet multimedia, voice over IP, IP telephony, and SIP have become quite popular, both inside IETF and with other standards groups, and the applications of SIP have grown. One result of this popularity has been a continual flood of suggestions for SIP modifications and extensions. The task for IETF management of SIP has been to keep the protocol development focused on SIP's core strengths and the applications it does best.
IETFのセッション開始プロトコル（SIP）[3]は、もともとマルチメディアセッションの開始のために開発されました。インターネットマルチメディア、ボイスオーバーIP、IPテレフォニー、およびSIPは、IETF内および他の標準グループの両方で非常に人気があり、SIPのアプリケーションが成長しました。この人気の結果の1つは、SIP修正と拡張に関する提案の継続的な洪水です。SIPのIETF管理のタスクは、SIPのコア強度と最適なアプリケーションに焦点を当てたプロトコル開発を維持することでした。
The IETF SIP Working Group has been chartered to be the "owner" of the SIP protocol [3], as long as the working group exists. All changes or extensions to SIP must first exist as SIP Working Group documents. The SIP Working group is charged with being the guardian of the SIP protocol for the Internet, and therefore should only extend or change the SIP protocol when there are compelling reasons to do so.
IETF SIPワーキンググループは、ワーキンググループが存在する限り、SIPプロトコル[3]の「所有者」になるようにチャーターされています。SIPへのすべての変更または拡張機能は、最初にSIPワーキンググループドキュメントとして存在する必要があります。SIPワーキンググループは、インターネットのSIPプロトコルの保護者であることで告発されているため、説得力のある理由がある場合にのみ、SIPプロトコルを拡張または変更する必要があります。
Documents that must be handled by the SIP working group include new SIP methods, new SIP option tags, new response codes, and new standards track SIP headers. With the exception of "P-" headers described in Section 4.1, all SIP extensions must be standards track and must be developed in the IETF based upon requirements provided by the SIPPING Working Group.
SIPワーキンググループが処理する必要があるドキュメントには、新しいSIPメソッド、新しいSIPオプションタグ、新しい応答コード、および新しい標準がSIPヘッダーを追跡する必要があります。セクション4.1で説明されている「P-」ヘッダーを除き、すべてのSIP拡張機能は標準の追跡であり、Sippingワーキンググループが提供する要件に基づいてIETFで開発する必要があります。
IETF working groups do not live forever; typically, mailing lists continue after the working group is concluded. If the SIP Working Group has closed and no suitable replacement or follow-on working group is active, the Transport Area directors will the use the non-working group standards track document process (described in section 6.1.2 of RFC 2026--IETF Standards Process [2]) using the SIP and SIPPING mailing lists and designated experts from the SIP community for advice. The IETF will remain the home of extensions of SIP and the requirement of standards track action will remain as defined in the rest of this document. The rate of growth of extensions of any protocol in the IETF is hoped to be low.
IETFワーキンググループは永遠に生きていません。通常、ワーキンググループが終了した後、メーリングリストは継続します。SIPワーキンググループが閉鎖されており、適切な交換または後続のワーキンググループがアクティブでない場合、輸送エリアディレクターは、非労働グループ標準の追跡ドキュメントプロセスを使用します（RFC 2026-IITF Standardsのセクション6.1.2で説明されていますプロセス[2]）SIPを使用して、SIPコミュニティのメーリングリストと指定された専門家を使用してアドバイスを求めます。IETFはSIPの延長の本拠地であり、標準の追跡アクションの要件は、このドキュメントの残りの部分で定義されているとおりのままです。IETFのプロトコルの拡張の成長率は、低いことを望んでいます。
It is appropriate for any working group to develop SIP event packages [4], but the working group must have charter approval to do so. The IETF will also require (Individual) RFC publication for the registration of event packages developed outside the scope of an IETF working group. Requirements for publishing event packages are described in detail in Section 4.3.
ワーキンググループがSIPイベントパッケージ[4]を開発することは適切ですが、ワーキンググループはそうするためにチャーターの承認を持っている必要があります。IETFには、IETFワーキンググループの範囲外で開発されたイベントパッケージの登録には、（個人）RFC出版物が必要です。公開イベントパッケージの要件については、セクション4.3で詳しく説明しています。
The IETF Session Initiation Protocol Proposal Investigation (sipping) Working Group is chartered to be a filter in front of the SIP Working Group. This working group will investigate requirements for applications of SIP, some of which may lead to requests for extensions to SIP. These requirements may come from the community at large, or from individuals who are reporting the requirements as determined by another standards body. The SIPPING Working Group will also not live forever, with similar consideration to the sections above.
IETFセッション開始プロトコル提案調査（SIPTING）ワーキンググループは、SIPワーキンググループの前のフィルターになるようにチャーターされています。このワーキンググループは、SIPのアプリケーションの要件を調査しますが、その一部はSIPの拡張リクエストにつながる可能性があります。これらの要件は、コミュニティ全体、または別の基準機関によって決定された要件を報告している個人からもたらされる場合があります。すすり泣くワーキンググループも永遠に生きることはなく、上記のセクションと同様の考慮事項があります。
The SIPPING Working Group may determine: that these requirements can be satisfied by SIP without modifications, that the requirements are not sufficiently general to warrant a change to SIP, that the requirements justify a change to SIP, or that the requirements should be combined with other requirements to solve a more general problem or solve the same problem in a more flexible way.
すすり泣くワーキンググループは、これらの要件を変更せずにSIPによって満たすことができること、要件がSIPの変更を保証するのに十分な一般ではないこと、要件がSIPの変更を正当化する、または要件を他のものと組み合わせる必要があることを決定する場合があります。より一般的な問題を解決したり、より柔軟な方法で同じ問題を解決するための要件。
Because the SIP protocol gets so much attention, some application designers may want to use it just because it is there, such as for controlling household appliances. SIPPING should act as a filter, accepting only requirements which play to the best strengths of SIP, such as realtime presence.
SIPプロトコルは非常に注目されているため、一部のアプリケーションデザイナーは、家電製品を制御するなど、そこにあるからといってそれを使用したいと思うかもしれません。すすりながら、フィルターとして機能し、リアルタイムの存在感など、SIPの最良の強みで再生する要件のみを受け入れる必要があります。
When the SIPPING working group decides on a set of requirements, it forwards them to the SIP working group. The SIPPING Working Group may also document usage or applications of SIP which do not require any protocol extensions.
飲み物のワーキンググループが一連の要件を決定すると、SIPワーキンググループに転送します。すすり泣くワーキンググループは、プロトコル拡張機能を必要としないSIPの使用またはアプリケーションを文書化することもできます。
The SIPPING working group also acts as a filter for proposed event packages as described in Section 4.3.
すすり泣くワーキンググループは、セクション4.3で説明されているように、提案されたイベントパッケージのフィルターとしても機能します。
Anyone who thinks that the existing SIP protocol is applicable to their application, yet not sufficient for their task must write an individual Internet-Draft explaining the problem they are trying to solve, why SIP is the applicable protocol, and why the existing SIP protocol will not work. The Internet-Draft must include a detailed set of requirements (distinct from solutions) that SIP would need to meet to solve the particular problem. The Internet-Draft must also describe in detail any security issues that arise from meeting those requirements. After the Internet-Draft is published, the authors should send a note to the SIPPING Working Group mailing list to start discussion on the Internet-Draft.
既存のSIPプロトコルがアプリケーションに適用可能であると考えている人は誰でも、タスクに十分ではないが、彼らが解決しようとしている問題、SIPが適用可能なプロトコルである理由、および既存のSIPプロトコルがなぜあるのかを説明する個々のインターネットドラフトを書く必要がありますうまくいかない。インターネットドラフトには、特定の問題を解決するためにSIPが満たす必要がある詳細な要件（ソリューションとは異なる）を含める必要があります。また、インターネットドラフトは、これらの要件を満たすことから生じるセキュリティの問題を詳細に説明する必要があります。インターネットドラフトが公開された後、著者は、インターネットドラフトに関する議論を開始するために、すすり回すワーキンググループメーリングリストにメモを送信する必要があります。
The SIPPING working group chairs, in conjunction with the Transport Area Directors, will determine if the particular problems raised in the requirements Internet-Draft warrants being added to the SIPPING charter based on the mailing list discussion. The SIPPING working group should consider whether the requirements can be merged with other requirements from other applications, and refine the ID accordingly.
輸送エリアのディレクターと連携して、ワーキンググループの椅子をすすりながら、メーリングリストの議論に基づいて、インターネットドラフトがすすり屋に追加された要件で提起された特定の問題が令状に追加されるかどうかを判断します。すすり泣くワーキンググループは、要件を他のアプリケーションの他の要件と統合できるかどうかを検討し、それに応じてIDを改良する必要があります。
If the chairs and the ADs both feel that the particular new problems should be added to the SIPPING Working Group charter, then the ADs will present the proposed SIPPING charter modifications to the IESG and IAB, in accordance with the usual process for charter expansion. If the IESG (with IAB advice) approves of the charter changes, the SIPPING working group can then work on the problems described in the Internet-Draft.
椅子と広告がどちらも特定の新しい問題をすすり込むワーキンググループチャーターに追加する必要があると感じた場合、広告は、通常のチャーター拡張のプロセスに従って、提案されたチャーターの変更をIESGとIABに提示します。IESG（IABアドバイスを含む）がチャーターの変更を承認した場合、すすりながらワーキンググループは、インターネットドラフトで説明されている問題に取り組むことができます。
In a separate Internet-Draft, the authors may describe a set of changes to SIP that would meet the requirements. The Internet-Draft would then be passed to the SIP working group for consideration (if warranted). The SIP working group is not required to adopt the proposed solution from this additional Internet-Draft.
別のインターネットドラフトでは、著者は、要件を満たすSIPの一連の変更を説明する場合があります。インターネットドラフトは、検討のためにSIPワーキンググループに渡されます（保証されている場合）。SIPワーキンググループは、この追加のインターネットドラフトから提案されたソリューションを採用する必要はありません。
The SIPPING working group may also evaluate such proposals for extensions if the requirements are judged to be appropriate to SIP, but are not sufficiently general for standards track activity. The SIPPING working group will attempt to determine if the new proposal meets the requirements for publication as a "P-" header, as described in Section 4.1, within a specific scope of applicability.
すすり泣くワーキンググループは、要件がSIPに適切であると判断されたが、標準追跡活動には十分に一般的ではない場合、拡張のこのような提案を評価することもできます。すすり泣くワーキンググループは、新しい提案が、セクション4.1で説明されているように、特定の適用範囲内で「P-」ヘッダーとしての出版要件を満たしているかどうかを判断しようとします。
The Transport ADs may, on a case by case basis, support a process in which the requirements analysis is implicit and the SIP working group requests the addition of a charter item for an extension without a full SIPPING process as described. This will be the exception.
輸送広告は、ケースバイケースで、要件分析が暗黙的であるプロセスをサポートし、SIPワーキンググループは、記載されているように完全なすすりのプロセスなしで拡張機能のチャーターアイテムの追加を要求する場合があります。これが例外になります。
With respect to standardization, this process means that SIP extensions come only from the IETF, the body that created SIP. The IETF will not publish a SIP extension RFC outside of the processes described here.
標準化に関しては、このプロセスは、SIP拡張がSIPを作成した本体であるIETFからのみ発生することを意味します。IETFは、ここで説明するプロセスの外部でSIP拡張RFCを公開しません。
The SIP Working Group is required to protect the architectural integrity of SIP and must not add features that do not have general use beyond the specific case. Also, they must not add features just to make a particular function more efficient at the expense of simplicity or robustness.
SIPワーキンググループは、SIPのアーキテクチャの完全性を保護するために必要であり、特定のケースを超えて一般的に使用されていない機能を追加してはなりません。また、特定の機能を単純さや堅牢性を犠牲にしてより効率的にするためだけに機能を追加してはなりません。
Some working groups besides SIPPING generate requirements for SIP solutions and/or extensions as well. At the time this document was written, these include SIP for Instant Messaging and Presence Leveraging Extensions (simple), Service in the PSTN/IN Requesting InTernet Service (spirits), and Telephone Number Mapping (enum).
すすりする以外の一部のワーキンググループは、SIPソリューションや拡張機能の要件も生成します。このドキュメントが書かれた時点で、これらには、インターネットサービス（Spirits）の要求におけるPSTN/のサービス（シンプル）のサービスを活用するインスタントメッセージと存在感のためのSIPが含まれます。
In an idealized protocol model, extensible design would be self-contained, and it would be inherent that new extensions and new headers would naturally have an architectural coherence with the original protocol.
理想化されたプロトコルモデルでは、拡張可能な設計は自己完結型であり、新しい拡張機能と新しいヘッダーが自然に元のプロトコルとのアーキテクチャの一貫性を持つことが固有です。
However, this idealized vision has not been attained in the world of standards track protocols. While, interoperability implications can be addressed by capabilities negotiation rules, the effects of adding features that overlap, or that deal with a point solution and are not general, are much harder to control with rules. Therefore, the Transport Area calls for architectural guardianship and application of Occam's Razor by the SIP Working Group.
ただし、この理想化されたビジョンは、標準の追跡プロトコルの世界では達成されていません。一方、相互運用性の影響は、機能交渉規則に対処できますが、重複する、またはポイントソリューションに対処し、一般的ではない機能を追加することの効果は、ルールで制御するのがはるかに困難です。したがって、輸送エリアでは、SIPワーキンググループによるOccam's Razorの建築の後見と適用が求められています。
In keeping with the IETF tradition of "running code and rough consensus", it is valid to allow for the development of SIP extensions that are either not ready for standards track, but might be understood for that role after some running code, or are private or proprietary in nature, because a characteristic motivating them is usage that is known not to fit the Internet architecture for SIP. We call these "P-" headers, for "preliminary", "private", or "proprietary".
「コードと大まかなコンセンサスを実行する」というIETFの伝統に沿って、標準トラックの準備ができていないが、実行中のコードの後にその役割について理解されるか、プライベートであるかのどちらかであるか、またはプライベートであるSIP拡張機能の開発を可能にすることが有効ですまたは本質的に独自のものであるため、それらを動機付ける特徴は、SIPのインターネットアーキテクチャに適合しないことが知られている使用法です。これらの「P-」ヘッダーを、「予備的な」、「プライベート」、または「独自」と呼びます。
There are two key issues to consider with respect to keeping the "P-" header extension space "safe":
「P-」ヘッダー拡張スペースを「安全」に保つことに関して、考慮すべき重要な問題が2つあります。
1. Clearly indicating the unarchitected or not-yet understood nature of the extension.
1. 拡張の非公開または未知の性質を明確に示しています。
2. Preventing identity conflicts between extensions.
2. エクステンション間のアイデンティティの競合を防ぐ。
4.1 Indicating a "P-" Header:
4.1 「P-」ヘッダーを示す：
Use of an "X-" prefix on textual identifiers has been widely used to indicate experimental extensions in other protocols. This approach is applied in modified form here by use of a "P-" header extension. However, there are a number of stronger constraints for "P-" headers, including documentation that get Expert and IESG review, and other SIP protocol criteria described below.
テキスト識別子での「X-」プレフィックスの使用は、他のプロトコルの実験的拡張を示すために広く使用されています。このアプローチは、「P-」ヘッダー拡張機能を使用することにより、ここで修正された形式で適用されます。ただし、専門家やIESGレビューを取得するドキュメントや、以下で説明するその他のSIPプロトコル基準など、「P-」ヘッダーには多くの強力な制約があります。
Informational SIP Headers can be registered as "P-" headers if all of the following conditions are met:
情報SIPヘッダーは、次のすべての条件が満たされている場合、「P-」ヘッダーとして登録できます。
1. A designated expert (as defined in RFC 2434 [4]) MUST review the proposal for applicability to SIP and conformance to these guidelines. The Expert Reviewer will send email to the Transport Area Directors on this determination. The expert reviewer can cite one or more of the guidelines that haven't been followed in his/her opinion.
1. 指定された専門家（RFC 2434 [4]で定義されている）は、これらのガイドラインを飲み、適合するための適用性の提案を確認する必要があります。専門家のレビュアーは、この決意について輸送エリアディレクターに電子メールを送信します。専門家のレビュアーは、彼/彼女の意見に従っていないガイドラインの1つ以上を引用できます。
2. The proposed extension MUST NOT define SIP option tags, response codes, or methods.
2. 提案された拡張機能は、SIPオプションタグ、応答コード、またはメソッドを定義してはなりません。
3. The function of the proposed header MUST NOT overlap with current or planned chartered extensions.
3. 提案されたヘッダーの機能は、現在または計画されたチャーターされた拡張機能と重複してはなりません。
4. The proposed header MUST be of a purely informational nature, and MUST NOT significantly change the behavior of SIP entities which support it. Headers which merely provide additional information pertinent to a request or a response are acceptable. If the headers redefine or contradict normative behavior defined in standards track SIP specifications, that is what is meant by significantly different behavior.
4. 提案されたヘッダーは、純粋に情報的な性質でなければならず、それをサポートするSIPエンティティの動作を大幅に変えてはなりません。単にリクエストまたは応答に関連する追加情報を提供するヘッダーは受け入れられます。ヘッダーが標準で定義されている規範的な動作を再定義または矛盾する場合、SIP仕様を追跡する場合、それは著しく異なる動作によって意味されます。
5. The proposed header MUST NOT undermine SIP security in any sense. The Internet Draft proposing the new header MUST address security issues in detail as if it were a Standards Track document. Note that, if the intended application scenario makes certain assumptions regarding security, the security considerations only need to meet the intended application scenario rather than the general Internet case. In any case, security issues need to be discussed for arbitrary usage scenarios (including the general Internet case).
5. 提案されたヘッダーは、いかなる意味でもSIPセキュリティを損なってはなりません。新しいヘッダーを提案するインターネット草案は、標準トラックドキュメントであるかのように、セキュリティの問題に詳細に対処する必要があります。意図したアプリケーションシナリオがセキュリティに関する特定の仮定を行っている場合、セキュリティ上の考慮事項は、一般的なインターネットケースではなく、意図したアプリケーションシナリオを満たすだけであることに注意してください。いずれにせよ、任意の使用シナリオ（一般的なインターネットケースを含む）については、セキュリティの問題について議論する必要があります。
6. The proposed header MUST be clearly documented in an (Individual or Working Group) Informational RFC, and registered with IANA.
6. 提案されたヘッダーは、（個人またはワーキンググループ）情報RFCに明確に文書化され、IANAに登録する必要があります。
7. An applicability statement in the Informational RFC MUST clearly document the useful scope of the proposal, and explain its limitations and why it is not suitable for the general use of SIP in the Internet.
7. 情報情報RFCの適用声明は、提案の有用な範囲を明確に文書化し、その制限と、インターネットでのSIPの一般的な使用に適していない理由を説明する必要があります。
Any implementation of a "P-" header (meaning "not specified by a standards-track RFC issued through the SIP Working Group") MUST include a "P-" prefix on the header, as in "P-Headername". Note that "P-" extensions are not IETF standards of any kind, and MUST NOT be required by any production deployment considered compliant to IETF specifications. Specifically, implementations are only SIP compliant if a) they fall back to baseline behavior when they ignore all P-headers, and b) when using P- headers they do not contradict any normative behavior.
「P-」ヘッダーの実装（「SIPワーキンググループを通じて発行された標準トラックRFCによって指定されていないことを意味する」）には、「P-Headername」のように、ヘッダーに「P-」プレフィックスを含める必要があります。「P-」拡張機能はいかなる種類のIETF標準ではなく、IETF仕様に準拠していると見なされる生産展開では義務付けられてはならないことに注意してください。具体的には、a）すべてのPヘッダーを無視したときにベースラインの動作に戻る場合にのみ、実装はSIPに準拠します。
4.2 Preventing Identity Conflicts Between P-Extensions:
4.2 P拡張の間のアイデンティティの対立を防ぐ：
In order to prevent identity conflicts between P-headers, this document provides an IANA process (See: "IANA Considerations" below) to register the P-headers. The handling of unknown P-headers is to ignore them, however, section 4.1 is to be taken seriously, and users of P-headers will have best results with adherence. All implemented P-headers SHOULD meet the P-Header requirements in 4.1. Any P-header used outside of a very restricted research or teaching environment (such as a student lab on implementing extensions) MUST meet those requirements and MUST be documented in an RFC and be IANA registered. IANA registration is permitted when the IESG approves the internet-draft.
Pヘーダー間のアイデンティティの競合を防ぐために、このドキュメントは、Pヘッダーを登録するためのIANAプロセス（以下の「IANAの考慮事項」を参照）を提供します。未知のPヘッダーの取り扱いはそれらを無視することですが、セクション4.1は真剣に受け止められ、Pヘッダーのユーザーは順守を伴う最良の結果をもたらします。実装されたすべてのPヘッダーは、4.1のPヘッダー要件を満たす必要があります。非常に制限された研究や教育環境の外で使用されるPヘッダー（拡張機能の実装に関する学生研究所など）は、それらの要件を満たし、RFCで文書化され、登録されなければなりません。IESGがインターネットドラフトを承認した場合、IANA登録は許可されます。
events [4] defines two different types of event packages: normal event packages, and event template-packages. Event template-packages can only be created and registered by the publication of a Standards Track RFC (from an IETF Working Group). Normal event packages can be created and registered by the publication of any Working Group RFC (Informational, Standards Track, Experimental), provided that the RFC is a chartered working group item.
イベント[4]は、通常のイベントパッケージとイベントテンプレートパッケージの2つの異なるタイプのイベントパッケージを定義します。イベントテンプレートパッケージは、標準トラックRFC（IETFワーキンググループから）の公開によってのみ作成および登録できます。通常のイベントパッケージは、RFCがチャーターされたワーキンググループアイテムである場合、ワーキンググループRFC（情報、標準トラック、実験的）の公開によって作成および登録できます。
Individuals may also wish to publish SIP Event packages. Individual proposals for registration of a SIP event package MUST first be published as Internet-drafts for review by the SIPPING Working Group, or the working group, mailing list, or expert designated by the Transport Area Directors if the SIPPING Working Group has closed. Proposals should include a strong motivational section, a thorough description of the proposed syntax and semantics, event package considerations, security considerations, and examples of usage. The author should submit his or her proposal as an individual Internet-Draft, and post an announcement to the working group mailing list to begin discussion. The SIPPING Working Group will determine if the proposed package is a) an inappropriate usage of SIP, b) applicable to SIP but not sufficiently interesting, general, or in-scope to adopt as a working group effort, c) contrary to similar work planned in the Working Group, or d) should be adopted as or merged with chartered work.
個人は、SIPイベントパッケージを公開することもできます。SIPイベントパッケージの登録に関する個別の提案は、最初にワーキンググループ、またはワーキンググループ、メーリングリスト、または輸送エリアディレクターが指定したワーキンググループ、メーリングリスト、またはすすり泣きワーキンググループが閉鎖した場合に指定された専門家によるインターネットドラフトとして公開する必要があります。提案には、強力な動機付けセクション、提案された構文とセマンティクスの徹底的な説明、イベントパッケージの考慮事項、セキュリティ上の考慮事項、および使用例が含まれます。著者は、個々のインターネットドラフトとして提案を提出し、議論を開始するためにワーキンググループメーリングリストに発表を投稿する必要があります。すすり泣くワーキンググループは、提案されたパッケージがa）SIPの不適切な使用法、b）SIPに適用されるが、ワーキンググループの努力として採用するための十分に興味深い、一般的、またはスコープ内ではないかどうかを判断します。ワーキンググループ、またはd）は、チャーターされた作業としてまたは合併する必要があります。
The IETF requires (Individual) RFC publication for registration of event packages developed outside the scope of an IETF working group, according to the following guidelines:
IETFには、次のガイドラインに従って、IETFワーキンググループの範囲外で開発されたイベントパッケージの登録のために（個人）RFC出版物が必要です。
1. A designated expert (as defined in RFC 2434 [4]) MUST review the proposal for applicability to SIP and conformance with these guidelines. The Expert Reviewer will send email to the IESG on this determination. The expert reviewer can cite one or more of the guidelines that have not been followed in his/her opinion.
1. 指定された専門家（RFC 2434 [4]で定義されている）は、これらのガイドラインを飲んで適合する適用性の提案を確認する必要があります。専門家のレビュアーは、この決定についてIESGに電子メールを送信します。専門家のレビュアーは、彼/彼女の意見に従っていないガイドラインの1つ以上を引用できます。
2. The proposed extension MUST NOT define an event template-package.
2. 提案された拡張機能は、イベントテンプレートパッケージを定義してはなりません。
3. The function of the proposed package MUST NOT overlap with current or planned chartered packages.
3. 提案されたパッケージの機能は、現在または計画されたチャーターされたパッケージと重複してはなりません。
4. The event package MUST NOT redefine or contradict the normative behavior of SIP events [4], SIP [3], or related standards track extensions.
4. イベントパッケージは、SIPイベント[4]、SIP [3]、または関連する標準の規範的な動作を再定義または矛盾してはなりません。
5. The proposed package MUST NOT undermine SIP security in any sense. The Internet Draft proposing the new package MUST address security issues in detail as if it were a Standards Track document. Security issues need to be discussed for arbitrary usage scenarios (including the general Internet case).
5. 提案されたパッケージは、いかなる意味でもSIPセキュリティを損なってはなりません。新しいパッケージを提案するインターネットドラフトは、標準トラックドキュメントであるかのように、セキュリティの問題に詳細に対処する必要があります。任意の使用シナリオ（一般的なインターネットケースを含む）については、セキュリティの問題について議論する必要があります。
6. The proposed package MUST be clearly documented in an (Individual) Informational RFC, and registered with IANA. The package MUST document all the package considerations required in Section 5 of SIP events [4].
6. 提案されたパッケージは、（個別の）情報RFCに明確に文書化され、IANAに登録する必要があります。パッケージは、SIPイベントのセクション5に必要なすべてのパッケージに関する考慮事項を文書化する必要があります[4]。
7. If determined by the expert reviewer or the chairs or ADs of the SIPPING WG, an applicability statement in the Informational RFC MUST clearly document the useful scope of the proposal, and explain its limitations and why it is not suitable for the general use of SIP in the Internet.
7. 専門家のレビュアーまたはSipping WGの椅子または広告によって決定された場合、情報情報RFCの適用声明は、提案の有用な範囲を明確に文書化し、その限界とSIPの一般的な使用に適していない理由を説明する必要があります。インターネット。
Complexity and indeterminate or hard to define protocol behavior, depending on which of many extensions operate, is a fine breeding ground for security flaws.
多くの拡張機能が動作するものに応じて、複雑さと不確定性または定義するのが困難であるため、セキュリティの欠陥の細かい繁殖地です。
All Internet-Drafts that present new requirements for SIP must include a discussion of the security requirements and implications inherent in the proposal. All RFCs that modify or extend SIP must show that they have adequate security and do not worsen SIP's existing security considerations.
SIPの新しい要件を提示するすべてのインターネットドラフトには、提案に固有のセキュリティ要件と意味の議論を含める必要があります。SIPを変更または拡張するすべてのRFCは、適切なセキュリティがあり、SIPの既存のセキュリティに関する考慮事項を悪化させないことを示す必要があります。
RFC 3261 [3] directs the Internet Assigned Numbers Authority (IANA) to establish a registry for SIP method names, a registry for SIP option tags, and a registry for SIP response codes, and to amend the practices used for the existing registry for SIP headers.
RFC 3261 [3]は、インターネットに割り当てられた番号局（IANA）に、SIPメソッド名のレジストリ、SIPオプションタグのレジストリ、SIP応答コードのレジストリを確立するように指示し、SIPの既存のレジストリに使用されるプラクティスを修正するよう指示します。ヘッダー。
With the exception of P-headers, entries go into these registries only by approval of an Internet-Draft as a standards track RFC.
Pヘッダーを除き、エントリは、標準ドラフトを標準ドラフトを追跡するRFCとしての承認によってのみ、これらのレジストリに入ります。
Each RFC shall include an IANA Considerations section which directs IANA to create appropriate registrations. Registration shall be done at the time the IESG announces its approval of the draft containing the registration requests.
各RFCには、IANAに適切な登録を作成するよう指示するIANAの考慮事項セクションが含まれます。登録は、IESGが登録要求を含むドラフトの承認を発表したときに行われるものとします。
Standard headers and messages MUST NOT begin with the leading characters "P-".
標準のヘッダーとメッセージは、主要なキャラクター「P-」から始めてはなりません。
"P-" header names MUST begin with the leading characters "P-". No "P-" header which conflicts with (would, without the "P-" prefix have the same name as) an existing standards track header is allowed. Each registration of a "P-" header will also reserve the name of the header as it would appear without the "P-" prefix. However, the reserved name without the "P-" will not explicitly appear in the registry. It will only appear if there is a later standards track document (which is unlikely in most cases!). Please do not accept the registration of IANA-Greeting when you see: P-IANA-Greeting. P-header's "reserved standard names" MUST NOT be used in a SIP implementation prior to standardization of the header.
「P-」ヘッダー名は、主要な文字「P-」から始まる必要があります。既存の標準トラックヘッダーが許可されている（「P-」プレフィックスが同じ名前と同じ名前を持たない（「P-」プレフィックスなしで競合する「P-」ヘッダーは許可されません。「P-」ヘッダーの各登録は、「P-」プレフィックスなしで表示されるヘッダーの名前も予約します。ただし、「P-」のない予約済みの名前は、レジストリに明示的に表示されません。後の標準トラックドキュメントがある場合にのみ表示されます（ほとんどの場合はありそうもない！）。表示されているときは、IANA-Greetingの登録を受け付けないでください：p-aiana-greeting。P-Headerの「予約標準名」は、ヘッダーの標準化前にSIP実装で使用してはなりません。
Short forms of headers MUST only be assigned to standards track headers. In other words, P-headers MUST NOT have short forms.
短い形式のヘッダーは、標準トラックヘッダーにのみ割り当てられる必要があります。言い換えれば、Pヘッダーは短い形を持っていてはなりません。
Similarly, RFC 3265 [4] directs the IANA to establish a registry for SIP event packages and SIP event template packages. For event template packages, entries go into this registry only by approval of a draft for standards track RFC. For ordinary event packages, entries go into this registry only by approval of a draft for RFC (of any type). In either case, the IESG announcement of approval authorizes IANA to make the registration.
同様に、RFC 3265 [4]は、SIPイベントパッケージとSIPイベントテンプレートパッケージのレジストリを確立するようにIANAに指示します。イベントテンプレートパッケージの場合、エントリは標準トラックRFCのドラフトの承認によってのみこのレジストリに入ります。通常のイベントパッケージの場合、エントリは（あらゆるタイプの）RFCのドラフトの承認によってのみこのレジストリに入ります。いずれの場合も、承認のIESG発表は、IANAが登録を行うことを許可しています。
The Transport ADs thank our IESG and IAB colleagues (especially Randy Bush, Harald Alvestrand, John Klensin, Leslie Daigle, Patrik Faltstrom, and Ned Freed) for valuable discussions of extensibility issues in a wide range of protocols, including those that our area brings forward and others. Thanks to the many members of the SIP community engaged in interesting dialogue about this document as well; Jonathan Rosenberg and Jon Peterson gave us useful reviews. Thanks also to Henning Schulzrinne and William Marshall.
トランスポート広告は、IESGとIABの同僚（特にランディブッシュ、ハラルドアルベスランド、ジョンクレンシン、レスリーデイグル、パトリックファルトストローム、ネッドフリード）に感謝します。その他。SIPコミュニティの多くのメンバーがこのドキュメントについて興味深い対話にも関与していることに感謝します。ジョナサン・ローゼンバーグとジョン・ピーターソンは、私たちに有用なレビューをくれました。ヘニング・シュルツリンとウィリアム・マーシャルにも感謝します。
[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] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[2] Bradner、S。、「インターネット標準プロセス - リビジョン3」、BCP 9、RFC 2026、1996年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：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[4] Roach, A., "Session Initiation Protocol (SIP) - Specific Event Notification", RFC 3265, June 2002.
[4] Roach、A。、「セッション開始プロトコル（SIP） - 特定のイベント通知」、RFC 3265、2002年6月。
Allison Mankin Bell Labs, Lucent Corporation
アリソンマンキンベルラボ、ルーセントコーポレーション
EMail: mankin@psg.com
Scott Bradner Harvard University
スコット・ブラッドナー・ハーバード大学
EMail: sob@harvard.edu
Rohan Mahy Cisco
Rohan Mahy Cisco
EMail: rohan@cisco.com
Dean Willis dynamicsoft
ディーン・ウィリス・ダイナミクスソフト
EMail: dean.willis@softarmor.com
Brian Rosen Marconi
ブライアン・ローゼン・マルコーニ
EMail: brian.rosen@marconi.com
Joerg Ott ipDialog / Uni Bremen TZI
Joerg Ott Ipdialog / Uni Bremen Tzi
EMail: jo@ipdialog.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。