RFC4485 日本語訳
4485 Guidelines for Authors of Extensions to the Session InitiationProtocol (SIP). J. Rosenberg, H. Schulzrinne. May 2006. (Format: TXT=57278 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Rosenberg
Request for Comments: 4485 Cisco Systems
Category: Informational H. Schulzrinne
Columbia University
May 2006
コメントを求めるワーキンググループJ.ローゼンバーグの要求をネットワークでつないでください: 4485年のシスコシステムズカテゴリ: 情報のH.Schulzrinneコロンビア大学2006年5月
Guidelines for Authors of Extensions to
the Session Initiation Protocol (SIP)
セッション開始プロトコルへの拡大の作者へのガイドライン(一口)
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
The Session Initiation Protocol (SIP) is a flexible yet simple tool for establishing interactive communications sessions across the Internet. Part of this flexibility is the ease with which it can be extended. In order to facilitate effective and interoperable extensions to SIP, some guidelines need to be followed when developing SIP extensions. This document outlines a set of such guidelines for authors of SIP extensions.
Session Initiationプロトコル(SIP)は、インターネットの向こう側に対話的なコミュニケーションセッションを確立するためのフレキシブルな、しかし、簡単なツールです。 この柔軟性の一部がそれを広げることができる容易さです。 有効で共同利用できる拡大をSIPに容易にするために、いくつかのガイドラインが、SIP拡張子を開発するとき、続かれる必要があります。 このドキュメントはSIP拡張子の作者のために1セットのそのようなガイドラインについて概説します。
Rosenberg & Schulzrinne Informational [Page 1] RFC 4485 SIP Guidelines May 2006
ローゼンバーグとSchulzrinneの情報[1ページ]のRFC4485はガイドライン2006年5月にちびちび飲みます。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Should I Define a SIP Extension? ................................3
3.1. SIP's Solution Space .......................................4
3.2. SIP Architectural Model ....................................5
4. Issues to Be Addressed ..........................................7
4.1. Backwards Compatibility ....................................7
4.2. Security ..................................................10
4.3. Terminology ...............................................10
4.4. Syntactic Issues ..........................................10
4.5. Semantics, Semantics, Semantics ...........................13
4.6. Examples Section ..........................................14
4.7. Overview Section ..........................................14
4.8. IANA Considerations Section ...............................14
4.9. Document-Naming Conventions ...............................16
4.10. Additional Considerations for New Methods ................16
4.11. Additional Considerations for New Header Fields
or Header Field ..........................................17
4.12. Additional Considerations for New Body Types .............18
5. Interactions with SIP Features .................................18
6. Security Considerations ........................................19
7. Acknowledgements ...............................................19
8. References .....................................................19
8.1. Normative References ......................................19
8.2. Informative References ....................................20
1. 序論…2 2. 用語…3 3. 私は一口拡大を定義するべきですか? ................................3 3.1. 一口のソリューションスペース…4 3.2. 建築モデルをちびちび飲んでください…5 4. 扱われる問題…7 4.1. 遅れている互換性…7 4.2. セキュリティ…10 4.3. 用語…10 4.4. 構文の問題…10 4.5. 意味論、意味論、意味論…13 4.6. 例の部…14 4.7. 概要部…14 4.8. IANA問題部…14 4.9. 命名を記録しているコンベンション…16 4.10. 新しいメソッドのための追加問題…16 4.11. 新しいヘッダーフィールドかヘッダーフィールドのための追加問題…17 4.12. 新しいボディータイプのための追加問題…18 5. 一口機能との相互作用…18 6. セキュリティ問題…19 7. 承認…19 8. 参照…19 8.1. 標準の参照…19 8.2. 有益な参照…20
1. Introduction
1. 序論
The Session Initiation Protocol (SIP) [2] is a flexible yet simple tool for establishing interactive communications sessions across the Internet. Part of this flexibility is the ease with which it can be extended (with new methods, new header fields, new body types, and new parameters), and there have been countless proposals that have been made to do just that. An IETF process has been put into place that defines how extensions are to be made to the SIP protocol [10]. That process is designed to ensure that extensions are made that are appropriate for SIP (as opposed to being done in some other protocol), that these extensions fit within the model and framework provided by SIP and are consistent with its operation, and that these extensions solve problems generically rather than for a specific use case. However, [10] does not provide the technical guidelines needed to assist that process. This specification helps to meet that need.
Session Initiationプロトコル(SIP)[2]は、インターネットの向こう側に対話的なコミュニケーションセッションを確立するためのフレキシブルな、しかし、簡単なツールです。 この柔軟性の一部がそれを広げることができる(新しいメソッド、新しいヘッダーフィールド、新しいボディータイプ、および新しいパラメタで)容易さです、そして、まさしくそれをするのがされた無数の提案がありました。 SIPプロトコル[10]に作られている拡大がことである方法を定義する場所にIETFプロセスを入れました。 そのプロセスは、SIP(ある他のプロトコルですることと対照的に)に、適切な拡大をして、これらの拡大がSIPによって提供されたモデルとフレームワークの中で合って、操作と一致していて、これらの拡大が使用がケースに入れる詳細より一般的にむしろ問題を解決するのを保証するように設計されています。 しかしながら、[10]はそのプロセスを補助するのに必要である技術的なガイドラインを提供しません。 この仕様は、その需要を満たすのを助けます。
This specification first provides a set of guidelines to help decide whether a certain piece of functionality is appropriately done in SIP. Assuming the functionality is appropriate, it then points out
この仕様は、最初に、SIPで適切に、ある機能性をするかどうか決めるのを助けるためにマニュアルを提供します。 そして、それは、機能性を仮定するのが適切であると指摘します。
Rosenberg & Schulzrinne Informational [Page 2] RFC 4485 SIP Guidelines May 2006
ローゼンバーグとSchulzrinneの情報[2ページ]のRFC4485はガイドライン2006年5月にちびちび飲みます。
issues that extensions should deal with from within their specification. Finally, it discusses common interactions with existing SIP features that often cause difficulties in extensions.
拡大がそれらの仕様から対処するべきである問題。 最終的に、それはしばしば拡大における困難を引き起こす既存のSIPの特徴との一般的な相互作用について議論します。
2. Terminology
2. 用語
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for compliant implementations.
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFCで2119[1]について説明して、対応する実装のために要件レベルを示すとき解釈されることであるべきですか?
3. Should I Define a SIP Extension?
3. 私は一口拡大を定義するべきですか?
The first question to be addressed when defining a SIP extension is whether a SIP extension is the best solution to the problem. SIP has been proposed as a solution for numerous problems, including mobility, configuration and management, QoS control, call control, caller preferences, device control, third-party call control, and MPLS path setup, to name a few. Clearly, not every problem can be solved by a SIP extension. More importantly, some problems that could be solved by a SIP extension probably shouldn't.
SIP拡張子を定義するとき扱われるべき最初の質問はSIP拡張子が問題への最も良い解決であるかどうかということです。 SIPは多数の問題のためのソリューションとして提案されました、いくつかを命名するために移動性、構成、管理、QoSコントロール、呼び出しコントロール、訪問者好み、装置制御、第三者呼び出しコントロール、およびMPLS経路セットアップを含んでいて。 明確に、SIP拡張子であらゆる問題を解決できるというわけではありません。 より重要に、SIP拡張子で解決できるだろういくつかの問題はたぶんそうするべきではありません。
To assist engineers in determining whether a SIP extension is an appropriate solution to their problem, we present two broad criteria. First, the problem SHOULD fit into the general purview of SIP's solution space. Secondly, the solution MUST conform to the general SIP architectural model.
SIP拡張子が彼らの問題への適切な解決であるかどうか決定するのに技術者を助けるために、私たちは2つの広い評価基準を提示します。 まず最初に、問題SHOULDはSIPのソリューションスペースの一般的な範囲に収まります。 第二に、ソリューションは一般的なSIP建築モデルに従わなければなりません。
Although the first criteria might seem obvious, we have observed that numerous extensions to SIP have been proposed because some function is needed in a device that also speaks SIP. The argument is generally given that "I'd rather implement one protocol than many". As an example, user agents, like all other IP hosts, need some way to obtain their IP address. This is generally done through DHCP [11]. SIP's multicast registration mechanisms might supply an alternate way to obtain an IP address. This would eliminate the need for DHCP in clients. However, we do not believe such extensions are appropriate. We believe that protocols should be defined to provide specific, narrow functions, rather than be defined for all protocols needed between a pair of devices. The former approach to protocol design yields modular protocols with broad application. It also facilitates extensibility and growth; single protocols can be removed and changed without affecting the entire system. We observe that this approach to protocol engineering mirrors object-oriented software engineering.
最初の評価基準は明白に見えるかもしれませんが、私たちは、何らかの機能がまた、SIPを話すデバイスで必要であるのでSIPへの大幅な拡大が提案されたのを観測しました。 一般に、「私は多くより1つのプロトコルを実装する方がましである」という主張を与えます。 例として、他のすべてのIPホストのように、ユーザエージェントは彼らのIPアドレスを得る何らかの方法を必要とします。 一般に、DHCP[11]を通してこれをします。 SIPのマルチキャスト登録メカニズムはIPアドレスを得る代替の方法を供給するかもしれません。 これはクライアントでDHCPの必要性を排除するでしょう。 しかしながら、私たちは、そのような拡大が適切であると信じていません。 私たちは、プロトコルが1組のデバイスの間で必要であるすべてのプロトコルのために定義されるよりむしろ特定の、そして、狭い機能を提供するために定義されるべきであると信じています。 前者は広いアプリケーションでプロトコルデザイン利回りにモジュールのプロトコルにアプローチします。 また、それは伸展性と成長を容易にします。 全体のシステムに影響しないで、ただ一つのプロトコルを取り除いて、変えることができます。 私たちは、工学について議定書の中で述べるこのアプローチがオブジェクト指向ソフトウェア工学を反映するのを観測します。
Our second criteria, that the extension must conform to the general SIP architectural model, ensures that the protocol remains manageable and broadly applicable.
私たちの2番目の評価基準、拡大が一般的なSIPに建築していた状態で従わなければならないのがモデル化して、プロトコルが処理しやすくて、広く適切なままで残っているのを確実にします。
Rosenberg & Schulzrinne Informational [Page 3] RFC 4485 SIP Guidelines May 2006
ローゼンバーグとSchulzrinneの情報[3ページ]のRFC4485はガイドライン2006年5月にちびちび飲みます。
3.1. SIP's Solution Space
3.1. 一口のソリューションスペース
In order to evaluate the first criteria, it is necessary to define exactly what SIP's solution space is, and what it is not.
最初の評価基準を評価するために、SIPのソリューションスペースがまさに何であるか、そして、それが何でないかを定義するのが必要です。
SIP is a protocol for initiating, modifying, and terminating interactive sessions. This process involves the discovery of users, (or, more generally, entities that can be communicated with, including services, such as voicemail or translation devices) wherever they may be located, so that a description of the session can be delivered to the user. It is assumed that these users or communications entities are mobile, and that their point of attachment to the network changes over time. The primary purpose of SIP is a rendezvous function, to allow a request initiator to deliver a message to a recipient wherever they may be. Such a rendezvous is needed to establish a session, but it can be used for other purposes related to communications, such as querying for capabilities or delivery of an instant message.
SIPは、対話的なセッションを開始して、変更して、終えるためのプロトコルです。 このプロセスがユーザの発見にかかわる、(より一般にボイスメールか翻訳デバイスなどのサービスを含んでいて、コミュニケートされることができる実体) どこでそうしても、見つけられてください、セッションの記述をユーザに提供できるように。 これらのユーザかコミュニケーション実体モバイルであり、ネットワークへのそれらの接着点が時間がたつにつれて変化すると思われます。 SIPのプライマリ目的は、要求創始者がどこでも、それらがあるかもしれないところで受取人に伝言をもたらすのを許容するためにはランデブー機能です。 そのようなランデブーがセッションを確立するのに必要ですが、コミュニケーションに関連する他の目的にそれを使用できます、インスタントメッセージの能力か配送のための質問などのように。
Much of SIP focuses on this discovery and rendezvous component. Its ability to fork, its registration capabilities, and its routing capabilities are all present for the singular purpose of finding the desired user wherever they may be. As such, features and capabilities such as personal mobility, automatic call distribution, and follow-me are well within the SIP solution space.
SIPの多くがこの発見とランデブーコンポーネントに焦点を合わせます。 それらがどこにあっても、分岐する性能、登録能力、およびそのルーティング能力は必要なユーザを見つけるまれな目的のためにすべて存在しています。 SIPソリューションスペースのかなり中に自動呼び出し分配であって、私に続いている個人的な移動性などのそのようなもの、特徴、および能力があるとき。
Session initiation also depends on the ability of the called party to have enough information about the session itself to make a decision on whether to join. That information includes data about the caller, the purpose for the invitation, and parameters of the session itself. For this reason, SIP includes this kind of information.
また、セッション開始は被呼者がおよそセッション自体接合するかどうかに関して決定できるくらいの情報を持つ能力に依存します。 その情報は訪問者に関するデータ、招待のための目的、およびセッション自体のパラメタを含んでいます。 この理由で、SIPはこの種類の情報を含んでいます。
Part of the process of session initiation is the communication of progress and the final results of establishment of the session. SIP provides this information as well.
セッション開始のプロセスの一部が、進歩に関するコミュニケーションとセッションの設立の最終的な結果です。 SIPはまた、この情報を提供します。
SIP itself is independent of the session, and the session description is delivered as an opaque body within SIP messages. Keeping SIP independent of the sessions it initiates and terminates is fundamental. As such, there are many functions that SIP explicitly does not provide. It is not a session management protocol or a conference control protocol. The particulars of the communications within the session are outside of SIP. This includes features such as media transport, voting and polling, virtual microphone passing, chairman election, floor control, and feedback on session quality.
SIP自身はセッションから独立しています、そして、セッション記述は不透明体としてSIPメッセージの中で提供されます。 それが開始して、終えるセッションの如何にかかわらずSIPを保つのは基本的です。 そういうものとして、SIPが明らかに提供しない多くの機能があります。 それは、セッション管理プロトコルでなくて、またまたは会議制御プロトコルでもありません。 セッション中のコミュニケーションの子細がSIPの外にあります。 これはセッション品質のメディア輸送や、票や世論調査などの特徴、仮想のマイクロホン通過、議長選挙、床のコントロール、およびフィードバックを含んでいます。
SIP is not a resource reservation protocol for sessions. This is fundamentally because (1) SIP is independent of the underlying
SIPはセッションのための資源予約プロトコルではありません。 これは(1) 基本的にSIPが基本的さから独立しているからです
Rosenberg & Schulzrinne Informational [Page 4] RFC 4485 SIP Guidelines May 2006
ローゼンバーグとSchulzrinneの情報[4ページ]のRFC4485はガイドライン2006年5月にちびちび飲みます。
session it establishes, and (2) the path of SIP messages is completely independent from the path that session packets may take. The path independence refers to paths within a provider's network and the set of providers itself. For example, it is perfectly reasonable for a SIP message to traverse a completely different set of autonomous systems than the audio in a session SIP establishes.
それが確立するセッション、およびSIPの経路が通信させる(2)はセッションパケットが取るかもしれない経路から完全に独立しています。 経路独立はプロバイダーのネットワークとプロバイダーのセット自体の中の経路について言及します。 例えば、完全に異なったセットの自律システムを横断するSIPメッセージに、それはSIPが確立するセッションにおけるオーディオより完全に妥当です。
SIP is not a general purpose transfer protocol. It is not meant to send large amounts of data unrelated to SIP's operation. It is not meant as a replacement for HTTP. This is not to say that carrying payloads in SIP messages is never a good thing; in many cases, the data is very much related to SIP's operation. In those cases, congestion-controlled transports end-to-end are critical.
SIPは汎用の転送プロトコルではありません。 それはSIPの操作に関係ない状態で多量のデータを送ることになっていません。 それはHTTPとの交換として意味されません。 これはSIPメッセージでペイロードを運ぶのが、決して良いものでないと言わないためのものです。 多くの場合、データはSIPの操作にたいへん関連します。 それらの場合では、終わるために終わっている混雑で制御された輸送は重要です。
SIP is not meant to be a general Remote Procedure Call (RPC) mechanism. None of its user discovery and registration capabilities are needed for RPC, and neither are most of its proxy functions.
SIPは一般的なRemote Procedure Call(RPC)メカニズムであることが意味されません。 そのユーザ発見と登録能力のいずれもRPCに必要ではありません、そして、プロキシ機能の大部分もそうではありません。
SIP is not meant to be used as a strict Public Switched Telephone Network (PSTN) signaling replacement. It is not a superset of the Integrated Services Digital Network (ISDN) User Part (ISUP). Although it can support gatewaying of PSTN signaling and can provide many features present in the PSTN, the mere existence of a feature or capability in the PSTN is not a justification for its inclusion in SIP. Extensions needed to support telephony MUST meet the other criteria described here.
SIPは、交換に合図しながら、厳しいPublic Switched Telephone Network(PSTN)として使用されることになっていません。 それはIntegrated Services Digital Network(ISDN)ユーザPart(ISUP)のスーパーセットではありません。 PSTNシグナリングのgatewayingをサポートすることができて、PSTNの現在の多くの特徴を提供できますが、PSTNの特徴か能力の単なる存在はSIPでの包含のための正当化ではありません。 電話を支えるのに必要である拡大はここで説明された他の評価基準を満たさなければなりません。
SIP is a poor control protocol. It is not meant to be used for one entity to tell another to pick up or answer a phone, to send audio using a particular codec, or to provide a new value for a configuration parameter. Control protocols have different trust relationships from that assumed in SIP and are more centralized in architecture than SIP is, as SIP is a very distributed protocol.
SIPは不十分な制御プロトコルです。 1つの実体が、電話に拾うか、出る、特定のコーデックを使用することでオーディオを送るか、または新しい値を設定パラメータに提供するように別のものに言うのに使用されて、それによる意味されません。 制御プロトコルは、SIPよりSIPで想定されたそれと異なった信頼関係を持って、アーキテクチャに集結されます、SIPが非常に分配されたプロトコルであるので。
There are many network layer services needed to make SIP function. These include quality of service, mobility, and security, among others. Rather than build these capabilities into SIP itself, they SHOULD be developed outside of SIP and then used by it. Specifically, any protocol mechanisms that are needed by SIP, but that are also needed by many other application layer protocols SHOULD NOT be addressed within SIP.
SIPを機能させるのに必要である多くのネットワーク層サービスがあります。 これらは特にサービスの質、移動性、およびセキュリティを含んでいます。 むしろ、これらの能力をSIP自身に組み込むよりそれら、SHOULDはSIPの外で開発されて、次に、それを使用しました。 明確に、いずれもSIPが必要ですが、必要であるメカニズムについて議定書の中で述べます、また、他の多くの応用層プロトコルSHOULD NOTが必要であることで、SIPの中で扱われてください。
3.2. SIP Architectural Model
3.2. 建築モデルをちびちび飲んでください。
We describe here some of the primary architectural assumptions that underlie SIP. Extensions that violate these assumptions should be examined more carefully to determine their appropriateness for SIP.
私たちはここでSIPの基礎となるいくつかのプライマリ建築仮定について説明します。 これらの仮定に違反する拡大は、SIPのために彼らの適切さを決定するために、より慎重に調べられるべきです。
Rosenberg & Schulzrinne Informational [Page 5] RFC 4485 SIP Guidelines May 2006
ローゼンバーグとSchulzrinneの情報[5ページ]のRFC4485はガイドライン2006年5月にちびちび飲みます。
Session independence: SIP is independent of the session it
establishes. This includes the type of session, be it audio,
video, game, chat session, or virtual reality. SIP operation
SHOULD NOT depend on some characteristic of the session. SIP is
not specific to voice only. Any extensions to SIP MUST consider
the application of SIP to a variety of different session types.
セッション独立: SIPはそれが確立するセッションから独立しています。 これはオーディオ、ビデオ、ゲーム、チャットセッション、またはバーチャルリアリティであることにかかわらずセッションのタイプを含んでいます。 SIP操作SHOULD NOTはセッションの何らかの特性に依存します。 SIPは声だけに特定ではありません。 SIP MUSTへのどんな拡大も、さまざまな異なったセッションまでのSIPのアプリケーションがタイプされると考えます。
SIP and Session path independence: We have already touched on this
once, but it is worth noting again. The set of routers, networks,
and/or autonomous systems traversed by SIP messages are unrelated
to the set of routers, networks, and/or autonomous systems
traversed by session packets. They may be the same in some cases,
but it is fundamental to SIP's architecture that they need not be
the same. Standards-track extensions MUST NOT be defined that
work only when the signaling and session paths are coupled. Non-
standard P-header extensions [10] are required for any extension
that only works in such a case.
SIPとSession経路独立: 私たちは一度既にこれに触れたことがありますが、それは再び注意する価値があります。 ルータのセット、ネットワーク、そして/または、SIPメッセージによって横断された自律システムはセッションパケットによって横断されたルータ、ネットワーク、そして/または、自律システムのセットに関係ありません。 それらはいくつかの場合同じであるかもしれませんが、同じようにそれらはアーキテクチャ的でなければなりませんが、それはSIPのものに基本的です。 標準化過程拡大はシグナリングとセッション経路が結合されるときだけ、定義されて、それが働いているということであるはずがありません。 非標準のP-ヘッダー拡大[10]がこのような場合には働いているだけであるどんな拡大にも必要です。
Multi-provider and multi-hop: SIP assumes that its messages will
traverse the Internet. That is, SIP works through multiple
networks administered by different providers. It is also assumed
that SIP messages traverse many hops (where each hop is a proxy).
Extensions MUST NOT work only under the assumption of a single hop
or specialized network topology. They SHOULD avoid the assumption
of a single SIP provider (but see the use of P-Headers, per RFC
3427 [10]).
マルチプロバイダーとマルチホップ: SIPは、メッセージがインターネットを横断すると仮定します。 すなわち、SIPは異なったプロバイダーによって管理された複数のネットワークを終えます。 また、SIPメッセージが多くのホップ(各ホップがプロキシであるところ)を横断すると思われます。 拡大は単一のホップか専門化しているネットワーク形態の仮定だけの下で働いてはいけません。 しかし、それら、SHOULDがただ一つのSIPプロバイダーの仮定を避ける、(RFC3427[10])あたりのP-ヘッダーの使用を見てください。
Transactional: SIP is a request/response protocol, possibly enhanced
with intermediate responses. Many of the rules of operation in
SIP are based on general processing of requests and responses.
This includes the reliability mechanisms, routing mechanisms, and
state maintenance rules. Extensions SHOULD NOT add messages that
are not within the request-response model.
取引: SIPはことによると中間的応答で高められた要求/応答プロトコルです。 SIPでの操作の規則の多くが要求と応答の一般的な処理に基づいています。 これは信頼性のメカニズム、ルーティングメカニズム、および州のメインテナンス規則を含んでいます。 拡大SHOULD NOTは要求応答モデルの中にないメッセージを加えます。
Proxies can ignore bodies: In order for proxies to scale well, they
must be able to operate with minimal message processing. SIP has
been engineered so that proxies can always ignore bodies.
Extensions SHOULD NOT require proxies to examine bodies.
プロキシはボディーを無視できます: プロキシがよくスケーリングするように、彼らは最小量のメッセージ処理で作動できなければなりません。 SIPは、プロキシがいつもボディーを無視できるように、設計されました。 拡大SHOULD NOTは、プロキシがボディーを調べるのを必要とします。
Proxies don't need to understand the method: Processing of requests
in proxies does not depend on the method, except for the well-
known methods INVITE, ACK, and CANCEL. This allows for
extensibility. Extensions MUST NOT define new methods that must
be understood by proxies.
プロキシはメソッドを理解する必要はありません: プロキシでの要求の処理はメソッドによりません、よく知られているメソッドINVITE、ACK、およびキャンセルを除いて。 これは伸展性を考慮します。 拡大はプロキシに解釈しなければならない新しいメソッドを定義してはいけません。
Rosenberg & Schulzrinne Informational [Page 6] RFC 4485 SIP Guidelines May 2006
ローゼンバーグとSchulzrinneの情報[6ページ]のRFC4485はガイドライン2006年5月にちびちび飲みます。
INVITE messages carry full state: An initial INVITE message for a
session is nearly identical (the exception is the tag) to a re-
INVITE message to modify some characteristic of the session. This
full state property is fundamental to SIP and is critical for
robustness of SIP systems. Extensions SHOULD NOT modify INVITE
processing such that data spanning multiple INVITEs must be
collected in order to perform some feature.
INVITEメッセージは完全な状態を運びます: セッションへの初期のINVITEメッセージはセッションの何らかの特性を変更する再INVITEメッセージとほとんど同じです(例外はタグです)。 この完全な州の所有地は、SIPに基本的であり、SIPシステムの丈夫さに、重要です。拡大SHOULD NOTがINVITE処理を変更するので、何らかの特徴を実行するために複数のINVITEsにかかるデータを集めなければなりません。
Generality over efficiency: Wherever possible, SIP has favored
general-purpose components rather than narrow ones. If some
capability is added to support one service but a slightly broader
capability can support a larger variety of services (at the cost
of complexity or message sizes), the broader capability SHOULD be
preferred.
効率の上一般性: どこでも、可能であるところでは、SIPが狭いものよりむしろ汎用コンポーネントを支持しました。 何らかの能力がそうなら、1つのサービスにもかかわらず、わずかに広い能力が、より大きいバラエティーのサービス(複雑さかメッセージサイズの費用における)、より広い能力SHOULDであるとサポートすることができるサポートに加えられて、好まれてください。
The Request URI is the primary key for forwarding: Forwarding logic
at SIP servers depends primarily on the request URI (this is
different from request routing in SIP, which uses the Route header
fields to pass a request through intermediate proxies). It is
fundamental to the operation of SIP that the request URI indicate
a resource that, under normal operations, resolves to the desired
recipient. Extensions SHOULD NOT modify the semantics of the
request URI.
Request URIは推進のための主キーです: SIPサーバで論理を進めるのは主として要求URIによります(これは要求に合格するのにRouteヘッダーフィールドを使用するSIPでの要求ルーティングから中間的プロキシまで異なっています)。 それはSIPの操作に基本的です。要求URIはそれが必要な受取人に通常操作で決議するリソースを示します。 拡大SHOULD NOTは要求URIの意味論を変更します。
Heterogeneity is the norm: SIP supports heterogeneous devices. It
has built-in mechanisms for determining the set of overlapping
protocol functionalities. Extensions SHOULD NOT be defined that
only function if all devices support the extension.
異種性は標準です: SIPは異種のデバイスを支えます。 それには、プロトコルの機能性を重ね合わせるセットを決定するための内蔵のメカニズムがあります。 拡大SHOULD NOT、定義されて、すべてのデバイスが拡大をサポートする場合にだけそれが機能するということになってください。
4. Issues to Be Addressed
4. 扱われる問題
Given an extension has met the litmus tests in the previous section, there are several issues that all extensions should take into consideration.
考えて、拡大は前項のリトマス試験を満たして、すべての拡大が考慮に入れるべきであるいくつかの問題があります。
4.1. Backward Compatibility
4.1. 後方の互換性
One of the most important issues to consider is whether the new extension is backward compatible with baseline SIP. This is tightly coupled with how the Require, Proxy-Require, and Supported header fields are used.
考える中で最も重要な問題の1つは新しい拡大が基線SIPと互換性があった状態で後方であるかどうかということです。 これがそう、しっかりRequireをどのようにに結びつけたか、Proxy必要である、そして、使用されるSupportedヘッダーフィールド。
If an extension consists of new header fields or header field parameters inserted by a user agent in a request with an existing method, and the request cannot be processed reasonably by a proxy and/or user agent without understanding the header fields or parameters, the extension MUST mandate the usage of the Require and/or Proxy-Require header fields in the request. These extensions
拡大が新しいヘッダーフィールドかヘッダーから成るならユーザエージェントによって既存のメソッドで要求に挿入されたパラメタをさばいてください、要求は、ヘッダーフィールドかパラメタ、拡大がRequireの使用法を強制しなければならないのを理解していないプロキシ、そして/または、ユーザエージェントによって合理的に処理される、そして/または、要求におけるヘッダーフィールドをProxy必要とすることができません。 これらの拡大
Rosenberg & Schulzrinne Informational [Page 7] RFC 4485 SIP Guidelines May 2006
ローゼンバーグとSchulzrinneの情報[7ページ]のRFC4485はガイドライン2006年5月にちびちび飲みます。
are not backwards compatible with SIP. The result of mandating usage of these header fields means that requests cannot be serviced unless the entities being communicated with also understand the extension. If some entity does not understand the extension, the request will be rejected. The UAC can then handle this in one of two ways. In the first, the request simply fails, and the service cannot be provided. This is basically an interoperability failure. In the second case, the UAC retries the request without the extension. This will preserve interoperability, at the cost of a "dual stack" implementation in a UAC (processing rules for operation with and without the extension). As the number of extensions increases, this leads to an exponential explosion in the sets of processing rules a UAC may need to implement. The result is excessive complexity.
後方に、SIPと互換性があった状態で、ありません。 これらのヘッダーフィールドの用法を強制するという結果は、また、コミュニケートされる実体が拡大を理解していないなら要求を修理できないことを意味します。 何らかの実体が拡大を理解していないと、要求は拒絶されるでしょう。 そして、UACは2つの方法の1つでこれを扱うことができます。 1番目では、要求は単に失敗します、そして、サービスは提供できません。 これは基本的に相互運用性失敗です。 2番目の場合では、UACは拡大なしで要求を再試行します。 これは相互運用性を保存するでしょう、UAC(拡大のあるなしにかかわらず操作のための処理規則)の「デュアルスタック」実装の費用で。 拡大の数が増加するのに従って、これはUACが実装する必要があるかもしれない処理規則のセットでの指数の爆発に通じます。 結果は過度の複雑さです。
Because of the possibility of interoperability and complexity problems that result from the usage of Require and Proxy-Require, we believe the following guidelines are appropriate:
Requireの使用法から生じる相互運用性と複雑さ問題の可能性、Proxy必要である、私たちは、以下のガイドラインが適切であると信じています:
o The usage of these header fields in requests for basic SIP
services (in particular, session initiation and termination) is
NOT RECOMMENDED. The less frequently a particular extension is
needed in a request, the more reasonable it is to use these header
fields.
o 基本的なSIPサービス(特にセッション開始と終了)を求める要求におけるこれらのヘッダーフィールドの用法はNOT RECOMMENDEDです。 特定の拡大は要求でそれほど頻繁でなく必要でなければ必要でないほど、それはこれらのヘッダーフィールドを使用するのが、より妥当です。
o The Proxy-Require header field SHOULD be avoided at all costs.
The failure likelihood in an individual proxy stays constant, but
the path failure grows exponentially with the number of hops. On
the other hand, the Require header field only mandates that a
single entity, the UAS, support the extension. Usage of
Proxy-Require is thus considered exponentially worse than usage of
the Require header field.
o ヘッダー分野SHOULDをProxy必要としてください。どんなことをしても避けられます。 個々のプロキシの失敗見込みは一定の状態で残っていますが、ホップの数に応じて、経路失敗は指数関数的に成長します。 他方では、Requireヘッダーフィールドは、単一体、UASが拡大をサポートするのを強制するだけです。 用法、Proxy必要である、Requireヘッダーフィールドの用法より指数関数的に悪いとこのようにして考えられます。
o If either Require or Proxy-Require are used by an extension, the
extension SHOULD discuss how to fall back to baseline SIP
operation if the request is rejected with a 420 response.
o Requireである、Proxy必要である、拡大で使用されて、要求が420応答で拒絶されるなら、拡大SHOULDは基線SIP操作へ後ろへ下がる方法について議論します。
Extensions that define new methods do not need to use the Require header field. SIP defines mechanisms that allow a UAC to know whether a new method is understood by a UAS. This includes both the OPTIONS request and the 405 (Method Not Allowed) response with the Allow header field. It is fundamental to SIP that proxies need not understand the semantics of a new method in order to process it. If an extension defines a new method that must be understood by proxies in order to be processed, a Proxy-Require header field is needed. As discussed above, these kinds of extensions are frowned upon.
新しいメソッドを定義する拡張子はRequireヘッダーフィールドを使用する必要はありません。 SIPはUACが、新しいメソッドがUASに解釈されるかどうかを知ることができるメカニズムを定義します。 これはAllowヘッダーフィールドがあるOPTIONSが要求する両方と405(メソッドNot Allowed)応答を含んでいます。 プロキシが必要とするSIPへの基本的がそれを処理するために新しいメソッドの意味論を理解していないということです。 拡大が新しいメソッドを定義するなら、必須が処理されるためにプロキシに解釈されて、aがヘッダーフィールドをProxy必要とするのが必要です。 上で議論するように、これらの種類の拡大は反対されます。
In order to achieve backwards compatibility for extensions that define new methods, the Allow header field is used. There are two
新しいメソッドを定義する拡大のために互換性を後方に獲得するために、Allowヘッダーフィールドは使用されています。 2があります。
Rosenberg & Schulzrinne Informational [Page 8] RFC 4485 SIP Guidelines May 2006
ローゼンバーグとSchulzrinneの情報[8ページ]のRFC4485はガイドライン2006年5月にちびちび飲みます。
types of new methods - those that are used for established dialogs (initiated by INVITE, for example), and those that are sent as the initial request to a UA. Since INVITE and its response both SHOULD contain an Allow header field, a UA can readily determine whether the new method can be supported within the dialog. For example, once an INVITE dialog is established, a user agent could determine whether the REFER method [12] is supported if it is present in an Allow header field. If it wasn't, the "transfer" button on the UI could be "greyed out" once the call is established.
新しいメソッドのタイプ--確立した対話(例えば、INVITEが開始される)に使用されるもの、および初期の要求としてUAに送られるもの。 INVITEと応答のその両方以来、SHOULDはAllowヘッダーフィールドを含んでいます、と対話の中で新しいメソッドをサポートすることができるか否かに関係なく、UAが容易に決定できます。 例えば、INVITE対話がいったん確立されると、ユーザエージェントは、それがAllowヘッダーフィールドで存在しているならREFERメソッド[12]がサポートされるかどうかと決心するかもしれません。 一度UIの上の「移し」ボタンを「外では、灰色にすることができた」ということでなかったなら、呼び出しは確立されます。
Another type of extension is that which requires a proxy to insert header fields or header field parameters into a request as it traverses the network, or for the UAS to insert header fields or header field parameters into a response. For some extensions, if the UAC or UAS does not understand these header fields, the message can still be processed correctly. These extensions are completely backwards compatible.
別のタイプの拡大はネットワークを横断するのに従ってヘッダーフィールドかヘッダーフィールドパラメタを要求に挿入するか、またはUASがヘッダーフィールドかヘッダーフィールドパラメタを応答に挿入するようにプロキシを必要とするそれです。 いくつかの拡大において、UACかUASがこれらのヘッダーフィールドを理解していないなら、メッセージをまだ正しく処理できます。 これらの拡大は完全に後方にそうです。互換性がある。
Most other extensions of this type require that the server only insert the header field or parameter if it is sure the client understands it. In this case, these extensions will need to make use of the Supported request header field mechanism. This mechanism allows a server to determine if the client can understand some extension, so that it can apply the extension to the response. By their nature, these extensions may not always be able to be applied to every response.
このタイプの他のほとんどの拡張子が、サーバがヘッダーフィールドを挿入するだけであるのを必要とするか、またはパラメタはそれが確実にクライアントであるならそれを理解しています。 この場合、これらの拡張子は、Supported要求ヘッダーフィールドメカニズムを利用する必要があるでしょう。 サーバは、このメカニズムでクライアントが何らかの拡大を理解できるかどうか決定できます、拡大を応答に適用できるように。 本質的に、これらの拡大はいつもあらゆる応答に適用できるかもしれないというわけではありません。
If an extension requires a proxy to insert a header field or parameter into a request and this header field or parameter needs to be understood by both UAC and UAS to be executed correctly, a combination of the Require and the Supported mechanism will need to be used. The proxy can insert a Require header field into the request if the Supported header field is present. An example of such an extension is the SIP Session Timer [13].
拡張子が、プロキシがヘッダーフィールドかパラメタを要求に挿入するのを必要として、このヘッダーフィールドかパラメタが、正しく実行されるためにUACとUASの両方に解釈される必要があると、Requireの組み合わせとSupportedメカニズムは、使用される必要があるでしょう。 Supportedヘッダーフィールドが存在しているなら、プロキシはRequireヘッダーフィールドを要求に挿入できます。 そのような拡大に関する例はSIP Session Timer[13]です。
Yet another type of extension is that which defines new body types to be carried in SIP messages. According to the SIP specification, bodies must be understood by user agents in order to process a request. As such, the interoperability issues are similar to new methods. However, the Content-Disposition header field has been defined to allow a client or server to indicate that the message body is optional [2]. Extensions that define or require new body types SHOULD make them optional for the user agent to process.
さらに別のタイプの拡大はSIPメッセージで運ばれるために新しいボディータイプを定義するそれです。 SIP仕様に従って、要求を処理するためにユーザエージェントにボディーを解釈しなければなりません。 そういうものとして、相互運用性問題は新しいメソッドと同様です。 しかしながら、Content-気質ヘッダーフィールドは、クライアントかサーバが、メッセージ本体が任意の[2]であることを示すのを許容するために定義されました。 ユーザエージェントが処理するように任意の状態でSHOULDが彼らをする新しいボディータイプを定義するか、または必要とする拡張子。
When a body must be understood to properly process a request or response, it is preferred that the sending entity know ahead of time whether the new body is understood by the recipient. For requests that establish a dialog, inclusion of Accept in the request and its
適切に要求か応答を処理するのをボディーを理解しなければならないとき、送付実体が、早めに新しいボディーが受取人に解釈されるかどうかを知っているのが好ましいです。 そして、対話を確立する要求、要求のAcceptの含み、それ
Rosenberg & Schulzrinne Informational [Page 9] RFC 4485 SIP Guidelines May 2006
ローゼンバーグとSchulzrinneの情報[9ページ]のRFC4485はガイドライン2006年5月にちびちび飲みます。
success responses is RECOMMENDED. This will allow both parties to determine what body types are supported by their peers. Subsequent messaging between the peers would then only include body types that were indicated as being understood.
成功応答はRECOMMENDEDです。 これで、双方は、どんなボディータイプが彼らの同輩によってサポートされるかを決定できるでしょう。 そして、同輩の間のその後のメッセージングは理解されているとして示されたボディータイプを含んでいるだけでしょう。
4.2. Security
4.2. セキュリティ
Security is an important component of any protocol. Designers of SIP extensions need to carefully consider if additional security requirements are required over those described in RFC 3261. Frequently, authorization requirements and requirements for end-to- end integrity are the most overlooked.
セキュリティはどんなプロトコルの重要な成分です。 SIP拡張子のデザイナーは、追加担保要件がRFC3261で説明されたものの上で必要であるかどうか慎重に考える必要があります。 頻繁に、終わりから終わりへの保全のための承認要件と要件は最も見落としているものです。
SIP extensions MUST consider how (or if) they affect usage of the general SIP security mechanisms. Most extensions should not require any new security capabilities beyond general-purpose SIP. If they do, it is likely that the security mechanism has more general-purpose application and should be considered an extension in its own right.
SIP拡張子は、どのようにが(or if)であるかと考えなければなりません。それらは一般的なSIPセキュリティー対策の使用法に影響します。ほとんどの拡張子が汎用SIPを超えた少しの新しいセキュリティ能力も必要とするべきではありません。 そうするなら、セキュリティー対策は、より汎用のアプリケーションを持って、それ自身の権利における拡大であると考えられそうであるべきです。
Overall system security requires that both the SIP signaling and the media sessions it established be secured. The media sessions normally use their own security techniques, which are quite distinct from those used by SIP itself. Extensions should take care not to conflate the two. However, specifications that define extensions that impact the media sessions in any way SHOULD consider the interactions between SIP and session security mechanisms.
総合体系セキュリティは、SIPシグナリングとそれが確立したメディアセッションの両方が機密保護されるのを必要とします。 通常、メディアセッションはそれら自身のセキュリティのテクニックを使用します。(テクニックはSIP自身によって使用されたものと全く異なっています)。 拡大は、2を融合しないように注意されるべきです。 しかしながら、SHOULDがSIPとセッションセキュリティー対策との相互作用を考えるどんな方法でもメディアセッションに影響を与える拡大を定義する仕様。
4.3. Terminology
4.3. 用語
RFC 3261 has an extensive terminology section that defines terms such as caller, callee, user agent, and header field. All SIP extensions MUST conform to this terminology. They MUST NOT define new terms that describe concepts already defined by a term in another SIP specification. If new terminology is needed, it SHOULD appear in a separate section towards the beginning of the document.
RFC3261には、訪問者や、訪問される人や、ユーザエージェントや、ヘッダーフィールドなどの用語を定義する大規模な用語部があります。 すべてのSIP拡張子がこの用語に従わなければなりません。 彼らは用語によって別のSIP仕様に基づき既に定義された概念について説明する新学期を定義してはいけません。 新しい用語が必要であるならそれ、SHOULDは別々のセクションでドキュメントの始まりに向かって見えます。
Careful attention must be paid to the actual usage of terminology. Many documents misuse the terms header, header field, and header field values, for example. Document authors SHOULD do a careful review of their documents for proper usage of these terms.
用語の実際の用法に慎重な注意を向けなければなりません。 多くのドキュメントが例えばヘッダーという用語、ヘッダーフィールド、およびヘッダーフィールド値を誤用します。 SHOULDがこれらの用語の適切な語法のための彼らのドキュメントの慎重なレビューをする作者を記録してください。
4.4. Syntactic Issues
4.4. 構文の問題
Extensions that define new methods SHOULD use all capitals for the method name. Method names SHOULD be shorter than 10 characters and SHOULD attempt to convey the general meaning of the request. Method names are case sensitive, and therefore, strictly speaking, they don't have to be capitalized. However, using capitalized method
新しいメソッドSHOULDを定義する拡大はメソッド名にすべての資本を使用します。 メソッドは10より背の低いキャラクタとSHOULDが要求の一般的な意味を伝える試みであったならSHOULDを命名します。 メソッド名は大文字と小文字を区別しています、そして、したがって、厳密に言うと、それらは大文字で書かれる必要はありません。 しかしながら、使用はメソッドを大文字で書きました。
Rosenberg & Schulzrinne Informational [Page 10] RFC 4485 SIP Guidelines May 2006
ローゼンバーグとSchulzrinneの情報[10ページ]のRFC4485はガイドライン2006年5月にちびちび飲みます。
names keeps with a long-standing convention in SIP and many similar protocols, such as HTTP [15] and RTSP [16].
名前はSIPの長年のコンベンションとHTTP[15]やRTSP[16]などの多くの同様のプロトコルで保たれます。
Extensions that define new header fields that are anticipated to be
heavily used MAY define a compact form if those header fields are
more than six characters. "Heavily used" means that the percentage
of all emitted messages that contain that header field is over thirty
percent. Usage of compact forms in these cases is only a MAY because
there are better approaches for reducing message overhead [20].
Compact header fields MUST be a single character. When all 26
characters are exhausted, new compact forms will no longer be
defined. Header field names are defined by the "token" production in
RFC 3261, Section 25.1, and thus include the upper and lowercase
letters, the digits 0 through 9, the HYPHEN-MINUS (-), FULL STOP (.),
EXCLAMATION MARK (!), PERCENT SIGN (%), ASTERISK (*), LOW LINE (_),
PLUS SIGN (+), GRAVE ACCENT (`), APOSTROPHE ('), and TILDE (~). They
SHOULD be descriptive but reasonably brief. Although header field
names are case insensitive, a single common capitalization SHOULD be
used throughout the document. It is RECOMMENDED that each English
word present in the header field name have its first letter
capitalized. For example, "ThisIsANewHeader".
大いに使用されるために予期される新しいヘッダーフィールドを定義する拡大はそれらのヘッダーフィールドが6つ以上のキャラクタであるならコンパクト形を定義するかもしれません。 30パーセントの上にそのヘッダーフィールドを含むすべての放たれたメッセージの割合がある「大いに使用された」手段。 メッセージオーバーヘッド[20]を下げるための、より良いアプローチがあるので、これらの場合におけるコンパクト形の使用法は5月にすぎません。 コンパクトなヘッダーフィールドは単独のキャラクタであるに違いありません。 すべての26のキャラクタが疲れ果てているとき、新しいコンパクト形はもう定義されないでしょう。 ヘッダーフィールド名は、RFC3261、セクション25.1で「トークン」生産で定義されて、その結果、0〜9に上側の、そして、小文字の手紙、ケタを含んでいます、HYPHEN-MINUS(-)、FULL STOP、()、EXCLAMATION MARK(!)、PERCENT SIGN(%)、ASTERISK(*)、LOW LINE(_)、PLUS SIGN(+)、GRAVE ACCENT、('、)、APOSTROPHE、('、)、そして、TILDE(~)、' それら、SHOULD、描写的ですが、合理的に簡潔であってください。 ヘッダーフィールドですが、名前は大文字と小文字を区別しなく、ただ一つの一般的な資源化はSHOULDです。ドキュメント中で使用されます。 ヘッダーフィールド名における現在のそれぞれの英単語で最初の手紙を大文字で書くのは、RECOMMENDEDです。 例えば、"ThisIsANewHeader"。
As an example, the following are poor choices for header field names:
例として、↓これはヘッダーフィールド名のための不十分な選択です:
ThisIsMyNewHeaderThatDoesntDoVeryMuchButItHasANiceName --.!A Function
ThisIsMyNewHeaderThatDoesntDoVeryMuchButItHasANiceName--. A機能
Case sensitivity of parameters and values is a constant source of confusion, a difficulty that plagued RFC 2543 [17]. This has been simplified through the usage of the BNF constructs of RFC 4234 [5], which have clear rules of case sensitivity and insensitivity. Therefore, the BNF for an extension completely defines the matching rules.
パラメタと値のケース感度は混乱の一定の源、RFC2543[17]を苦しめた困難です。 これはRFC4234[5]のBNF構造物の使用法で簡素化されました。(構造物には、ケース感度と無神経の明確なルールがあります)。 したがって、拡大のためのBNFは合っている規則を完全に定義します。
Extensions MUST be consistent with the SIP conventions for case sensitivity. Methods MUST be case sensitive. Header field names MUST be case insensitive. Header field parameter names MUST be case insensitive. Header field values and parameter values are sometimes case sensitive, and sometimes case insensitive. However, generally, they SHOULD be case insensitive. Defining a case-sensitive component requires explicitly listing each character through its ASCII code.
ケース感度において、拡大はSIPコンベンションと一致しているに違いありません。 メソッドは大文字と小文字を区別しているに違いありません。 ヘッダーフィールド名は大文字と小文字を区別しないに違いありません。 ヘッダーフィールドパラメタ名は大文字と小文字を区別しないに違いありません。 ヘッダーフィールド値とパラメタ値は、時々大文字と小文字を区別していて、時々大文字と小文字を区別しないです。 しかしながら、一般に、それら、SHOULD、大文字と小文字を区別しなくいてください。 大文字と小文字を区別するコンポーネントを定義するのは、ASCIIコードを通して明らかに各キャラクタを記載するのを必要とします。
Extensions that contain freeform text MUST allow that text to be UTF-8, as per the IETF policies on character set usage [3]. This ensures that SIP remains an internationalized standard. As a general guideline, freeform text is never needed by programs to perform protocol processing. It is usually entered by and displayed to the
自由形状テキストを含む拡大は、そのテキストがUTF-8であることを許容しなければなりません、文字集合用法[3]に関するIETF方針に従って。 これは、SIPが国際化している規格のままで残っているのを確実にします。 一般的ガイドラインとして、自由形状テキストは、プロトコル処理を実行するのにプログラムで決して必要ではありません。 それに通常、入って、表示します。
Rosenberg & Schulzrinne Informational [Page 11] RFC 4485 SIP Guidelines May 2006
ローゼンバーグとSchulzrinneの情報[11ページ]のRFC4485はガイドライン2006年5月にちびちび飲みます。
user. If an extension uses a parameter that can contain UTF-8- encoded characters, and that extension requires a comparison to be made of this parameter to other parameters, the comparison MUST be case sensitive. Case-insensitive comparison rules for UTF-8 text are, at this time, impossible and MUST be avoided.
ユーザ。 拡大がUTF-8でコード化されたキャラクタを含むことができて、比較がされる拡張子がこのパラメタで必要であるパラメタを他のパラメタに使用するなら、比較は大文字と小文字を区別しているに違いありません。 UTF-8テキストのための大文字と小文字を区別しない比較規則をこのとき、不可能であり、避けなければなりません。
Extensions that make use of dates MUST use the SIP-Date BNF defined in RFC 3261. No other date formats are allowed. However, the usage of absolute dates to determine intervals (for example, the time at which some timer fires) is NOT RECOMMENDED. This is because it requires synchronized time between peers, and this is frequently not the case. Therefore, relative times, expressed in numbers of seconds, SHOULD be used.
日付を利用する拡大はBNFがRFC3261で定義したSIP-日付を使用しなければなりません。 他の日付の形式は全く許容されていません。 しかしながら、間隔(例えば、あるタイマが撃たれる時間)を決定する絶対期日の用法はNOT RECOMMENDEDです。 これがそれが同輩の間で連動している時間を必要とするからである頻繁のそうではありません。 したがって、秒、SHOULDの数で言い表された相対的な時勢、使用されてください。
Extensions that include network-layer addresses SHOULD permit dotted quad IPv4 addresses, IPv6 addresses in the format described in [4], and domain names.
SHOULDが可能にするネットワーク層アドレスを含んでいる拡大が回路IPv4アドレスに点を打たせました、と形式のIPv6アドレスは[4]、およびドメイン名で説明しました。
Extensions that have header fields containing URIs SHOULD be explicit about which URI schemes can be used in that header field. Header fields SHOULD allow the broadest set of URI schemes possible that are a match for the semantics of the header field.
それがURI SHOULDを含むヘッダーフィールドが明白であることを持っているそのヘッダーフィールドにそれのURI体系を使用できる拡大。 ヘッダーフィールドSHOULDはヘッダーフィールドの意味論のためのマッチである最も広いセットの可能なURI体系を許容します。
Header fields MUST follow the standard formatting for SIP, defined as follows:
ヘッダーフィールドは以下の通り定義されたSIPのための標準の形式に続かなければなりません:
header = header-name HCOLON header-value
*(COMMA header-value)
header-name = token
header-value = value *(SEMI value-parameter)
value-parameter = token [EQUAL gen-value]
gen-value = token / host / quoted-string
value = token / host / quoted-string
ヘッダー=ヘッダー名HCOLONヘッダー価値*(COMMAヘッダー価値)ヘッダー名=トークンヘッダー価値が値*(SEMI値パラメタ)値パラメタ=トークンと等しい、[EQUAL、値に情報を得る、]、値に情報を得ている=トークン/ホスト/引用文字列値=トークン/ホスト/引用文字列
In some cases, this form is not sufficient. That is the case for header fields that express descriptive text meant for human consumption. An example is the Subject header field in SIP [2]. In this case, an alternate form is:
いくつかの場合、このフォームは十分ではありません。 それは人間の消費で意味された説明文を言い表すヘッダーフィールドのためのそうです。 例はSIP[2]のSubjectヘッダーフィールドです。 この場合、代替のフォームは以下の通りです。
header = header-name HCOLON [TEXT-UTF8-TRIM]
ヘッダー=ヘッダー名HCOLON[テキストUTF8は整えます]です。
Developers of extensions SHOULD allow for extension parameters in their header fields.
拡大SHOULDの開発者はそれらのヘッダーフィールドにおける拡大パラメタを考慮します。
Rosenberg & Schulzrinne Informational [Page 12] RFC 4485 SIP Guidelines May 2006
ローゼンバーグとSchulzrinneの情報[12ページ]のRFC4485はガイドライン2006年5月にちびちび飲みます。
Header fields that contain a list of URIs SHOULD follow the same syntax as the Contact header field in SIP. Implementors are also encouraged to wrap these URI in angle brackets, "<" and ">", at all times. We have found this to be a frequently misimplemented feature.
URI SHOULDのリストを含むヘッダーフィールドがSIPでContactヘッダーフィールドと同じ構文に従います。 また、作成者が角ブラケット、"<"、および">"でいつもこれらのURIを包装するよう奨励されます。 私たちは、これが頻繁にmisimplementedされた特徴であることがわかりました。
Beyond the compact form, there is no need to define compressed versions of header field values. Compression of SIP messages SHOULD be handled at lower layers, for example, using IP payload compression [18] or signalling compression [20].
コンパクト形を超えて、ヘッダーフィールド値の圧縮されたバージョンを定義する必要は全くありません。 例えば、下層でIPペイロード圧縮[18]を使用することで扱われるか、または圧縮[20]に合図することであるSIPメッセージSHOULDの圧縮。
Syntax for header fields is expressed in Augmented Backus-Naur Form and MUST follow the format of RFC 4234 [5]. Extensions MUST make use of the primitive components defined in RFC 3261 [2]. If the construction for a BNF element is defined in another specification, it is RECOMMENDED that the construction be referenced rather than copied. The reference SHOULD include both the document and section number. All BNF elements must be either defined or referenced.
ヘッダーフィールドのための構文は、Augmented BN記法で言い表されて、RFC4234[5]の書式に従わなければなりません。 拡大はRFC3261[2]で定義された原始のコンポーネントを利用しなければなりません。 BNF要素のための工事が別の仕様に基づき定義されるなら、工事がコピーされるよりむしろ参照をつけられるのは、RECOMMENDEDです。 参照SHOULDはドキュメントとセクション番号の両方を含んでいます。 すべてのBNF要素に定義されなければならないか、または参照をつけなければなりません。
It is RECOMMENDED that BNF be collected into a single section near the end of the document.
BNFがドキュメントの端頃に1つのセクションに集められるのは、RECOMMENDEDです。
All tokens and quoted strings are separated by explicit linear white space. Linear white space, for better or worse, allows for line folding. Extensions MUST NOT define new header fields that use alternate linear white space rules.
すべてのトークンと引用文字列は明白な直線的な余白によって切り離されます。 直線的な余白はのるかそるか系列の折り重なりを考慮します。 拡大は代替の直線的な余白規則を使用する新しいヘッダーフィールドを定義してはいけません。
All SIP extensions MUST verify that any BNF productions that they define in their grammar do not conflict with any existing grammar defined in other SIP standards-track specifications.
すべてのSIP拡張子が、それらが文法で定義するどんなBNF創作も他のSIP標準化過程仕様に基づき定義されるどんな既存の文法とも闘争しないことを確かめなければなりません。
4.5. Semantics, Semantics, Semantics
4.5. 意味論、意味論、意味論
Developers of protocols often get caught up in syntax issues, without spending enough time on semantics. The semantics of a protocol are far more important. SIP extensions MUST clearly define the semantics of the extensions. Specifically, the extension MUST specify the behaviors expected of a UAC, UAS, and proxy in processing the extension. This is often best described by having separate sections for each of these three elements. Each section SHOULD step through the processing rules in temporal order of the most common messaging scenario.
プロトコルの開発者は十分な時間を意味論で過ごすことのない構文問題でしばしば追いつかれます。 プロトコルの意味論ははるかに重要です。 SIP拡張子は明確に拡大の意味論を定義しなければなりません。 明確に、拡大は拡大を処理する際にUAC、UAS、およびプロキシに予想された振舞いを指定しなければなりません。 それぞれのこれらの3つの要素のために別々のセクションを持っていることによってこれについてしばしば説明するのは最も良いです。 各セクションSHOULDは最も一般的なメッセージングシナリオの時の注文における処理規則で踏みます。
Processing rules generally specify actions to be taken (in terms of messages to be sent, variables to be stored, and rules to be followed) on receipt of messages and expiration of timers. If an action requires transmission of a message, the rule SHOULD outline requirements for insertion of header fields or other information in the message.
一般に、処理規則は、タイマのメッセージと満了を受け取り次第取る(送られるべきメッセージ、保存されるべき変数、および続くべき規則で)ために動作を指定します。 動作がメッセージの伝達を必要とするなら、規則SHOULDはヘッダーフィールドの挿入のための要件かメッセージの他の情報について概説します。
Rosenberg & Schulzrinne Informational [Page 13] RFC 4485 SIP Guidelines May 2006
ローゼンバーグとSchulzrinneの情報[13ページ]のRFC4485はガイドライン2006年5月にちびちび飲みます。
The extension SHOULD specify procedures to be taken in exceptional conditions that are recoverable, or that require some kind of user intervention. Handling of unrecoverable errors does not require specification.
拡大SHOULDは、回復可能であるか、またはある種のユーザ介入を必要とする例外的な状態で取るために手順を指定します。 回復不能エラーの取り扱いは仕様を必要としません。
4.6. Examples Section
4.6. 例の部
The specification SHOULD contain a section that gives examples of call flows and message formatting. Extensions that define substantial new syntax SHOULD include examples of messages containing that syntax. Examples of message flows should be given to cover common cases and at least one failure or unusual case.
仕様SHOULDは呼び出し流れとメッセージ形式に関する例を出すセクションを含みます。 かなりの新しい構文SHOULDを定義する拡大がその構文を含むメッセージに関する例を含んでいます。 メッセージ流れに関する例は、少なくとも1つのよくある例と失敗か珍しいケースを含むために出されるべきです。
For an example of how to construct a good examples section, see the message flows and message formatting defined in the Basic Call Flows specification [21]. Note that complete messages SHOULD be used. Be careful to include tags, Via header fields (with the branch ID cookie), Max-Forwards, Content-Lengths, Record-Route, and Route header fields. Example INVITE messages MAY omit session descriptions, and Content-Length values MAY be set to "..." to indicate that the value is not provided. However, the specification MUST explicitly call out the meaning of the "..." and explicitly indicate that session descriptions were not included.
どう好例部を組み立てるかに関する例に関しては、メッセージ流れとメッセージ形式がBasic Call Flows仕様[21]に基づき定義されるのを見てください。 完全なメッセージSHOULDが使用されることに注意してください。 タグ、Viaヘッダーフィールド(ブランチIDクッキーがある)、前方へマックス、Content-長さ、Record-ルート、およびRouteヘッダーフィールドを含んでいるように注意してください。 値が提供されないのを示すためには「」 …に、5月がセッション記述を省略するという例のINVITEメッセージ、およびContent-長さが、評価するセットであるかもしれません」。 「しかしながら、仕様が意味から明らかに呼ばなければならない、」 … 」 セッション記述が含まれていなかったのを明らかに示してください。
4.7. Overview Section
4.7. 概要部
Too often, extension documents dive into detailed syntax and semantics without giving a general overview of operation. This makes understanding of the extension harder. It is RECOMMENDED that extensions have a protocol overview section that discusses the basic operation of the extension. Basic operation usually consists of the message flow, in temporal order, for the most common case covered by the extension. The most important processing rules for the elements in the call flow SHOULD be mentioned. Usage of the RFC 2119 [1] terminology in the overview section is NOT RECOMMENDED, and the specification should explicitly state that the overview is tutorial in nature only. This section SHOULD expand all acronyms, even those common in SIP systems, and SHOULD be understandable to readers who are not SIP experts. [27] provides additional guidance on writing good overview sections.
操作の概要を与えないで、あまりにも頻繁に、拡大ドキュメントは詳細な構文と意味論に突っ込みます。 これは、より強く拡大の協定になります。 拡大には拡大の基本的な操作について論ずるプロトコル概要部があるのは、RECOMMENDEDです。 通常、基本的な操作は拡大でカバーされる中で最も一般的なケースの時の注文におけるメッセージ流動から成ります。 最も重要な処理は、呼び出し流動SHOULDの要素のために言及されるように裁決します。 概要部のRFC2119[1]用語の用法はNOT RECOMMENDEDです、そして、仕様は概要が自然だけで家庭教師であると明らかに述べるべきです。 このセクションSHOULDはすべての頭文字語、SIPシステムで一般的なそれら、およびSHOULDさえ広げます。SIP専門家ではなく、そうする読者にとって、理解できてください。 [27]は良い概要部に書くときの追加指導を提供します。
4.8. IANA Considerations Section
4.8. IANA問題部
Documents that define new SIP extensions will invariably have IANA Considerations sections.
新しいSIP拡張子を定義するドキュメントが不変的にIANA Considerations部を持つでしょう。
If your extension is defining a new event package, you MUST register that package. RFC 3265 [6] provides the registration template. See
あなたの拡大が新しいイベントパッケージを定義しているなら、あなたはそのパッケージを登録しなければなりません。 RFC3265[6]は登録テンプレートを提供します。 見てください。
Rosenberg & Schulzrinne Informational [Page 14] RFC 4485 SIP Guidelines May 2006
ローゼンバーグとSchulzrinneの情報[14ページ]のRFC4485はガイドライン2006年5月にちびちび飲みます。
[22] for an example of the registration of a new event package. As discussed in RFC 3427 [10], only standards-track documents can register new event-template packages. Both standards-track and informational specifications can register event packages.
新しいイベントパッケージの登録に関する例のための[22]。 RFC3427[10]で議論するように、標準化過程文書だけが新しいイベントテンプレートパッケージを登録できます。 標準化過程と情報の仕様の両方がイベントパッケージを登録できます。
If your extension is defining a new header field, you MUST register that header field. RFC 3261 [2] provides a registration template. See Section 8.2 of RFC 3262 [23] for an example of how to register new SIP header fields. Both standards-track and informational P-header specifications can register new header fields [10].
あなたの拡大が新しいヘッダーフィールドを定義しているなら、あなたはそのヘッダーフィールドを示さなければなりません。 RFC3261[2]は登録テンプレートを提供します。 どう新しいSIPヘッダーフィールドを示すかに関する例のためのRFC3262[23]のセクション8.2を見てください。 標準化過程と情報のP-ヘッダー仕様の両方が新しいヘッダーフィールド[10]を示すことができます。
If your extension is defining a new response code, you MUST register that response code. RFC 3261 [2] provides a registration template. See Section 6.4 of RFC 3329 [19] for an example of how to register a new response code. As discussed in RFC 3427 [10], only standards- track documents can register new response codes.
あなたの拡大が新しい応答コードを定義しているなら、あなたはその応答コードを示さなければなりません。 RFC3261[2]は登録テンプレートを提供します。 どう新しい応答コードを示すかに関する例のためのRFC3329[19]のセクション6.4を見てください。 RFC3427[10]で議論するように、規格道のドキュメントだけが新しい応答コードを示すことができます。
If your extension is defining a new SIP method, you MUST register that method. RFC 3261 [2] provides a registration template. See Section 10 of RFC 3311 [24] for an example of how to register a new SIP method. As discussed in RFC 3427 [10], only standards-track documents can register new methods.
あなたの拡大が新しいSIPメソッドを定義しているなら、あなたはそのメソッドを登録しなければなりません。 RFC3261[2]は登録テンプレートを提供します。 どう新しいSIPメソッドを登録するかに関する例のためのRFC3311[24]のセクション10を見てください。 RFC3427[10]で議論するように、標準化過程文書だけが新しいメソッドを登録できます。
If your extension is defining a new SIP header field parameter, you MUST register that header field parameter per the guidelines in RFC 3968 [7]. Section 4.1 of that specification provides a template. Only IETF approved specifications can register new header field parameters. However, there is no requirement that these be standards track.
あなたの拡大が新しいSIPヘッダーフィールドパラメタを定義しているなら、あなたはRFC3968[7]にその1ガイドラインあたりのヘッダーフィールドパラメタを示さなければなりません。 その仕様のセクション4.1はテンプレートを提供します。 IETFだけが仕様缶のレジスタ新しいヘッダーフィールドパラメタを承認しました。 しかしながら、これらが標準化過程であるという要件が全くありません。
If your extension is defining a new SIP URI parameter, you MUST register that URI parameter per the guidelines in RFC 3969 [8]. Section 4.1 of that specification provides a template. Only standards-track documents can register new URI parameters.
あなたの拡大が新しいSIP URIパラメタを定義しているなら、あなたはRFC3969[8]にその1ガイドラインあたりのURIパラメタを示さなければなりません。 その仕様のセクション4.1はテンプレートを提供します。 標準化過程文書だけが新しいURIパラメタを示すことができます。
Many SIP extensions make use of option tags, carried in the Require, Proxy-Require, and Supported header fields. Section 4.1 discusses some of the issues involved in the usage of these header fields. If your extension does require them, you MUST register an option tag for your extension. RFC 3261 [2] provides a registration template. See Section 8.1 of RFC 3262 [23] for an example of how to register an option tag. Only standards-track RFCs can register new option tags.
オプションタグのRequireで運ばれた造の使用がProxy必要とする多くのSIP拡張子、およびSupportedヘッダーフィールド。 セクション4.1はこれらのヘッダーフィールドの用法にかかわる問題のいくつかについて論じます。 あなたの拡張子がそれらを必要とするなら、あなたはあなたの拡大のためのオプションタグを登録しなければなりません。 RFC3261[2]は登録テンプレートを提供します。 どうオプションタグを登録するかに関する例のためのRFC3262[23]のセクション8.1を見てください。 標準化過程RFCsだけが新しいオプションタグを登録できます。
Some SIP extensions will require establishment of their own IANA registries. RFC 2434 [25] provides guidance on how and when IANA registries are established. For an example of how to set one up, see Section 6 of RFC 3265 [6] for an example.
いくつかのSIP拡張子がそれら自身のIANA登録を設立に要求するでしょう。 RFC2434[25]はIANA登録が確立されるどのように、時指導を提供するか。 セットするために、1つがどう上昇するかに関する例に関しては、例のためのRFC3265[6]のセクション6を見てください。
Rosenberg & Schulzrinne Informational [Page 15] RFC 4485 SIP Guidelines May 2006
ローゼンバーグとSchulzrinneの情報[15ページ]のRFC4485はガイドライン2006年5月にちびちび飲みます。
4.9. Document-Naming Conventions
4.9. ドキュメント命名規則
An important decision to be made about the extension is its title. The title MUST indicate that the document is an extension to SIP. It is RECOMMENDED that the title follow the basic form of "A [summary of function] for the Session Initiation Protocol (SIP)", where the summary of function is a one- to three-word description of the extension. For example, if an extension defines a new header field, called Make-Coffee, for making coffee, the title would read, "Making Coffee with the Session Initiation Protocol (SIP)". It is RECOMMENDED that these additional words be descriptive rather than naming the header field. For example, the extension for making coffee should not be named "The Make-Coffee Header for the Session Initiation Protocol".
拡大に関して作られているという重要な決定はそのタイトルです。 タイトルは、ドキュメントがSIPへの拡大であることを示さなければなりません。 タイトルが機能の概要が拡大の3単語の記述への1つである「Session Initiationプロトコル(SIP)のためのA[機能の概要]」の基本的なフォームに続くのは、RECOMMENDEDです。 例えば、拡大がコーヒーを入れるためにMake-コーヒーと呼ばれる新しいヘッダーフィールドを定義するなら、タイトルは読むでしょう、「セッション開始プロトコル(一口)で、コーヒーを入れ」て。 これらの追加単語がヘッダーフィールドを命名するよりむしろ描写的であることは、RECOMMENDEDです。 例えば、「セッション開始プロトコルのためのコーヒーを入れているヘッダー」とコーヒーを入れるための拡大を命名するべきではありません。
For extensions that define new methods, an acceptable template for titles is "The Session Initiation Protocol (SIP) X Method" where X is the name of the method.
新しいメソッドを定義する拡大のために、タイトルのための許容できるテンプレートはXがメソッドの名前である「セッション開始プロトコル(一口)Xメソッド」です。
Note that the acronym SIP MUST be expanded in the titles of RFCs, as per [26].
頭文字語SIP MUSTが[26]に従ってRFCsのタイトルで広げられることに注意してください。
4.10. Additional Considerations for New Methods
4.10. 新しいメソッドのための追加問題
Extensions that define new methods SHOULD take into consideration and discuss the following issues:
新しいメソッドSHOULDを定義する拡大が、以下の問題を考慮に入れて、議論します:
o Can it contain bodies? If so, what is the meaning of the presence
of those bodies? What body types are allowed?
o それはボディーを含むことができますか? そうだとすれば、それらのボディーの存在の意味は何ですか? どんなボディータイプが許容されていますか?
o Can a transaction with this request method occur while another
transaction, in the same and/or reverse direction, is in progress?
o 別のトランザクションが同じ、そして/または、反対の方向で進行している間、この要求メソッドがあるトランザクションは起こることができますか?
o The extension MUST define which header fields can be present in
requests of that method. It is RECOMMENDED that this information
be represented as a new column of Table 2/3 of RFC 3261 [2]. The
table MUST contain rows for all header fields defined in
standards-track RFCs at the time of writing of the extension.
o 拡大は、そのメソッドの要求でどのヘッダーフィールドが存在している場合があるかを定義しなければなりません。 この情報がRFC3261[2]のTable2/3の新しいコラムとして表されるのは、RECOMMENDEDです。 テーブルは拡大を主題にして書く時点で標準化過程RFCsで定義されたすべてのヘッダーフィールドのための行を含まなければなりません。
o Can the request be sent within a dialog, or does it establish a
dialog?
o 対話の中で要求を送ることができますか、またはそれは対話を確立しますか?
o Is it a target refresh request?
o それはaです。目標は要求をリフレッシュしますか?
o Extensions to SIP that define new methods MAY specify whether
offers and answers can appear in requests of that method or its
responses. However, those extensions MUST adhere to the protocol
o 新しいメソッドを定義するSIPへの拡大は、申し出と答えがそのメソッドかその応答の要求に現れることができるかどうか指定するかもしれません。 しかしながら、それらの拡大はプロトコルを固く守らなければなりません。
Rosenberg & Schulzrinne Informational [Page 16] RFC 4485 SIP Guidelines May 2006
ローゼンバーグとSchulzrinneの情報[16ページ]のRFC4485はガイドライン2006年5月にちびちび飲みます。
rules specified in [28] and MUST adhere to the additional
constraints for offers and answers as specified in SIP [2].
規則は、[28]で指定して、SIP[2]の指定されるとしての申し出と答えの追加規制を固く守らなければなりません。
o Because of the nature of reliability treatment of requests with
new methods, those requests need to be answered immediately by the
UAS. Protocol extensions that require longer durations for the
generation of a response (such as a new method that requires human
interaction) SHOULD instead use two transactions - one to send the
request, and another in the reverse direction to convey the result
of the request. An example of that is SUBSCRIBE and NOTIFY [6].
o 新しいメソッドがある要求の信頼性の処理の本質のために、それらの要求は、すぐUASによって答えられる必要があります。 応答(人間の交流を必要とする新しいメソッドなどの)SHOULDの世代のために、より長い持続時間を必要とするプロトコル拡張子が代わりに2つのトランザクションを使用します--要求の結果を伝える反対の方向に要求、および別のものを送る1。 その例がそうである、登録、そして、NOTIFY[6]。
o The SIP specification [2] allows new methods to specify whether
transactions using that new method can be canceled using a CANCEL
request. Further study of the non-INVITE transaction [14] has
determined that non-INVITE transactions must be completed as soon
as possible. New methods must not plan for the transaction to
pend long enough for CANCEL to be meaningful. Thus, new methods
MUST declare that transactions initiated by requests with that
method cannot be canceled. Future work may relax this
restriction, at which point these guidelines will be revised.
o SIP仕様[2]はキャンセル要求を使用することでその新しいメソッドを使用するトランザクションを取り消すことができるかどうか指定する新しいメソッドを許容します。 非INVITEトランザクション[14]のさらなる研究は、非INVITE取引ができるだけ早く完了されなければならないことを決定しました。 新しいメソッドは、キャンセルのために十分長いpendへのトランザクションが重要であることを計画してはいけません。 したがって、新しいメソッドは、そのメソッドで要求で開始されたトランザクションは取り消すことができないと宣言しなければなりません。 今後の活動はこの規制を緩和するかもしれません。そのポイントでは、これらのガイドラインは改訂されるでしょう。
o New methods that establish a new dialog must discuss the impacts
of forking. The design of such new methods should follow the
pattern of requiring an immediate request in the reverse direction
from the request establishing a dialog, similar to the immediate
NOTIFY sent when a subscription is created per RFC 3265 [6].
o 新しい対話を確立する新しいメソッドは分岐の影響について議論しなければなりません。 そのような新しいメソッドのデザインは対話を確立する要求から反対の方向による即座の要求を必要とするパターンに従うべきです、購読がRFC3265[6]単位で作成されるとき送られた即座のNOTIFYと同様です。
The reliability mechanisms for all new methods must be the same as for BYE. The delayed response feature of INVITE is only available in INVITE, never for new methods. The design of new methods must encourage an immediate response. If the application being enabled requires a delay, the design SHOULD follow a pattern using multiple transactions, similar to RFC 3265's use of NOTIFYs with different Subscription-State header field values (pending and active in particular) in response to SUBSCRIBE [6].
すべての新しいメソッドのための信頼性のメカニズムはBYEのように同じであるに違いありません。 INVITEの遅延応答機能はINVITEで決してどんな新しいメソッドにも利用可能であるだけではありません。 新しいメソッドのデザインは即時型反応を奨励しなければなりません。 に対応して可能にされるアプリケーションが遅れを必要とするなら、多数の取引を使用することでデザインSHOULDはパターンに従います、異なったSubscription-州のヘッダーフィールド値が(未定で特にアクティブ)であることでNOTIFYsのRFC3265の使用と同様である、登録、[6]。
4.11. Additional Considerations for New Header Fields or Header Field
Parameters
4.11. 新しいヘッダーフィールドかヘッダーフィールドパラメタのための追加問題
The most important issue for extensions that define new header fields or header field parameters is backwards compatibility. See Section 4.1 for a discussion of the issues. The extension MUST detail how backwards compatibility is addressed.
最も重要であるのは新しいヘッダーフィールドを定義してください。さもないと、ヘッダーフィールドパラメタが後方に定義する拡大のために互換性を発行します。 問題の議論に関してセクション4.1を見てください。 拡大は、互換性がどれくらい遅れているかを扱われた状態で詳しく述べなければなりません。
It is often tempting to avoid creation of a new method by overloading an existing method through a header field or parameter. Header fields and parameters are not meant to fundamentally alter the meaning of the method of the request. A new header field cannot
それはヘッダーフィールドかパラメタを通して既存のメソッドを積みすぎることによって新しいメソッドの作成を避けるのにしばしば誘惑しています。 ヘッダーフィールドとパラメタは基本的に要求のメソッドの意味を変更することになっていません。 新しいヘッダーフィールドはそうすることができません。
Rosenberg & Schulzrinne Informational [Page 17] RFC 4485 SIP Guidelines May 2006
ローゼンバーグとSchulzrinneの情報[17ページ]のRFC4485はガイドライン2006年5月にちびちび飲みます。
change the basic semantic and processing rules of a method. There is no shortage of method names, so when an extension changes the basic meaning of a request, a new method SHOULD be defined.
メソッドの意味と処理の基本的な規則を変えてください。 メソッド名(拡大が定義されるように要求、a新しいメソッドSHOULDを意味する基礎を変えるそう)の不足が全くありません。
For extensions that define new header fields, the extension MUST define the request methods the header field can appear in, and what responses it can be used in. It is RECOMMENDED that this information be represented as a new row of Table 2/3 of RFC 3261 [2]. The table MUST contain columns for all methods defined in standards-track RFCs at the time of writing of the extension.
新しいヘッダーフィールドを定義する拡大のために、拡大は、ヘッダーフィールドが現れることができる要求メソッド、およびどんな応答にそれを使用できるかを定義しなければなりません。 この情報がRFC3261[2]のTable2/3の新しい行として表されるのは、RECOMMENDEDです。 テーブルは拡大を主題にして書く時点で標準化過程RFCsで定義されたすべてのメソッドのためのコラムを含まなければなりません。
4.12. Additional Considerations for New Body Types
4.12. 新しいボディータイプのための追加問題
Because SIP can run over UDP, extensions that specify the inclusion of large bodies (where large is several times the ethernet MTU) are frowned upon unless end-to-end congestion controlled transport can be guaranteed. If at all possible, the content SHOULD be included indirectly [9], even if congestion controlled transports are available.
SIPがUDPをひくことができるので、終わりから終わりへの混雑制御輸送を保証できないなら、大きいボディー(イーサネットMTUについて多大が何度かであるところ)の包含を指定する拡大が反対されます。 間接的に含まれていて、SHOULDを満足させてください。できれば、[9]混雑の制御輸送が利用可能であっても。
Note that the presence of a body MUST NOT change the nature of the message. That is, bodies cannot alter the state machinery associated with processing a request of a particular method or a response.
ボディーの存在がメッセージの本質を変えてはいけないことに注意してください。 すなわち、ボディーは特定のメソッドか応答の要求を処理すると関連している州の機械を変更できません。
Bodies enhance this processing by providing additional data.
ボディーは、追加データを提供することによって、この処理を機能アップします。
5. Interactions with SIP Features
5. 一口機能との相互作用
We have observed that certain capabilities of SIP continually interact with extensions in unusual ways. Writers of extensions SHOULD consider the interactions of their extensions with these SIP capabilities and document any unusual interactions, if they exist. The following are the most common causes of problems:
私たちは、SIPのある能力が絶えず珍しい方法で拡大と対話するのを観測しました。 拡大SHOULDの作家は、これらのSIP能力とドキュメントによる彼らの拡大の相互作用があらゆる珍しい相互作用であると考えます、存在しているなら。 ↓これは問題の最も一般的な原因です:
Forking: Forking by far presents the most troublesome interactions
with extensions. This is generally because it can cause (1) a
single transmitted request to be received by an unknown number of
UASes, and (2) a single INVITE request to have multiple responses.
分岐します: 分岐は拡大との最も厄介な相互作用を断然提示します。 これはそれが一般に、(1) UASesの未知の数によって受け取られるというただ一つの伝えられた要求、および(2) 複数の応答を持っているというただ一つのINVITE要求を引き起こす場合があるからです。
CANCEL and ACK: CANCEL and ACK are "special" SIP requests, in that
they are exceptions to many of the general request processing
rules. The main reason for this special status is that CANCEL and
ACK are always associated with another request. New methods
SHOULD consider the meaning of cancellation, as described above.
Extensions that define new header fields in INVITE requests SHOULD
consider whether they also need to be included in ACK and CANCEL.
Frequently they do, in order to allow a stateless proxy to route
the CANCEL or ACK identically to the INVITE.
キャンセルとACK: キャンセルとACKは、それらが一般的な要求処理規則の多くへの例外であるので、「特別な」SIP要求です。 この特別な状態の主な理由はそのキャンセルです、そして、ACKはいつも別の要求に関連しています。 新しいメソッドSHOULDは上で説明されるようにキャンセルの意味を考えます。 それらが、ACKとキャンセルに含まれる必要があるか否かに関係なくも、SHOULDが考えるINVITE要求で新しいヘッダーフィールドを定義する拡大。 頻繁に、彼らは、同様にキャンセルを発送する状態がないプロキシかACKをINVITEに許容するためにします。
Rosenberg & Schulzrinne Informational [Page 18] RFC 4485 SIP Guidelines May 2006
ローゼンバーグとSchulzrinneの情報[18ページ]のRFC4485はガイドライン2006年5月にちびちび飲みます。
Routing: The presence of Route header fields in a request can cause
it to be sent through intermediate proxies. Requests that
establish dialogs can be record-routed, so that the initial
request goes through one set of proxies, and subsequent requests
through a different set. These SIP features can interact in
unusual ways with extensions.
ルート設定: 要求における、Routeヘッダーフィールドの存在は中間的プロキシを通してそれを送らせることができます。 対話を確立する要求は記録で発送できます、初期の要求が1セットのプロキシ、および異なったセットを通したその後の要求に直面するように。 これらのSIPの特徴は拡大を伴う珍しい方法で相互作用できます。
Stateless Proxies: SIP allows a proxy to be stateless. Stateless
proxies are unable to retransmit messages and cannot execute
certain services. Extensions that depend on some kind of proxy
processing SHOULD consider how stateless proxies affect that
processing.
状態がないプロキシ: SIPは、プロキシが状態がないのを許容します。 状態がないプロキシは、メッセージを再送できないで、あるサービスを実行できません。 SHOULDを処理するある種のプロキシに頼る拡大は、状態がないプロキシがどのようにその処理に影響するかを考えます。
Dialog Usages: SIP allows for requests that normally create their own
dialog (such as SUBSCRIBE) to be used within a dialog created by
another method (such as INVITE). In such a case, there are said
to be multiple usages of that dialog. Extensions SHOULD consider
their interaction with dialog usages. In particular, extensions
that define new error response codes SHOULD describe whether that
response code causes the dialog and all usages to terminate, or
just a specific usage.
対話用法: SIPが通常、それら自身の対話を作成する要求を考慮する、(登録、)、別のメソッド(INVITEなどの)で作成された対話の中で使用されるために。 このような場合には、その対話の用法は、複数ために言われています。 拡大SHOULDは対話用法とのそれらの相互作用を考えます。 特にSHOULDが対話とすべての用法がコードで終えるその応答、またはただ特定の用法であることにかかわらず説明する新しい誤り応答コードを定義する拡大。
6. Security Considerations
6. セキュリティ問題
The nature of this document is such that it does not introduce any new security considerations. However, many of the principles described in the document affect whether a potential SIP extension design is likely to support the SIP security architecture.
このドキュメントの本質がそのようなものであるので、それはどんな新しいセキュリティ問題も紹介しません。 しかしながら、原則の多くが、ドキュメント感情で潜在的SIP拡大デザインがSIPセキュリティー体系をサポートしそうであるかどうか説明しました。
7. Acknowledgements
7. 承認
The authors would like to thank Rohan Mahy and Spencer Dawkins for their comments. Robert Sparks contributed important text on CANCEL issues. Thanks to Allison Mankin for her support.
作者は彼らのコメントについてRohanマーイとスペンサー・ダウキンズに感謝したがっています。 ロバート・スパークスはキャンセル問題に関する重要なテキストを寄付しました。 彼女のサポートをアリソン・マンキンをありがとうございます。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] 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.
[2] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[3] Alvestrand, H., "IETF Policy on Character Sets and Languages",
BCP 18, RFC 2277, January 1998.
[3]Alvestrand、H.、「文字コードと言語に関するIETF方針」、BCP18、RFC2277、1998年1月。
Rosenberg & Schulzrinne Informational [Page 19] RFC 4485 SIP Guidelines May 2006
ローゼンバーグとSchulzrinneの情報[19ページ]のRFC4485はガイドライン2006年5月にちびちび飲みます。
[4] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005.
[4]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「一般的な構文」、STD66、RFC3986、2005年1月。
[5] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[5] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
[6] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[6] ローチ、A.B.、「セッション開始プロトコル(一口)特定のイベント通知」、RFC3265、2002年6月。
[7] Camarillo, G., "The Internet Assigned Number Authority (IANA)
Header Field Parameter Registry for the Session Initiation
Protocol (SIP)", BCP 98, RFC 3968, December 2004.
[7] キャマリロ、G.、「セッション開始プロトコル(一口)のためのISOCの機関の一つで(IANA)ヘッダーフィールドパラメタ登録」、BCP98、RFC3968(2004年12月)。
[8] 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.
[8] キャマリロ、G.、「セッション開始プロトコル(一口)のためのISOCの機関の一つで(IANA)Uniform Resource Identifier(URI)パラメタ登録」、BCP99、RFC3969(2004年12月)。
[9] Burger, E., Ed., "A Mechanism for Content Indirection in Session
Initiation Protocol (SIP) Messages", RFC 4483, May 2006.
[9] バーガー、E.、エド、「セッション開始プロトコル(一口)メッセージでの満足している間接指定のためのメカニズム」、RFC4483、5月2006日
8.2. Informative References
8.2. 有益な参照
[10] 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.
[10] マンキン、A.、ブラドナー、S.、マーイ、R.、ウィリス、D.、オット、J.、およびB.ローゼンは「セッション開始プロトコル(一口)のために過程を変えます」、BCP67、RFC3427、2002年12月。
[11] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[11]Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
[12] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[12] スパークス、R.、「セッション開始プロトコル(一口)は方法を参照する」RFC3515、2003年4月。
[13] Donovan, S. and J. Rosenberg, "Session Timers in the Session
Initiation Protocol (SIP)", RFC 4028, April 2005.
[13] ドノヴァンとS.とJ.ローゼンバーグ、「セッション開始プロトコル(一口)のセッションタイマ」、RFC4028、2005年4月。
[14] Sparks, R., "Problems Identified Associated with the Session
Initiation Protocol's (SIP) Non-INVITE Transaction", RFC 4321,
January 2006.
[14] スパークス、R.、「問題はプロトコルのセッション開始ものに関連している(一口)非招待取引を特定した」RFC4321、2006年1月。
[15] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol
-- HTTP/1.1", RFC 2616, June 1999.
[15] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月。」
[16] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
1998年4月の[16]SchulzrinneとH.とラオ、A.とR.Lanphier、「リアルタイムのストリーミングのプロトコル(RTSP)」RFC2326。
Rosenberg & Schulzrinne Informational [Page 20] RFC 4485 SIP Guidelines May 2006
ローゼンバーグとSchulzrinneの情報[20ページ]のRFC4485はガイドライン2006年5月にちびちび飲みます。
[17] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg,
"SIP: Session Initiation Protocol", RFC 2543, March 1999.
[17] ハンドレー、M.、Schulzrinne、H.、学生、E.、およびJ.ローゼンバーグは「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC2543、1999年3月。
[18] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP
Payload Compression Protocol (IPComp)", RFC 3173, September
2001.
[18]Shacham、A.、Monsour、B.、ペレイラ、R.、およびM.トーマス、「IP有効搭載量圧縮プロトコル(IPComp)」、RFC3173 2001年9月。
[19] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T.
Haukka, "Security Mechanism Agreement for the Session
Initiation Protocol (SIP)", RFC 3329, January 2003.
[19]Arkko、J.、Torvinen、V.、キャマリロ、G.、Niemi、A.、およびT.Haukka、「セッション開始プロトコル(一口)のためのセキュリティー対策協定」、RFC3329(2003年1月)。
[20] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu,
Z., and J. Rosenberg, "Signaling Compression (SigComp)", RFC
3320, January 2003.
[20] 価格、R.、ボルマン、C.、Christoffersson、J.、ハンヌ、H.、リュウ、Z.、およびJ.ローゼンバーグ、「シグナリング圧縮(SigComp)」、RFC3320(2003年1月)。
[21] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K.
Summers, "Session Initiation Protocol (SIP) Basic Call Flow
Examples", BCP 75, RFC 3665, December 2003.
[21] ジョンストン、A.、ドノヴァン、S.、スパークス、R.、カニンハム、C.、およびK.夏、「セッション開始プロトコル(一口)基本的な呼び出し流れの例」、BCP75、RFC3665、2003年12月。
[22] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Registrations", RFC 3680, March 2004.
[22] ローゼンバーグ、J.、「登録証明書のためのセッション開始プロトコル(一口)イベントパッケージ」、RFC3680、2004年3月。
[23] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in Session Initiation Protocol (SIP)", RFC 3262, June
2002.
[23] ローゼンバーグとJ.とH.Schulzrinne、「セッション開始プロトコル(一口)の暫定的な応答の信頼性」、RFC3262、2002年6月。
[24] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002.
[24] ローゼンバーグ、J.、「セッション開始プロトコル(一口)アップデート方法」、RFC3311、2002年10月。
[25] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.
[25]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[26] Reynolds, J. and R. Braden, "Instructions to Request for
Comments (RFC) Authors", Work in Progress, July 2004.
[26] 「(RFC)が書くコメントのために要求する指示」というレイノルズ、J.、およびR.ブレーデンは進歩、2004年7月に働いています。
[27] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, June
2005.
[27] レスコラとE.とIAB、「書くことのプロトコルモデル」、RFC4101、2005年6月。
[28] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[28] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
Rosenberg & Schulzrinne Informational [Page 21] RFC 4485 SIP Guidelines May 2006
ローゼンバーグとSchulzrinneの情報[21ページ]のRFC4485はガイドライン2006年5月にちびちび飲みます。
Authors' Addresses
作者のアドレス
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US
ジョナサンローゼンバーグシスコシステムズ600Lanidex Plazaニュージャージー07054パーシッパニー(米国)
Phone: +1 973 952-5000 EMail: jdrosen@cisco.com URI: http://www.jdrosen.net
以下に電話をしてください。 +1 973 952-5000 メールしてください: jdrosen@cisco.com ユリ: http://www.jdrosen.net
Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027 US
ヘニングSchulzrinneコロンビア大学M/S0401 1214アムステルダムAve。 ニューヨーク、ニューヨーク10027米国
EMail: schulzrinne@cs.columbia.edu URI: http://www.cs.columbia.edu/~hgs
メール: schulzrinne@cs.columbia.edu ユリ: http://www.cs.columbia.edu/~hgs
Rosenberg & Schulzrinne Informational [Page 22] RFC 4485 SIP Guidelines May 2006
ローゼンバーグとSchulzrinneの情報[22ページ]のRFC4485はガイドライン2006年5月にちびちび飲みます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Rosenberg & Schulzrinne Informational [Page 23]
ローゼンバーグとSchulzrinne情報です。[23ページ]
一覧
スポンサーリンク
