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)
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 (2002). All Rights Reserved.
著作権（C）インターネット協会（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およびグループチェアワーキングセッション開始の提案調査（SIPPING）と一緒に、SIPの変更や拡張のための提案を提供しています。
In this document, the key words "MAY", "MUST, "MUST NOT", "SHOULD", and "SHOULD NOT", are to be interpreted as described in Keywords [1].
この文書に記載されている、キーワード "MAY"、「MUST、 "MUST NOTキーワードに記載されているように、"、 "SHOULD"、および "the" はならない[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のアプリケーションでは、成長しています。この人気の一つの結果は、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ワーキンググループ[3]は、ワーキンググループが存在する限り、SIPプロトコルの「所有者」であることが公認されています。 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のセクション6.1.2に記述された文書処理（使用追跡する - IETF標準化プロセス[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のセッション開始プロトコルの提案調査（飲み）ワーキンググループはSIPワーキンググループの前でフィルタするチャーターされます。このワーキンググループは、SIPへの拡張のための要求につながる可能性があり、そのいくつかのSIPのアプリケーションの要件を調査します。これらの要件は、大規模で社会から、または他の標準化団体によって決定される要件を報告している個人から来るかもしれません。 SIPPINGワーキンググループはまた、上記のセクションに似考慮して、永遠に生きることはありません。
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.
SIPPINGワーキンググループが決定することができる：これらの要件は要件は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プロトコルはあまり注目されているので、いくつかのアプリケーション設計者は、それがあるので、このような家電製品を制御するためとして、それを使用することをお勧めします。 SIPPINGは、このようなリアルタイムの存在のような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.
SIPPINGワーキンググループは、要件のセットを決定するとき、それはSIPワーキンググループに転送します。 SIPPINGワーキンググループはまた、任意のプロトコル拡張を必要としない用途やSIPのアプリケーションを文書化することがあります。
The SIPPING working group also acts as a filter for proposed event packages as described in Section 4.3.
4.3節で説明したようにSIPPINGワーキンググループはまた、提案イベントパッケージのためのフィルタとして機能します。
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は、特定の問題を解決するために満たすために必要となる要件（ソリューションは異なる）の詳細なセットを含める必要があります。インターネットドラフトはまた、詳細にこれらの要件を満たすことに起因するいかなるセキュリティ問題を記述しなければなりません。インターネットドラフトが公開された後、著者はインターネットドラフトでの議論を開始するSIPPINGワーキンググループのメーリングリストにメモを送信する必要があります。
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.
要件インターネットドラフトのワラントで提起された特定の問題は、メーリングリストの議論に基づいてSIPPING憲章に追加されている場合SIPPINGワーキンググループの議長は、交通エリアの取締役と連携して、決定します。 SIPPINGワーキンググループは、要件は、他のアプリケーションから他の要件と合併することができるかどうかを検討し、それに応じて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.
椅子や広告の両方が、特定の新たな問題がSIPPINGワーキンググループのチャーターに追加する必要があると感じた場合は、広告がチャーター拡張のための通常のプロセスに従って、IESGとIABに提案SIPPINGチャーターの修正を発表します。 （IABアドバイス付き）IESGはチャーターの変更を承認する場合は、SIPPINGワーキンググループは、インターネットドラフトに記述の問題に取り組むことができます。
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.
SIPPINGワーキンググループはまた、要件はSIPに適切であると判断された場合の拡張のために、このような提案を評価しますが、標準化トラックの活動のために十分に一般的ではありませんがあります。 SIPPINGワーキンググループは、セクション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ワーキンググループは、完全なSIPPING処理無し拡張ためのチャーター項目の追加を要求するプロセスをサポートすることができます。これは例外となります。
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の拡張は、IETF、SIPを作成し、本体からのみ来ることを意味します。 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ソリューションおよび/または拡張するための要件を生成するSIPPING以外にもいくつかのワーキンググループ。この文書が書かれた時点では、これらは、インスタントメッセージングとプレゼンスの活用拡張機能（シンプル）のためのSIP、PSTNでのサービス/インターネット・サービス（霊）を要求する際に、および電話番号のマッピング（列挙型）が含まれます。
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ワーキンググループによる建築後見とオッカムの剃刀のアプリケーションのために呼び出します。
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-」ヘッダ拡張スペースを維持に関して考慮すべき二つの重要な問題があります。
1. Clearly indicating the unarchitected or not-yet understood nature of the extension.
1.明らかに、拡張のアンアーキテクトまたは未理解性質を示します。
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]）これらのガイドラインにSIPとの適合性への適用のための提案を検討しなければなりません。エキスパートレビューこの決意に交通エリア取締役に電子メールを送信します。専門家のレビューアは、彼/彼女の意見に従っていませんガイドラインの一つ以上を挙げることができます。
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.
前記提案されたヘッダは、明らかに（個人または作業グループ）の情報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-ヘッダ名」のように、ヘッダの「P-」接頭辞を含まなければなりません。 「P-」の拡張機能は、あらゆる種類のIETF標準ではない、とIETF仕様に準拠したと考えるあらゆる生産の展開によって必要とされてはならないことに注意してください。具体的には、それらは全てP-ヘッダを無視する場合A）は、バック基線挙動に落ちる場合の実装にのみ準拠SIPされ、P-ヘッダを使用する場合B）彼らは、任意の規範的動作は矛盾しません。
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に文書化されなければならないとIANAが登録されます。 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つのイベントパッケージの異なるタイプを定義します。イベントテンプレートパッケージは作成され、（IETFワーキンググループからの）標準化過程RFCの公表によって登録することができます。通常のイベントパッケージは任意のワーキンググループ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イベントパッケージを発行することを望むかもしれません。 SIPPINGワーキンググループが閉じている場合は、SIPイベントパッケージの登録のための個々の提案は最初SIPPINGワーキンググループによる検討のためのインターネット・ドラフト、またはトランスポートエリアディレクターによって指定されたワーキンググループ、メーリングリスト、または専門家として公開されなければなりません。提案は強い動機付けの部分、提案構文と意味、イベントパッケージの考慮事項、セキュリティ上の考慮事項の完全な説明、および使用例を含める必要があります。著者は、個々のインターネットドラフトとして彼または彼女の提案を提出し、議論を開始するためにワーキンググループのメーリングリストに告知を掲示する必要があります。提案されたパッケージは、SIPのa）の不適切な使い方であればSIPPINGワーキンググループは、計画された同様の仕事にc）に反して、ワーキンググループの取り組みとして採用することを十分に、興味深い一般的、またはスコープ内の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]）のガイドラインとSIPとの適合に適用するための提案を確認しなければなりません。エキスパートレビューがこの決定にIESGに電子メールを送信します。専門家のレビューアは、彼/彼女の意見に従っていませんガイドラインの一つ以上を挙げることができます。
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].
前記提案されたパッケージは、明らかに（個人）情報のRFCに記載され、IANAに登録されなければなりません。パッケージには、SIPイベント[4]のセクション5に必要なすべてのパッケージの考慮事項を文書化しなければなりません。
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-挨拶を：あなたが見たときにIANA-挨拶の登録を受け付けないようにしてください。 P-ヘッダの「予約済み標準名」先行ヘッダの標準化に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の同僚（特にランディブッシュ、ハラルドAlvestrand、ジョン・クレンシン、レスリーDaigle氏、パトリックFaltstrom、およびネッドフリードを）感謝しますその他。 SIPコミュニティの多くのメンバーのおかげで、同様にこの文書についての興味深い対話に従事。ジョナサン・ローゼンバーグとジョン・ピーターソンは、私たちに有益なレビューを与えました。また、ヘニングSchulzrinneとし、ウィリアム・マーシャルに感謝します。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[2]ブラドナーの、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル"、 RFC 3261、2002年6月。
[4] Roach, A., "Session Initiation Protocol (SIP) - Specific Event Notification", RFC 3265, June 2002.
[4]ローチ、A.、 "セッション開始プロトコル（SIP） - 特定のイベント通知"、RFC 3265、2002年6月。
Allison Mankin Bell Labs, Lucent Corporation
アリソンマンキンベル研究所、ルーセント株式会社
EMail: mankin@psg.com
メールアドレス：mankin@psg.com
Scott Bradner Harvard University
スコット・ブラッドナーハーバード大学
EMail: sob@harvard.edu
メールアドレス：sob@harvard.edu
Rohan Mahy Cisco
ロハンマーイシスコ
EMail: rohan@cisco.com
メールアドレス：rohan@cisco.com
Dean Willis dynamicsoft
ディーンウィリスdynamicsoft
EMail: dean.willis@softarmor.com
メールアドレス：dean.willis@softarmor.com
Brian Rosen Marconi
ブライアン・ローゼンマルコーニ
EMail: brian.rosen@marconi.com
メールアドレス：brian.rosen@marconi.com
Joerg Ott ipDialog / Uni Bremen TZI
イェルク・オットipDialog /ユニブレーメンTZI
EMail: jo@ipdialog.com
メールアドレス：jo@ipdialog.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。