Internet Engineering Task Force (IETF) J. Peterson
Request for Comments: 5727 NeuStar, Inc.
BCP: 67 C. Jennings
Obsoletes: 3427 Cisco Systems
Updates: 3265, 3969 R. Sparks
Category: Best Current Practice Tekelec
ISSN: 2070-1721 March 2010
Change Process for the Session Initiation Protocol (SIP)
and the Real-time Applications and Infrastructure Area
Abstract
抽象
This memo documents a process intended to organize the future development of the Session Initiation Protocol (SIP) and related work in the Real-time Applications and Infrastructure (RAI) Area. As the environments in which SIP is deployed grow more numerous and diverse, modifying or extending SIP in certain ways may threaten the interoperability and security of the protocol; however, the IETF process must also cater to the realities of existing deployments and serve the needs of the implementers working with SIP. This document therefore defines the functions of two long-lived working groups in the RAI Area that are, respectively, responsible for the maintenance of the core SIP specifications and the development of new efforts to extend and apply work in this space. This document obsoletes RFC 3427.
このメモはリアルタイムアプリケーションとインフラストラクチャ（RAI）エリアでセッション開始プロトコル（SIP）の将来の発展および関連作業を整理することを目的とプロセスを説明します。 SIPは、特定の方法でSIPを修正又は延びる、より多数で多様な成長展開される環境は、プロトコルの相互運用性とセキュリティを脅かすことができるように。しかし、IETFプロセスは、既存の展開の現実に応えるとSIPを扱う実装者のニーズに応える必要があります。従って、この文書は、それぞれ、コアSIP仕様の維持と、このスペースでの作業を拡張して適用するための新しい取り組みの開発を担当しているRAIエリアに2つの長命のワーキンググループの関数を定義しています。この文書はRFC 3427を廃止します。
Status of This Memo
このメモのステータス
This memo documents an Internet Best Current Practice.
このメモはインターネット最も良い現在の練習を説明します。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 BCPの詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5727.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5727で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. History and Development . . . . . . . . . . . . . . . . . . . 3
1.1. The IETF SIPCORE Working Group . . . . . . . . . . . . . . 3
1.2. The IETF DISPATCH Working Group . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Introducing New Work to RAI . . . . . . . . . . . . . . . . . 6
4. Extensibility and Architecture . . . . . . . . . . . . . . . . 7
4.1. SIP Event Packages . . . . . . . . . . . . . . . . . . . . 9
5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7.1. Clarification of RFC 3969 . . . . . . . . . . . . . . . . 12
8. Overview of Changes to RFC 3427 . . . . . . . . . . . . . . . 12
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . . 13
The Session Initiation Protocol (SIP) [RFC3261] has grown well beyond its origins in Internet-based multimedia sessions and now enjoys widespread popularity in Voice-over-IP or IP telephony applications, both inside IETF and within other standards groups. One result of this popularity has been a continual flood of proposals for SIP modifications and extensions. The challenge for IETF management of SIP has been to preserve baseline interoperability across its many implementations
セッション開始プロトコル（SIP）[RFC3261]は、インターネットベースのマルチメディアセッション中にその起源をはるかに超えて成長し、今でIETF内や他の標準化グループ内の両方の、ボイスオーバーIPまたはIPテレフォニーアプリケーションで広く人気を享受しています。この人気の一つの結果は、SIPの変更や拡張のための提案の継続的な洪水となっています。 SIPのIETF管理のための課題は、その多くの実装で、ベースラインの相互運用性を維持してきました
In order to defend SIP against changes that might reduce interoperability, the working group chairs and Area Directors responsible for its management authored the SIP change process [RFC3427]. That document defined the role of the SIP and SIPPING Working Groups (WGs) in shepherding ongoing work on the SIP standard. It also defined ways that external working groups or bodies can define extensions intended for limited usage, especially through the "P-" header field mechanism.
相互運用性を減らす可能性がある変更に対してSIPを守るためには、その管理を担当するワーキンググループの議長とエリアの取締役はSIP変更処理[RFC3427]を執筆しています。その文書には、SIP標準に進行中の作業を牧におけるSIPとSIPPINGワーキンググループ（作業部会）の役割を定義しました。また、外部のワーキンググループや団体が、特に「P-」ヘッダフィールド機構を介して、限られた使用のために意図拡張を定義することができる方法を定義しました。
Over time, however, the management structure of RFC 3427 has demonstrated some limitations. The first and most significant of these concerns "P-" header fields. While "P-" header fields require expert review and IESG shepherding, in practice IETF oversight of these header fields is quite limited, and the value added by the IETF supervising their development remains unclear. More importantly, the presence of a "P-" in front of a header field name does nothing to prevent a popular header field from seeing deployment outside of the original "limited usage" it envisioned; a prominent example of this today is the P-Asserted-Identity (PAID) header field, described in RFC3325 [RFC3325].
時間が経つにつれて、しかし、RFC 3427の管理構造は、いくつかの制限を示しました。第一及びこれらの懸念「P-」ヘッダフィールドの最も重要な。 「P-」ヘッダフィールドは、専門家のレビューとIESGのシェパディングを必要としますが、これらのヘッダフィールドの練習IETFの監督にはかなり制限されており、IETFがその開発を監督することにより、付加価値は不明のまま。さらに重要なのは、ヘッダーフィールド名の前に「P-」の存在は、それが想定され、元の「限定された使用法」の外の展開を見てから人気のヘッダフィールドを防ぐために何もしません。この今日の顕著な例は、RFC3325 [RFC3325]に記載のP-アサート・アイデンティティ（PAID）ヘッダフィールドです。
Consequently, this document obsoletes RFC 3427 and describes a new structure for the management of deliverables in the Real-time Applications and Infrastructure Area.
したがって、この文書はRFC 3427を廃止し、リアルタイムアプリケーションとインフラストラクチャ地域における成果物の管理のための新しい構造を説明しています。
Historically, the IETF SIP Working Group (sip) was chartered to be the "owner" of the SIP protocol [RFC3261] for the duration of the working group. All changes or extensions to SIP were first required to exist as SIP Working Group documents. The SIP Working Group was charged with being the guardian of the SIP protocol for the Internet, and therefore was mandated only to extend or change the SIP protocol when there were compelling reasons to do so.
歴史的に、IETF SIPワーキンググループ（SIP）は、ワーキンググループの期間SIPプロトコル[RFC3261]の「所有者」であることが公認されました。 SIPへのすべての変更や拡張は、最初のSIPワーキンググループ文書として存在する必要がありました。 SIPワーキンググループは、インターネットのためのSIPプロトコルの守護者であることを仕込み、したがって、そうする説得力のある理由があったときのみ、SIPプロトコルを拡張したり、変更することが義務付けられました。
The SIPCORE Working Group replaces the function of the SIP Working Group in the original [RFC3427] account. Documents that must be handled by the SIPCORE Working Group include all documents that update or obsolete RFCs 3261 through 3265 or their successors. All SIP extensions considered in SIPCORE must be Standards Track. They may be based upon requirements developed externally in other IETF working groups.
SIPCOREワーキンググループは、元の[RFC3427]アカウント内のSIPワーキンググループの機能を置き換えます。 SIPCOREワーキンググループによって処理されなければならない書類は、その更新または廃止されたRFC 3265やその後継者を通して3261すべての文書が含まれます。 SIPCOREで考慮されるすべてのSIPの拡張機能は、標準化過程でなければなりません。彼らは他のIETFワーキンググループでは、外部開発要件に基づいていてもよいです。
Typical IETF working groups do not live forever; however, SIPCORE's charter is open-ended in order to allow it to remain the place where core SIP development will continue. In the event that the SIPCORE Working Group has closed and no suitable replacement or follow-on working group is active (and this specification also has not been superseded), then when modifications to the core SIP protocol are proposed, the RAI Area Directors will use the non-working-group Standards Track document process (described in Section 6.1.2 of RFC 2026 [RFC2026]) using the SIPCORE mailing list and Designated Experts from the SIP community for review.
典型的なIETFワーキンググループは永遠に住んでいません。しかし、SIPCOREのチャーターは、オープンエンド、それはコアSIPの開発を継続する場所とどまることを可能にするためです。コアSIPプロトコルへの変更が提案されている場合、RAI Areaディレクターが使用する、その後、SIPCOREワーキンググループが閉じており、いかなる適当な置換又は後続のワーキンググループがアクティブでない（および本明細書も取って代わられていない）した場合には非ワーキンググループ標準化過程ドキュメントプロセス（のセクション6.1.2で説明したRFC 2026 [RFC2026]）SIPCOREメーリングリストやレビューのためのSIPコミュニティから指定の専門家を使用。
It is appropriate for any IETF working group to develop SIP event packages [RFC3265], but the working group must have charter approval to do so. The IETF will also require [RFC5226] IETF Review for the registration of event packages developed outside the scope of an IETF working group. Instructions for event package registrations are provided in Section 4.1.
[RFC3265] SIPイベントパッケージを開発するために、任意のIETFワーキンググループに適しているが、ワーキンググループは、そうする憲章の承認を持っている必要があります。また、IETFはIETFワーキンググループの範囲外で開発されたイベントパッケージの登録のために[RFC5226] IETFレビューが必要になります。イベントパッケージの登録方法については、セクション4.1で提供されています。
Historically, the IETF Session Initiation Protocol Proposal Investigation (sipping) Working Group was chartered to be a filter in front of the SIP Working Group. This working group investigated requirements for applications of SIP, some of which led 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.
歴史的に、IETFセッション開始プロトコルの提案調査（飲み）ワーキンググループはSIPワーキンググループの前にフィルタであることをチャーターしました。このワーキンググループは、SIPへの拡張のための要求につながったそのうちのいくつかはSIPのアプリケーションの要件を、調査しました。これらの要件は、大規模で、または他の標準化団体によって決定される要件を報告している個人からコミュニティから来るかもしれません。
The DISPATCH Working Group replaces the function of the SIPPING WG, although with several important changes to its functionality -- the most notable being that its scope expands beyond just SIP to the entire work of the RAI Area. Like SIPPING, DISPATCH considers new proposals for work in the RAI Area, but rather than taking on specification deliverables as charter items itself, DISPATCH identifies the proper venue for work. If no such venue yet exists in the RAI Area, DISPATCH will develop charters and consensus for a BoF, working group, or exploratory group [RFC5111] as appropriate. Unlike the previous change structure, a DISPATCH review of any proposed change to core SIP is not required before it progresses to SIPCORE;
最も注目すべきは、その範囲がちょうどRAIエリアの全体の仕事にSIPを超えて拡大するということで - DISPATCH作業部会は、その機能にはいくつかの重要な変更であるが、SIPPING WGの機能を置き換えます。 SIPPINGと同様に、発送はRAIエリアでの仕事のための新たな提案を検討するのではなく、チャーター項目として仕様の成果の上に自分自身を取るよりも、発送は仕事のための適切な会場を識別します。そのような場所がまだRAI領域に存在しない場合、発送はチャーターや適宜のBoF、作業グループ、または探索グループ[RFC5111]のためのコンセンサスを開発します。それはSIPCOREに進む前に、前回の変化構造とは異なり、コアSIPへの変更案の発送見直しが必要とされていません。
however, any new proposed work that does not clearly fall within the charter of an existing RAI Area effort should be examined by DISPATCH.
しかし、明らかに既存のRAIエリア努力のチャーター内に収まっていない任意の新しい提案の仕事はDISPATCHによって検査されなければなりません。
In reaction to a proposal, the DISPATCH Working Group may determine that:
提案への反応では、DISPATCHワーキンググループがそれを決定することができます。
1. these requirements justify a change to the core SIP specifications (RFCs 3261 through 3265) and thus any resulting work must transpire in SIPCORE;
1.これらの要件は、コアSIP仕様（のRFC 3265を介して、3261）への変更を正当化するので、任意の得られた仕事はSIPCOREに蒸散しなければなりません。
2. these requirements do not change the SIP core specifications but require a new effort in the RAI Area (be that a working group, a BoF, or what have you);
2.これらの要件は、SIPコアの仕様を変更しませんが（ワーキンググループ、このBoF、または何があなたを持っているということ）RAI地域における新たな取り組みが必要です。
3. these requirements fall within the scope of existing chartered work in the RAI Area; or
3.これらの要件は、RAIエリア内の既存のチャーター仕事の範囲内にあります。または
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. DISPATCH should act as a filter, accepting only proposals that play to the strengths of SIP, not those that confuse its applicability or ultimately reduce its usefulness as a means for immediate personal communications on the Internet.
SIPプロトコルはあまり注目されているので、いくつかのアプリケーション設計者は、それがあるので、このような家電製品を制御するためとして、それを使用することをお勧めします。発送はSIPの強みではなく、その適用性を混同したり、最終的にインターネット上で即時に個人的なコミュニケーションのための手段として、その有用性を減らすものに遊ぶだけの提案を受け入れ、フィルタとして行動しなければなりません。
In practice, it is expected that the DISPATCH WG behaves as a RAI "Open Area" working group, similar to those employed in other areas of the IETF. While it does not have the traditional deliverables of a working group, DISPATCH may, at the discretion of its chairs and Area Directors, adopt milestones in accordance with standard working group milestone-adoption procedures, such as the production of charter text for a BoF or working group, a "-00" problem statement document that explicates a proposed work effort, or a document explaining why a particular direction for standards development was not pursued.
実際には、DISPATCH WGは、IETFの他の分野で用いられるものと類似RAI「オープンエリア」ワーキンググループとして振る舞うことが期待されます。それはワーキンググループの伝統的な成果を持っていませんが、発送は、その椅子や地域の取締役の裁量で、そのようなのBoFのためのチャーターテキストの生産として、標準ワーキンググループマイルストーン・養子縁組の手続きに従い、マイルストーンを採用することができますか、ワーキンググループ、提案された作業の労力をexplicates「-00」の問題文の文書、または規格開発のための特定の方向を追求されなかった理由を説明する文書。
In this document, the key words "MAY", "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC2119]. This document additionally uses [RFC5226] language to describe IANA registrations.
この文書に記載されている、キーワード "MAY"、 "MUST" は、 "NOT MUST"、 "SHOULD"、および "SHOULD NOT"、[RFC2119]に記載されているように解釈されるべきです。この文書では、さらにIANA登録を記述するために、[RFC5226]の言語を使用しています。
As with any new work in the IETF, proposals are best formulated in individual Internet-Drafts. New ideas arising within the chartered scope of a RAI Area working group naturally should be treated as candidates for adoption as a working group item there. Experience has demonstrated that authoring a problem statement or set of initial requirements prior to (or at least separately from) submitting a protocol mechanism speeds the consensus-making process significantly. A problem statement should explain what problem needs to be solved, why existing mechanisms are insufficient, and, for proposals to modify SIP, why SIP is the appropriate solution for this problem. A problem statement must also detail any security issues that may result from meeting these requirements. When proposed new work does not fall within the bounds of existing RAI Area working group charters, the DISPATCH Working Group assists the authors of proposals, the RAI Area Directors and the RAI community to decide the best way to approach the problem. Authors of proposals may submit their problem statements to the DISPATCH Working Group for community consideration and review.
IETFでの新たな仕事と同じように、提案は最高の個々のインターネットドラフトで処方されています。 RAI地域ワーキンググループのチャーター範囲内で生じる新たなアイデアが自然にそこにワーキンググループ項目として採用候補として扱われるべきです。経験は、問題文をオーサリングすることを実証したまたは有意プロトコル機構を提出する前に初期要求（または少なくとも別に）のコンセンサス製造工程を短縮しています。問題文は、既存のメカニズムが不十分である、と、SIPを変更する提案のために、なぜSIPは、この問題の適切な解決策である理由、解決する必要があるものの問題を説明する必要があります。問題文はまた、ディテール、これらの要件を満たすことから生じる可能性のあるセキュリティ上の問題がなければなりません。提案された新しい仕事は、既存のRAIエリアワーキンググループのチャーターの範囲内に収まっていない場合は、DISPATCHワーキンググループが提案、RAIエリアの取締役およびRAIコミュニティの作者が問題にアプローチする最良の方法を決定するために支援します。提案の作成者は、コミュニティの検討や見直しのためDISPATCH作業部会にその問題文を提出することができます。
The DISPATCH Working Group chairs, in conjunction with the RAI Area Directors, will determine if the particular problems raised in the requirements problem statement are indeed outside the charter of existing efforts and, if so, if they warrant a DISPATCH milestone for the definition of a new effort; this DISPATCH deliverable may take the form of a problem statement Internet-Draft, charter, or similar milestone that provides enough information to make a decision, but must not include protocol development. The DISPATCH Working Group should consider whether the requirements can be merged with other requirements from other applications, and refine the problem statement accordingly.
もしそうなら、彼らはの定義については、派遣マイルストーンを保証する場合DISPATCHワーキンググループチェアは、RAIエリアディレクターと一緒に、、、要件の問題文で提起特定の問題は、既存の努力のチャーター外に実際にあるかどうかを判断してます新たな取り組み。このディスパッチ成果は、決定を下すのに十分な情報を提供し、問題文インターネットドラフト、チャーター、または類似したマイルストーンの形をとることができるが、プロトコル開発を含めることはできません。 DISPATCHワーキンググループは、要件は、他のアプリケーションから他の要件と合併することができるかどうかを検討し、それに応じて問題文を絞り込む必要があります。
Once a new effort has been defined in DISPATCH and there is working group consensus that it should go forward, if the new effort will take the form of a working group or BoF, then the ADs will present the proposed new effort charter to the IESG and IAB, in accordance with the usual chartering process. If the new effort involves the rechartering of an existing working group, then similarly the existing working group rechartering functions will be performed by the appropriate WG chairs and ADs. If the IESG (with IAB advice) approves of the new charter or BoF, the DISPATCH Working Group has completed its deliverable and the new effort becomes autonomous.
新たな取り組みがDISPATCHで定義されていると、それは前に進むべきだとワーキンググループのコンセンサスがあると、新しい取り組みがワーキンググループかのBoFの形を取る場合は、その後、ADSはIESGに提案された新しい取り組み憲章を提示すると、 IAB、通常のチャータープロセスに従ってインチ新たな取り組みは、既存のワーキンググループのrecharteringが含まれている場合は、同様に、既存のワーキンググループrechartering機能は、適切なWGチェアや広告で実行されます。 （IABアドバイス付き）IESGが新しいチャーターかのBoFを承認した場合、DISPATCH作業部会は、その成果を完了し、新たな取り組みが自律的になります。
Anyone proposing requirements for new work is welcome to jointly develop, in a separate Internet-Draft, a mechanism that would meet the requirements. No working group is required to adopt the proposed solution from this additional Internet-Draft.
新しい仕事のための要件を提案する誰もが共同で、個別のインターネットドラフトでは、要件を満たしてしまうメカニズムを開発する大歓迎です。何ワーキンググループは、この追加のインターネットドラフトから提案されたソリューションを採用する必要はありません。
Work overseen by the SIPCORE 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, SIPCORE must not add features just to make a particular function more efficient at the expense of simplicity or robustness.
SIPCOREワーキンググループが監督の仕事は、SIPのアーキテクチャの整合性を保護するために必要とされ、具体的なケースを超えた一般的な使用を持っていない機能を追加してはいけません。また、SIPCOREはただ単純さや堅牢性を犠牲にして特定の機能をより効率的にするために機能を追加してはなりません。
The DISPATCH process is not the sole place that requirements for new work are considered in the RAI Area. For example, some working groups generate requirements for SIP solutions and/or extensions. At the time this document was written, groups with such chartered deliverables include SIP for Instant Messaging and Presence Leveraging Extensions (simple), Basic Level of Interoperability for SIP Services (bliss) and Session Peering for Multimedia Interconnect (speermint). The work of these and similar groups is not affected by the DISPATCH process.
DISPATCHプロセスは、新しい仕事のための要件はRAIエリアで考慮されている唯一の場所ではありません。例えば、いくつかのワーキンググループは、SIPソリューションおよび/または拡張のための要件を生成します。この文書が書かれた時点では、そのようなチャーター成果を持つグループは、マルチメディアインターコネクト（speermint）のためのインスタントメッセージングとプレゼンスの活用拡張機能（シンプル）のためのSIP、SIPサービスのための相互運用性の基本レベル（至福）とセッションピアリングが含まれます。これらと同様のグループの作業は、ディスパッチ処理の影響を受けません。
Of course, the RAI Area Directors may accept charter revisions from existing working groups that add new milestones or scope to their charters at their discretion, in the standard IETF manner, without any actions on the part of the DISPATCH Working Group. DISPATCH exists to assist new work in finding a home expeditiously in those cases where it does not naturally fall into an existing bucket.
もちろん、RAIエリアの取締役はDISPATCHワーキンググループの一部上の任意のアクションなしに、標準IETFの方法で、自分の裁量で彼らのチャーターに新しいマイルストーンまたは範囲を追加し、既存のワーキンググループからのチャーターリビジョンを受け入れることができます。発送は、それが自然に既存のバケットに分類されないような場合に迅速に家庭を見つけることで新しい仕事を支援するために存在しています。
In an idealized protocol model, extensible design would be self-contained, and it would be inherent that new extensions and new header fields 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 RAI Area calls for architectural guardianship and application of Occam's Razor by the SIPCORE and DISPATCH Working Groups.
しかし、この理想的なビジョンは、標準化過程プロトコルの世界では達成されていません。相互運用性への影響が能力交渉ルールによって対処することができますが、ポイントソリューションと重複する機能、またはその取引を追加し、一般的ではないの効果は、ルールで制御することが非常に困難です。したがって、RAIエリアは、建築後見とSIPCOREとDISPATCHワーキンググループによってオッカムの剃刀のアプリケーションのために呼び出します。
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. In the past, header fields associated with those extensions were called "P-" header fields for "preliminary", "private", or "proprietary".
「コードとラフコンセンサスを実行している」のIETFの伝統に沿って、いずれかの標準化過程のために準備ができていないSIPの拡張機能の開発を可能にするために有効ですが、いくつかの実行中のコードの後に、その役割のために理解される可能性がありますまたはプライベートですか自然の中で独自のそれらをやる気特性ので、SIPのためのインターネットアーキテクチャに合わせてないことが知られている使用方法です。過去には、これらの拡張子に関連付けられたヘッダフィールドは、「予備」「プライベート」、または「専有」のための「P-」ヘッダフィールドと呼ばれていました。
However, the "P-" header field process has not served the purpose for which it was designed -- namely, to restrict to closed environments the usage of mechanisms the IETF would not (yet) endorse for general usage. In fact, some "P-" header fields have enjoyed widespread implementation; because of the "P-" prefix, however, there seems to be no plausible migration path to designate these as general-usage header fields without trying to force implausible changes on large installed bases.
しかし、「P-」ヘッダフィールドのプロセスは、それが設計された目的を果たしていない - すなわち、閉鎖環境にメカニズムの使用を制限するためにIETFが（まだ）一般的な使用のために承認しないであろう。実際には、いくつかの「P-」ヘッダフィールドは、広範囲の実装を享受してきました。 「P-」プレフィックスのため、しかし、大規模なインストールベースに信じ難い変更を強制しようとすることなく、一般用法ヘッダーフィールドとしてこれらを指定するいかなる妥当移行パスはないと思われます。
Accordingly, this specification deprecates the previous [RFC3427] guidance on the creation of "P-" header fields. Existing "P-" header fields are to be handled by user agents and proxy servers as the "P-" header field specifications describe; the deprecation of the change process mechanism entails no change in protocol behavior. New proposals to document SIP header fields of an experimental or private nature, however, shall not use the "P-" prefix (unless existing deployments or standards use the prefix already, in which case they may be admitted as grandfathered cases at the discretion of the Designated Expert).
従って、本明細書では、「P-」ヘッダフィールドの作成に以前[RFC3427]ガイダンスを非難します。既存の「P-」ヘッダフィールドは、「P-」ヘッダフィールドの仕様で説明するようにユーザエージェントとプロキシサーバーによって処理されます。変更プロセス機構の廃止は、プロトコルの挙動に変化を伴うありません。既存の配備や基準は、彼らはの裁量で適用除外例として認められることがあり、その場合には、すでに接頭辞を使用しない限り、実験や民間自然のSIPヘッダフィールドを文書化するための新しい提案が、しかし、「P-」の接頭辞を（使用してはなりません指定エキスパート）。
Instead, the registration of SIP header fields in Informational RFCs, or in documents outside the IETF, is now permitted under the Designated Expert (per [RFC5226]) criteria. The future use of any header field name prefix ("P-" or "X-" or what have you) to designate SIP header fields of limited applicability is discouraged. Experts are advised to review documents for overlap with existing chartered work in the RAI Area, and are furthermore instructed to ensure the following two criteria are met:
代わりに、情報のRFCsにおけるSIPヘッダーフィールドの登録、またはIETF外部文書に、今基準（[RFC5226]あたりの）指定された専門家の下で許可されています。限られた適用のSIPヘッダフィールドを指定する任意のヘッダフィールド名のプレフィックス（「P-」または「X-」か何を持っている）の将来の使用が推奨されていません。専門家はRAIエリアでチャーター作業を既存との重複のためのドキュメントを確認することをお勧めします、さらに次の2つの基準が満たされていることを確認するように指示されています。
1. The proposed header field MUST be of a purely informational nature and MUST NOT significantly change the behavior of SIP entities that support it. Header fields that merely provide additional information pertinent to a request or a response are acceptable; these header fields are thus expected to have few, if any, implications for interoperability and backwards compatibility. Similarly, header fields that provide data consumed by applications at the ends of SIP's rendezvous function, rather than changing the behavior of the rendezvous function, are likely to be providing information in this sense. If the header fields redefine or contradict normative behavior defined in Standards Track SIP specifications, that is what is meant by significantly different behavior. Ultimately, the significance of differences in behavior is a judgment call that must be made by the expert reviewer.
1.提案されたヘッダフィールドは純粋に情報的に自然でなければならず、大幅にそれをサポートするSIPエンティティの振る舞いを変更しないでください。単に要求または応答に許容されるに関連する追加情報を提供するヘッダフィールド、これらのヘッダーフィールドは、このように相互運用性と下位互換性のために、もしあれば、いくつかの意味を持つことが期待されています。同様に、むしろランデブ機能の動作を変更するよりも、SIPのランデブ機能の端部のアプリケーションによって消費されるデータを提供するヘッダフィールドは、この意味での情報を提供する可能性があります。ヘッダフィールドは、標準化過程SIP仕様で定義された規範的な振る舞いを再定義するか、矛盾した場合、それは大きく異なる行動が意味するものです。最終的には、動作の違いの重要性は、専門家投稿者によって行われなければならない審判の判定です。
2. The proposed header field MUST NOT undermine SIP security in any sense. The Internet-Draft proposing the new header field MUST address security issues in detail, as if it were a Standards
2.提案されたヘッダフィールドは、いかなる意味においてもSIPセキュリティを弱体化してはいけません。それが標準であるかのように新しいヘッダフィールドを提案インターネットドラフトは、詳細なセキュリティ問題に対処しなければなりません
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).
Note that the deprecation of the "P-" header field process does not alter processes for the registration of SIP methods, URI parameters, response codes, or option tags.
「P-」ヘッダフィールドプロセスの廃止は、SIPメソッド、URIパラメータ、レスポンスコード、またはオプションタグの登録プロセスを変化させないことに留意されたいです。
SIP events [RFC3265] 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). Note that the guidance in [RFC3265] states that the IANA registration policy for normal event packages is "First Come First Serve"; this document replaces that policy with the following:
通常のイベントパッケージとイベントテンプレートパッケージ：SIPイベント[RFC3265]は、イベントパッケージの二つの異なるタイプを定義します。イベントテンプレートパッケージは作成され、（IETFワーキンググループからの）標準化過程RFCの公表によって登録することができます。 [RFC3265]のガイダンスは、通常のイベントパッケージのためのIANA登録ポリシーは「最初はサーブ最初に来る」であると述べていることに注意してください。このドキュメントは以下で、そのポリシーを置き換えます。
Individuals may wish to publish SIP Event packages that they believe fall outside the scope of any chartered work currently in RAI. Individual proposals for registration of a SIP event package MUST first be published as Internet-Drafts for review by the DISPATCH Working Group, or the working group, mailing list, or expert designated by the RAI Area Directors if the DISPATCH 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. Authors should submit their proposals as individual Internet-Drafts and post an announcement to the working group mailing list to begin discussion. The DISPATCH Working Group will determine if a proposed package is
個人は、彼らが現在、RAIのいずれかのチャーター仕事の範囲外と考えているSIPイベントパッケージを発行することを望むかもしれません。 DISPATCHワーキンググループが閉じている場合、SIPイベントパッケージの登録のための個々の提案は最初DISPATCHワーキンググループ、またはRAIエリアディレクターによって指定されたワーキンググループ、メーリングリスト、または専門家によるレビューのためにインターネットドラフトとして公開されなければなりません。提案は強い動機付けの部分、提案構文と意味、イベントパッケージの考慮事項、セキュリティ上の考慮事項の完全な説明、および使用例を含める必要があります。著者は、個々のインターネットドラフトとしての提案を提出し、議論を開始するためにワーキンググループのメーリングリストに告知を掲示する必要があります。提案されているパッケージがある場合DISPATCHワーキンググループが決定されます
a) an appropriate usage of SIP that should be spun into a new effort,
A）新しい努力に紡糸されるべきであるSIPの適切な使用法を、
b) applicable to SIP but not sufficiently interesting, general, or in-scope to adopt as a working group effort,
十分に、興味深い一般的、またはスコープ内のワーキンググループの取り組みとして採用するb）はSIPには適用ではなく、
c) contrary to similar work chartered in an existing effort, or
C）既存の努力にチャーター同様の仕事に反し、または
d) recommended to be adopted as or merged with chartered work elsewhere in RAI.
D）として採用することを推奨したり他の場所RAIでチャーター仕事と合併。
"RFC Required" in conjunction with "Designated Expert" (both as defined in RFC 5226) is the procedure for registration of event packages developed outside the scope of an IETF working group, according to the following guidelines:
「指定された専門家」と併せて「RFC必須」（RFC 5226で定義された両方として）、次のガイドラインに従って、IETFワーキンググループの範囲外で開発されたイベントパッケージの登録のための手順です。
1. A Designated Expert (as defined in RFC 5226) must review the proposal for applicability to SIP and conformance with these guidelines. The Designated Expert 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 5226で定義されている）SIPへの適用や、これらのガイドラインに準拠のための提案を検討しなければなりません。指定Expertはこの決定に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 [RFC3265], SIP [RFC3261], or related Standards Track extensions. (See Section 4.)
4.イベントパッケージは、[RFC3265]、SIP [RFC3261]、または関連する標準化過程の拡張をSIPイベントの規範的な振る舞いを再定義するか、矛盾してはなりません。 （第4節を参照してください）
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 4 of SIP events [RFC3265].
前記提案されたパッケージは、明らかに（個人）情報のRFCに文書化され、IANAに登録されなければなりません。パッケージには、SIPイベント[RFC3265]のセクション4で必要なすべてのパッケージの考慮事項を文書化しなければなりません。
7. If determined by the Designated Expert or the chairs or ADs of the DISPATCH 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.指定エキスパートまたはDISPATCH WG、提案の有益な範囲を文書化し、その限界を説明し、それが一般的な使用には適していません理由を明確にしなければならない情報のRFCでの適用性声明の椅子や広告によって決定した場合インターネットでSIP。
1. Documents that update or obsolete RFCs 3261 through 3265 must advance through the SIPCORE WG.
3265を通じて更新または廃止されたRFC 3261がSIPCORE WGを通じて進める必要があります。1.ドキュメント。
2. Standard SIP extensions that do not update RFCs 3261 through 3265, including event packages, may advance through chartered activity in any RAI Area WG or (with the agreement of the RAI ADs) any IETF working group that constitutes an appropriate venue.
イベントパッケージを含む、3265を介してのRFCに3261を更新しない2.標準SIP拡張は、任意RAIエリアWGまたは適切な会場を構成する任意のIETFワーキンググループ（RAIの広告契約を有する）チャーター活動を通して進めることができます。
3. Documents that specify Informational header fields pass through an Expert Review system.
情報のヘッダフィールドを指定3.ドキュメントはエキスパートレビューシステムを通過します。
Complex, indeterminate, and hard-to-define protocol behavior, depending on the interaction of many optional extensions, 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, must consider the security implications of feature interactions, and most of all must not worsen SIP's existing security considerations.
SIPのための新たな要件を提示し、すべてのインターネットドラフトは提案に固有のセキュリティ要件と意味の説明を含める必要があります。 SIPを変更したり、拡張するすべてのRFCは、彼らが十分なセキュリティを持っていることを示さなければならない、機能競合のセキュリティへの影響を考慮する必要があり、そしてすべてのほとんどは、SIPの既存のセキュリティの考慮事項を悪化させてはいけません。
RFC 3261 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 header fields. Reiterating the guidance of RFC 3261, method names, option tags, and SIP response codes require a Standards Action for inclusion in the IANA registry. Authors of specifications should also be aware that the SIP parameter registry is further elaborated in [RFC3968].
RFC 3261は、Internet Assigned Numbers Authority（IANA）SIPメソッド名のレジストリ、SIPオプションタグのレジストリ、およびSIP応答コードのレジストリを確立するため、およびSIPヘッダフィールドの既存のレジストリに使用される慣行を修正することを指示します。 RFC 3261、メソッド名、オプションタグ、およびSIP応答コードの指導を繰り返す、IANAレジストリに含めるための標準アクションが必要です。仕様の著者らはまた、SIPパラメータレジストリはさらに[RFC3968]に詳述されていることに注意すべきです。
Previously in RFC 3427, all new SIP header field registrations required a Standards Action (per RFC 5226) with the exception of "P-" header fields; now, Informational registration of non-"P-" header fields is permitted if approved by a Designated Expert, as described in Section 4.
以前はRFC 3427で、すべての新しいSIPヘッダフィールドの登録が必要な標準化アクション「P-」ヘッダフィールドを除いて、（RFC 5226あたり）。セクション4で説明したように、指定された専門家によって承認された場合、今、非「P-」ヘッダフィールドの情報の登録が許可されています。
Each RFC shall include an IANA Considerations section that 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 header fields and messages MUST NOT begin with the leading characters "P-". Existing "P-" header field registrations are considered grandfathered, but new registrations of Informational header fields should not begin with the leading characters "P-" (unless the "P-" would preserve compatibility with a pre-existing, unregistered usage of the header field, at the discretion the Designated Expert). Short forms of header fields MUST only be assigned to Standards Track header fields.
標準のヘッダフィールドとメッセージが主役「P-」で始めてはいけません。既存の「P-」ヘッダフィールドの登録は適用除外と考えられているが、「P-」はの既存の、未登録の利用状況との互換性を保つない限り情報のヘッダフィールドの新規登録が主役「P-」（で始めるべきではありません裁量指定された専門家でのヘッダフィールド）。ヘッダフィールドの短い形式は標準化過程ヘッダフィールドに割り当てる必要があります。
Similarly, [RFC3265] directs the IANA to establish a registry for SIP event packages and SIP event template-packages. For event template-packages, registrations must follow the [RFC5226] processes for Standards Action within an IETF working group. For normal event packages, as stated previously, registrations minimally require [RFC5226] "RFC Required" with "Designated Expert". In either case, the IESG announcement of RFC approval authorizes IANA to make the registration.
同様に、[RFC3265]はSIPイベントパッケージとSIPイベント・テンプレート・パッケージのレジストリを確立するために、IANAに指示します。イベントテンプレートパッケージの場合、登録はIETFワーキンググループ内で標準化アクションのための[RFC5226]のプロセスに従わなければなりません。前述のように、通常のイベントパッケージについては、登録が最小限に「指定エキスパート」で[RFC5226]「RFC必須」が必要です。いずれの場合も、RFC承認のIESGの発表は、IANAが登録を作るために許可します。
[RFC3969] stipulates that the (original) [RFC2434] rule of "Specification Required" applies to registrations of new SIP URI parameters; however, Section 3 of that same document mandates that a Standards Action is required to register new parameters with the IANA. This contradiction arose from a misunderstanding of the nature of the [RFC2434] categories; the intention was for the IANA Considerations to mandate that Standards Action is required.
[RFC3969]は、「仕様が必要」の（オリジナル）[RFC2434]のルールは、新しいSIP URIパラメータの登録に適用されることを規定しています。しかし、標準化アクションはIANAとの新しいパラメータを登録する必要があり、同じドキュメントの義務のセクション3。この矛盾は、[RFC2434]のカテゴリの性質の誤解から生じました。意図は、標準アクションが必要であることを義務付けるためにIANAの考慮事項のためでした。
This section provides a high-level overview of the changes between this document and RFC 3427. It is not a substitute for the document as a whole -- the details are necessarily not represented.
詳細は必ずしも示されていない - このセクションでは、それは全体として、ドキュメントのための代替ではない。この文書とRFC 3427.間の変更の高レベルの概要を提供します。
This document:
このドキュメント：
1. Changes the description of the SIP and SIPPING WG functions to the SIPCORE and DISPATCH WG functions using the context of the RAI Area.
1. RAIエリアのコンテキストを使用してSIPCOREディスパッチWG機能へSIPとSIPPING WG機能の記述を変更します。
2. Deprecates the process for "P-" header field registration, and changes the requirements for registration of SIP header fields of a purely informational nature.
2.「P-」ヘッダフィールド登録のプロセスを廃止すると、純粋に情報自然のSIPヘッダーフィールドの登録のための必要条件を変更します。
3. Updates IANA registry requirements, reflecting the publication of RFC 5226, clarifying the policies in RFC 3969, and clarifying that the original RFC 3237 updated the policies in RFC 3265.
3.アップデートIANAレジストリの要件、RFC 5226の出版を反映したRFC 3969に方針を明確化し、オリジナルのRFC 3237は、RFC 3265でポリシーを更新することを明確化。
The credit for the notion that SIP required careful management belongs to the original authors: Allison Mankin, Scott Bradner, Rohan Mahy, Dean Willis, Joerg Ott, and Brian Rosen. The current editors have provided only an update to reflect lessons learned from running the code and from the changing situation of the IETF and the IANA registration procedures. Gonzalo Camarillo was instrumental to the development of the concept of SIPCORE and DISPATCH. Useful comments were provided by Jonathan Rosenberg, Mary Barnes, Dan York, John Elwell, Alan Johnston, Spencer Dawkins, Alfred Hoenes, Russ Housley, and Dean Willis. The thorough review from Stephen Hanna of the Security Directorate proved enormously valuable. The authors also appreciated IESG feedback from Alexey Melnikov, Adrian Farrel, Dan Romascanu, and Magnus Westerlund.
アリソンマンキン、スコット・ブラッドナー、ロハンマーイ、ディーンウィリス、イェルク・オット、そしてブライアンローゼン：SIPは、慎重な管理を必要とするという考えのためのクレジットは、元の作者に属します。現在の編集者は、コードを実行しているからとIETFおよびIANA登録手順の変更状況から学んだ教訓を反映するために更新のみを提供しています。ゴンサロ・カマリロはSIPCOREとDISPATCHの概念の発展に尽力しました。有益なコメントはジョナサン・ローゼンバーグ、メアリー・バーンズ、ダン・ニューヨーク、ジョンエルウェル、アラン・ジョンストン、スペンサードーキンスアルフレッドHoenes、ラスHousley、およびディーンウィリスによって提供されました。セキュリティ総局のスティーブン・ハンナからの徹底的な見直しは非常に貴重な証明しました。著者らはまた、アレクセイ・メルニコフ、エードリアンファレル、ダンRomascanu、およびマグヌスウェスターからIESGからのフィードバックを感謝しています。
The original authors thanked their 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, including and especially Jonathan Rosenberg, Henning Schulzrinne, and William Marshall.
原作者は、私たちの地域は、前方にもたらしたものを含む、プロトコルの広い範囲で拡張性の問題の貴重な議論のための彼らのIESGとIABの同僚（特にランディブッシュ、ハラルドAlvestrand、ジョン・クレンシン、レスリーDaigle氏、パトリックFaltstrom、およびネッドフリードを）感謝しましたその他。特にジョナサン・ローゼンバーグ、ヘニングSchulzrinneと、そしてウィリアム・マーシャルを含むと同様、この文書についての興味深い対話に従事SIPコミュニティの多くのメンバーのおかげで、。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3261] 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.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265]ローチ、A.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、2002年6月。
[RFC3969] Camarillo, G., "The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)", BCP 99, RFC 3969, December 2004.
[RFC3969]キャマリロ、G.、BCP 99、RFC 3969、2004年12月 "セッション開始プロトコル（SIP）のための番号機関（IANA）のURI（Uniform Resource Identifier）パラメータレジストリの割り当てインターネット"。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
[RFC3325]ジェニングス、C.、ピーターソン、J.、およびM.ワトソン、 "信頼できるネットワーク内のアサート・アイデンティティのためのセッション開始プロトコル（SIP）のプライベート拡張"、RFC 3325、2002年11月。
[RFC3427] 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.
[RFC3427]マンキン、A.、ブラドナー、S.、マーイ、R.、ウィリス、D.、オット、J.、およびB.ローゼン、 "セッション開始プロトコル（SIP）のための変更処理"、BCP 67、RFC 3427、2002年12月。
[RFC3968] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, December 2004.
[RFC3968]キャマリロ、G.、BCP 98、RFC 3968、2004年12月 "インターネットは、セッション開始プロトコル（SIP）のための番号機関（IANA）ヘッダーフィールドパラメータレジストリを割り当てられました"。
[RFC5111] Aboba, B. and L. Dondeti, "Experiment in Exploratory Group Formation within the Internet Engineering Task Force (IETF)", RFC 5111, January 2008.
[RFC5111] Aboba、B.およびL. Dondeti、 "インターネットエンジニアリングタスクフォース（IETF）内の探索グループ形成における実験"、RFC 5111、2008年1月。
Authors' Addresses
著者のアドレス
Jon Peterson NeuStar, Inc.
ジョンピーターソンNeuStar株式会社
EMail: jon.peterson@neustar.biz
メールアドレス：jon.peterson@neustar.biz
Cullen Jennings Cisco Systems
カレンジェニングスシスコシステムズ
EMail: fluffy@cisco.com
メールアドレス：fluffy@cisco.com
Robert Sparks Tekelec
ロバート・スパークスTekelec
EMail: rjsparks@nostrum.com
メールアドレス：rjsparks@nostrum.com