[要約] RFC 5727は、SIPとリアルタイムアプリケーションおよびインフラストラクチャ領域の変更プロセスに関するものです。このRFCの目的は、SIPおよび関連するプロトコルの変更を効果的かつ一貫性のある方法で管理するためのガイドラインを提供することです。
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
セッション開始プロトコル（SIP）とリアルタイムアプリケーションとインフラストラクチャエリアの変更プロセス
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.
このメモは、セッション開始プロトコル（SIP）の将来の開発とリアルタイムアプリケーションおよびインフラストラクチャ（RAI）エリアでの関連作業を整理することを目的としたプロセスを文書化しています。SIPが展開される環境がより多数成長するにつれて、SIPを特定の方法で修正または拡張することで、プロトコルの相互運用性とセキュリティを脅かす可能性があります。ただし、IETFプロセスは、既存の展開の現実にも応え、SIPを使用して作業する実装者のニーズに応える必要があります。したがって、このドキュメントでは、Core 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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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テレフォニーアプリケーションで広範な人気を博しています。この人気の結果の1つは、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とすすりのワーキンググループ（WGS）の役割を定義しました。また、特に「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アサート付き（有料）ヘッダーフィールドです。
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ワーキンググループが処理する必要があるドキュメントには、RFCS 3261から3265またはその後継者を更新または廃止したすべてのドキュメントが含まれています。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の開発が続く場所にとどまることを可能にするために、オープンエンドです。SIPCOREワーキンググループが閉鎖され、適切な交換または後続のワーキンググループがアクティブでない場合（そしてこの仕様も取って代わられていません）、コアSIPプロトコルの変更が提案された場合、RAIエリアディレクターは使用します非労働グループ標準は、SIPCOREメーリングリストとSIPコミュニティの指定された専門家をレビューのために使用して、ドキュメントプロセス（RFC 2026のセクション6.1.2 [RFC2026]で説明）を追跡します。
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.
IETFワーキンググループがSIPイベントパッケージ[RFC3265]を開発することは適切ですが、ワーキンググループはそのためにチャーターの承認を得る必要があります。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セッション開始プロトコル提案調査（SIPPING）ワーキンググループは、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;
ディスパッチワーキンググループは、Sipping WGの機能に取って代わりますが、その機能にいくつかの重要な変更があります。最も注目すべきは、そのスコープがRAIエリア全体の仕事全体に単なる一口を超えて拡大することです。すすりながら、ディスパッチはRAIエリアでの仕事のための新しい提案を考慮しますが、仕様の成果物をチャーターアイテム自体として取得するのではなく、ディスパッチは仕事のための適切な場所を特定します。RAIエリアにそのような会場がまだ存在しない場合、ディスパッチは、必要に応じてBOF、ワーキンググループ、または探索グループ[RFC5111]のチャーターとコンセンサスを開発します。以前の変更構造とは異なり、Core SIPへの提案された変更の派遣レビューは、Sipcoreに進む前に必要はありません。
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エリアの努力の憲章内に明らかに該当しない新しい提案された作業は、ディスパッチによって検討する必要があります。
In reaction to a proposal, the DISPATCH Working Group may determine that:
提案に反応して、派遣ワーキンググループはそれを決定する場合があります。
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仕様（RFCS 3261〜3265）の変更を正当化するため、結果として生じる作業は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コア仕様を変更するものではありませんが、RAIエリアでの新たな努力が必要です（ワーキンググループ、BOF、またはあなたが何を持っているか）。
3. these requirements fall within the scope of existing chartered work in the RAI Area; or
3. これらの要件は、RAI地域の既存のチャーターされた作業の範囲内にあります。また
4. the proposal should not be acted upon at this time.
4. この時点で提案は行われるべきではありません。
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.
実際には、IETFの他のエリアで採用されているものと同様に、ディスパッチWGがRAIの「オープンエリア」ワーキンググループとして動作することが予想されます。ワーキンググループの伝統的な成果物はありませんが、派遣は、椅子とエリアディレクターの裁量で、BOFまたはBOFのチャーターテキストの生産など、標準的なワーキンググループのマイルストーン採用手順に従ってマイルストーンを採用することができます。ワーキンググループ、提案された作業努力を説明する「-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」、「muse」、「nut "wuth」、および" not "in buly"を[rfc2119]で説明するように解釈する必要があります。このドキュメントはさらに、[RFC5226]言語を使用してIANA登録を説明します。
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エリアワーキンググループチャーターの範囲内に該当しない場合、派遣ワーキンググループは、提案、RAIエリアディレクター、RAIコミュニティの著者を支援し、問題にアプローチする最良の方法を決定します。提案の著者は、コミュニティの考慮とレビューのために、派遣ワーキンググループに問題の声明を提出することができます。
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.
派遣ワーキンググループの椅子は、RAIエリアディレクターと協力して、要件問題の声明で提起された特定の問題が実際に既存の取り組みの憲章の外側にあるかどうかを判断します。新しい努力;この派遣成果物は、決定を下すのに十分な情報を提供するが、プロトコル開発を含めてはならない問題ステートメントインターネットドラフト、または同様のマイルストーンの形をとることができます。ディスパッチワーキンググループは、要件を他のアプリケーションの他の要件と統合できるかどうかを検討し、それに応じて問題の声明を改善する必要があります。
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.
派遣で新しい努力が定義され、ワーキンググループのコンセンサスが進むと、新しい努力がワーキンググループまたはBOFの形をとる場合、広告は提案された新規努力チャーターをIESGに提示し、IABは、通常のチャータープロセスに従って。新しい取り組みに既存のワーキンググループの充電が含まれる場合、同様に、既存のワーキンググループ充電関数が適切なWG椅子と広告によって実行されます。IESG（IABアドバイスを含む）が新しいチャーターまたはBOFを承認した場合、派遣ワーキンググループはその成果を完了し、新しい努力が自律的になります。
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.
派遣プロセスは、RAIエリアで新しい作業の要件が考慮される唯一の場所ではありません。たとえば、一部のワーキンググループは、SIPソリューションおよび/または拡張機能の要件を生成します。このドキュメントが書かれた時点で、このようなチャーターされた成果物を備えたグループには、インスタントメッセージング用のSIPが含まれ、拡張機能（シンプル）、SIPサービスの基本レベル（至福）、マルチメディアインターコネクト（Speermint）のセッションピアリングが含まれます。これらおよび類似のグループの作業は、派遣プロセスの影響を受けません。
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エリアのディレクターは、ディスパッチワーキンググループの側でのアクションなしで、標準的なIETF方法で、標準的な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 Workingグループによる建築の後見と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. In the past, header fields associated with those extensions were called "P-" header fields for "preliminary", "private", or "proprietary".
「コードと大まかなコンセンサスを実行する」というIETFの伝統に沿って、標準の追跡の準備ができていないが、一部の実行中のコードの後にその役割について理解されるか、プライベートである、またはそれらを動機付ける特徴的な動機は、SIPのインターネットアーキテクチャに適合しないことが知られている使用法であるため、本質的に独自のものです。過去には、これらの拡張機能に関連付けられたヘッダーフィールドは、「Primination」、「Private」、または「Proprietary」の「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:
代わりに、情報RFCまたはIETF外のドキュメントでのSIPヘッダーフィールドの登録は、指定された専門家（[RFC5226]ごとに）基準の下で許可されています。ヘッダーフィールド名プレフィックス（ "p-"または "x-"、または何があるか）の将来の使用が限られた適用可能性のSIPヘッダーフィールドを指定することが推奨されます。専門家は、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エンティティの動作を大幅に変えてはなりません。単にリクエストまたは応答に関連する追加情報を提供するヘッダーフィールドは受け入れられます。したがって、これらのヘッダーフィールドは、相互運用性と後方互換性に影響を与えることはほとんどないと予想されます。同様に、Rendezvous関数の動作を変更するのではなく、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 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).
2. 提案されたヘッダーフィールドは、いかなる意味でもSIPセキュリティを損なってはなりません。新しいヘッダーフィールドを提案するインターネットドラフトは、標準トラックドキュメントであるかのように、セキュリティの問題に詳細に対処する必要があります。意図したアプリケーションシナリオがセキュリティに関する特定の仮定を行っている場合、セキュリティ上の考慮事項は、一般的なインターネットケースではなく、意図したアプリケーションシナリオを満たすだけであることに注意してください。いずれにせよ、任意の使用シナリオ（一般的なインターネットケースを含む）については、セキュリティの問題について議論する必要があります。
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]は、通常のイベントパッケージとイベントテンプレートパッケージの2つの異なるタイプのイベントパッケージを定義します。イベントテンプレートパッケージは、標準トラックRFC（IETFワーキンググループから）の公開によってのみ作成および登録できます。[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イベントパッケージを公開したい場合があります。SIPイベントパッケージの登録に関する個別の提案は、派遣ワーキンググループ、またはワーキンググループ、メーリングリスト、またはRAIエリアディレクターが派遣ワーキンググループが閉鎖した場合に指定された専門家によるレビューのために、インターネットドラフトとして最初に公開する必要があります。提案には、強力な動機付けセクション、提案された構文とセマンティクスの徹底的な説明、イベントパッケージの考慮事項、セキュリティに関する考慮事項、および使用例が含まれます。著者は、個々のインターネットドラフトとして提案を提出し、議論を開始するためにワーキンググループメーリングリストに発表を投稿する必要があります。ディスパッチワーキンググループは、提案されたパッケージが
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 5226で定義されているように）と併せて「RFCが必要」は、次のガイドラインに従って、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で定義されている）は、これらのガイドラインを飲んで適合するための適用性の提案を確認する必要があります。指定された専門家は、この決定について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 [RFC3265], SIP [RFC3261], or related Standards Track extensions. (See Section 4.)
4. イベントパッケージは、SIPイベント[RFC3265]、SIP [RFC3261]、または関連標準の拡張を追跡することの規範的な動作を再定義または矛盾してはなりません。（セクション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].
6. 提案されたパッケージは、（個別の）情報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. 指定された専門家またはディスパッチWGの椅子または広告によって決定された場合、情報情報RFCの適用声明は、提案の有用な範囲を明確に文書化し、その限界とSIPの一般的な使用に適していない理由を説明する必要があります。インターネット。
1. Documents that update or obsolete RFCs 3261 through 3265 must advance through the SIPCORE WG.
1. RFCS 3261から3265を更新または廃止するドキュメントは、Sipcore WGを介して進む必要があります。
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.
2. イベントパッケージを含むRFCS 3261から3265を更新しない標準的なSIP拡張機能は、適切な会場を構成するIETFワーキンググループで、RAIエリアWGまたは（RAI広告の合意を伴う）任意のRAIエリアWGでのチャーターアクティビティを通じて前進する場合があります。
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は、インターネットに割り当てられた数字当局（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]はIANAに、SIPイベントパッケージとSIPイベントテンプレートパッケージのレジストリを確立するよう指示します。イベントテンプレートパッケージの場合、登録は、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パラメーターの登録に適用されることを規定しています。ただし、同じドキュメントのセクション3では、IANAに新しいパラメーターを登録するには標準アクションが必要であることが義務付けられています。この矛盾は、[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. SIPの説明を変更し、RAI領域のコンテキストを使用して、SIP機能をSIPCOREにSIPCOREに加え、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. RFC 5226の公開を反映してIANAレジストリの要件を更新し、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と派遣の概念の開発に役立ちました。Jonathan Rosenberg、Mary Barnes、Dan York、John Elwell、Alan Johnston、Spencer Dawkins、Alfred Hoenes、Russ Housley、Dean Willisによって有用なコメントが提供されました。セキュリティ局のスティーブンハンナからの徹底的なレビューは、非常に価値があることが証明されました。著者はまた、Alexey Melnikov、Adrian Farrel、Dan Romascanu、Magnus Westerlundからの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の同僚（特にRandy Bush、Harald Alvestrand、John Klensin、Leslie Daigle、Patrik Faltstrom、およびNed Freed）に感謝しました。その他。SIPコミュニティの多くのメンバーが、この文書についての興味深い対話にも関与していること、特にJonathan Rosenberg、Henning Schulzrinne、William Marshallを含む。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] Bradner、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265] Roach、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] Camarillo、G。、「インターネットは、セッション開始プロトコル（SIP）の数字権権（IANA）のユニフォームリソース識別子（URI）パラメーターレジストリ」、BCP 99、RFC 3969、2004年12月。
[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] Jennings、C.、Peterson、J。、およびM. Watson、「信頼できるネットワーク内での主張されたアイデンティティのセッション開始プロトコル（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] Mankin、A.、Bradner、S.、Mahy、R.、Willis、D.、Ott、J。、およびB. Rosen、「セッション開始プロトコルの変更プロセス（SIP）」、BCP 67、RFC3427、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] Camarillo、G。、「インターネットは、セッション開始プロトコル（SIP）の番号が割り当てられたヘッダーフィールドパラメーターレジストリ」、BCP 98、RFC 3968、2004年12月。
[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.
Jon Peterson Neustar、Inc。
EMail: jon.peterson@neustar.biz
Cullen Jennings Cisco Systems
カレンジェニングスシスコシステム
EMail: fluffy@cisco.com
Robert Sparks Tekelec
ロバート・スパークス・テケレック
EMail: rjsparks@nostrum.com