RFC3680 日本語訳
3680 A Session Initiation Protocol (SIP) Event Package forRegistrations. J. Rosenberg. March 2004. (Format: TXT=35403 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Rosenberg Request for Comments: 3680 dynamicsoft Category: Standards Track March 2004
コメントを求めるワーキンググループJ.ローゼンバーグの要求をネットワークでつないでください: 3680dynamicsoft Category: 2004年の標準化過程行進
A Session Initiation Protocol (SIP) Event Package for Registrations
登録証明書のためのセッション開始プロトコル(一口)イベントパッケージ
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright(C)インターネット協会(2004)。 All rights reserved。
Abstract
要約
This document defines a Session Initiation Protocol (SIP) event package for registrations. Through its REGISTER method, SIP allows a user agent to create, modify, and delete registrations. Registrations can also be altered by administrators in order to enforce policy. As a result, these registrations represent a piece of state in the network that can change dynamically. There are many cases where a user agent would like to be notified of changes in this state. This event package defines a mechanism by which those user agents can request and obtain such notifications.
このドキュメントは登録証明書のためのSession Initiationプロトコル(SIP)イベントパッケージを定義します。 REGISTERメソッドで、SIPはユーザエージェントに登録証明書を作成して、変更して、削除させます。 また、管理者は、方針を実施するために登録証明書を変更できます。 その結果、これらの登録証明書はダイナミックに変化できるネットワークで1つの状態を表します。 多くのケースがユーザエージェントをこの状態の変化について通知されたいところにあります。 このイベントパッケージはそれらのユーザエージェントがそのような通知を要求して、得ることができるメカニズムを定義します。
Table of Contents
目次
1. Introduction ................................................. 2
2. Terminology .................................................. 3
3. Usage Scenarios .............................................. 3
3.1. Forcing Re-Authentication .............................. 3
3.2. Composing Presence ..................................... 3
3.3. Welcome Notices ........................................ 4
4. Package Definition ........................................... 4
4.1. Event Package Name ..................................... 4
4.2. Event Package Parameters ............................... 5
4.3. SUBSCRIBE Bodies ....................................... 5
4.4. Subscription Duration .................................. 5
4.5. NOTIFY Bodies .......................................... 6
4.6. Notifier Processing of SUBSCRIBE Requests .............. 6
4.7. Notifier Generation of NOTIFY Requests ................. 7
4.7.1. The Registration State Machine ................. 7
1. 序論… 2 2. 用語… 3 3. 用法シナリオ… 3 3.1. 再認証を強制します… 3 3.2. 存在を構成します… 3 3.3. 通知を歓迎してください… 4 4. 定義をパッケージしてください… 4 4.1. イベントパッケージ名… 4 4.2. イベントパッケージパラメタ… 5 4.3. ボディーを申し込んでください… 5 4.4. 購読持続時間… 5 4.5. ボディーに通知してください… 6 4.6. より多くのNotifierに処理する、要求を申し込んでください… 6 4.7. Notifier世代、要求に通知してください… 7 4.7.1. 登録州のマシン… 7
Rosenberg Standards Track [Page 1] RFC 3680 SIP Registrations Event March 2004
ローゼンバーグ標準化過程[1ページ]RFC3680は2004年の登録証明書イベント行進のときにちびちび飲みます。
4.7.2. Applying the state machine ..................... 9
4.8. Subscriber Processing of NOTIFY Requests ............... 9
4.9. Handling of Forked Requests ............................ 9
4.10. Rate of Notifications .................................. 10
4.11. State Agents ........................................... 10
5. Registration Information ..................................... 10
5.1. Structure of Registration Information .................. 10
5.2. Computing Registrations from the Document .............. 14
5.3. Example ................................................ 15
5.4. XML Schema ............................................. 16
6. Example Call Flow ............................................ 18
7. Security Considerations ...................................... 21
8. IANA Considerations .......................................... 21
8.1. SIP Event Package Registration ......................... 21
8.2. application/reginfo+xml MIME Registration .............. 22
8.3. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:reginfo ......................... 23
9. References ................................................... 23
9.1. Normative References ................................... 23
9.2. Informative References ................................. 24
10. Contributors ................................................. 25
11. Acknowledgements ............................................. 25
12. Author's Address ............................................. 25
13. Full Copyright Statement ..................................... 26
4.7.2. 州のマシンを適用します… 9 4.8. 加入者、処理する、要求に通知してください… 9 4.9. 股状の要求の取り扱い… 9 4.10. 通知の速度… 10 4.11. エージェントを述べてください… 10 5. 登録情報… 10 5.1. レジスト情報の構造… 10 5.2. ドキュメントから登録証明書を計算します… 14 5.3. 例… 15 5.4. XML図式… 16 6. 例の呼び出し流動… 18 7. セキュリティ問題… 21 8. IANA問題… 21 8.1. イベントパッケージ登録をちびちび飲んでください… 21 8.2アプリケーション/reginfo+xml MIME Registration… 22 8.3. つぼ:ietf:paramsのためのURN Sub-名前空間Registration: xml:ナノ秒:reginfo… 23 9. 参照… 23 9.1. 標準の参照… 23 9.2. 有益な参照… 24 10. 貢献者… 25 11. 承認… 25 12. 作者のアドレス… 25 13. 完全な著作権宣言文… 26
1. Introduction
1. 序論
The Session Initiation Protocol (SIP) [1] provides all of the functions needed for the establishment and maintenance of communications sessions between users. One of the functions it provides is a registration operation. A registration is a binding between a SIP URI, called an address-of-record, and one or more contact URIs. These contact URIs represent additional resources that can be contacted in order to reach the user identified by the address-of-record. When a proxy receives a request within its domain of administration, it uses the Request-URI as an address-of-record, and uses the contacts bound to the address-of-record to forward (or redirect) the request.
Session Initiationプロトコル(SIP)[1]は設立に必要である機能のすべてとユーザの間のコミュニケーションセッションのメインテナンスを提供します。 それが提供する機能の1つは登録操作です。 登録は記録されている住所と呼ばれるSIP URIと、1つ以上の接触URIの間の結合です。 これらの接触URIは記録されている住所によって特定されたユーザに届くように連絡できる追加リソースを表します。 プロキシが管理のドメインの中に要求を受け取るとき、それは、記録されている住所としてRequest-URIを使用して、転送する記録されている住所に制限されるのと(再直接)で接触を使用します。要求。
The SIP REGISTER method provides a way for a user agent to manipulate registrations. Contacts can be added or removed, and the current set of contacts can be queried. Registrations can also change as a result of administrator policy. For example, if a user is suspected of fraud, their registration can be deleted so that they cannot receive any requests. Registrations also expire after some time if not refreshed.
SIP REGISTERメソッドはユーザエージェントが登録証明書を操る方法を提供します。 接触を加えるか、または取り除くことができます、そして、現在の接触について質問できます。 また、登録証明書は管理者方針の結果、変化できます。 例えば、ユーザが詐欺について疑われるなら、彼らがどんな要求も受け取ることができないように、彼らの登録を削除できます。 また、リフレッシュされないなら、登録証明書はいつか後に期限が切れます。
Rosenberg Standards Track [Page 2] RFC 3680 SIP Registrations Event March 2004
ローゼンバーグ標準化過程[2ページ]RFC3680は2004年の登録証明書イベント行進のときにちびちび飲みます。
Registrations represent a dynamic piece of state maintained by the network. There are many cases in which user agents would like to know about changes to the state of registrations. The SIP Events Framework [2] defines a generic framework for subscription to, and notification of, events related to SIP systems. The framework defines the methods SUBSCRIBE and NOTIFY, and introduces the notion of a package. A package is a concrete application of the event framework to a particular class of events. Packages have been defined for user presence [9], for example. This specification defines a package for registration state.
登録証明書はネットワークによって維持されたダイナミックな状態を表します。 ユーザエージェントが登録証明書の状態への変化に関して知りたがっている多くの場合があります。 イベントはSIPシステムに関係しました。[2]が購読のためのジェネリックフレームワークを定義するSIP Events Framework、および通知、フレームワークがメソッドを定義する、登録、NOTIFY、パッケージの概念を紹介します。 パッケージは特定のクラスのイベントへのイベントフレームワークの具体的なアプリケーションです。 パッケージは例えば、ユーザ存在[9]のために定義されました。 この仕様は登録状態とパッケージを定義します。
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 BCP 14, RFC 2119 [3] and indicate requirement levels for compliant implementations.
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTが解釈されるのは中でBCP14について説明しました、RFC2119[3]ということであり、対応する実装のために要件レベルを示すべきであるかをさせましょう。
3. Usage Scenarios
3. 用法シナリオ
There are many applications of this event package. A few are documented here for illustrative purposes.
このイベントパッケージの多くの利用があります。 いくつかは説明に役立った目的のためにここに記録されます。
3.1. Forcing Re-Authentication
3.1. 再認証を強制します。
It is anticipated that many SIP devices will be wireless devices that will be always-on, and therefore, continually registered to the network. Unfortunately, history has shown that these devices can be compromised. To deal with this, an administrator will want to terminate or shorten a registration, and ask the device to re-register so it can be re-authenticated. To do this, the device subscribes to the registration event package for the address-of-record that it is registering contacts against. When the administrator shortens registration (for example, when fraud is suspected) the registration server sends a notification to the device. It can then re-register and re-authenticate itself. If it cannot re-authenticate, the expiration will terminate shortly thereafter.
多くのSIPデバイスがしたがって、そして、絶えずいつもオンで、ネットワークに登録するようになるワイヤレス機器になると予期されます。 残念ながら、歴史は、これらのデバイスに感染することができるのを示しました。 管理者は、これに対処するために、登録を終えたいか、または短くしたくて、それを再認証できるように再登録するようにデバイスに頼むでしょう。 これをするために、デバイスはそれが接触を登録している記録されている住所のための登録イベントパッケージに加入します。 管理者が登録を短くするとき(詐欺が例えば疑われるとき)、登録サーバはデバイスに通知書を送っています。 次に、それは、それ自体を再登録して、再認証できます。 再認証できないと、満了はその後、まもなく、終わるでしょう。
3.2. Composing Presence
3.2. 存在を構成します。
An important concept to understand is the relationship between this event package and the event package for user presence [9]. User presence represents the willingness and ability of a user to communicate with other users on the network. It is composed of a set of contact addresses that represent the various means for contacting the user. Those contact addresses might represent the contact address for voice, for example. Typically, the contact address
理解している重要な概念はユーザ存在[9]のためのこのイベントパッケージとイベントパッケージとの関係です。 ユーザ存在はユーザがネットワークで他のユーザとコミュニケートする意欲と能力を表します。 それはユーザに連絡するための様々な手段を表す1セットの連絡先で構成されます。 それらの連絡先は例えば、声のための連絡先を表すかもしれません。 通常連絡先
Rosenberg Standards Track [Page 3] RFC 3680 SIP Registrations Event March 2004
ローゼンバーグ標準化過程[3ページ]RFC3680は2004年の登録証明書イベント行進のときにちびちび飲みます。
listed for voice will be an address-of-record. The status of that contact (whether its open or closed) may depend on any number of factors, including the state of any registrations against that address-of-record. As a result, registration state can be viewed as an input to the process which determines the presence state of a user. Effectively, registration state is "raw" data, which is combined with other information about a user to generate a document that describes the user's presence.
声のために記載されているのは、記録されている住所でしょう。 その接触(それが開くか閉じられることにかかわらず)の状態をどんな多くの要因にも依存するかもしれません、その記録されている住所に対してどんな登録証明書の状態も含めて。 その結果、入力としてユーザの存在状態を決定するプロセスに登録状態を見なすことができます。 事実上、登録状態は「生」のデータです。(そのデータは、ユーザの存在について説明するドキュメントを作るためにユーザに関して他の情報に結合されます)。
In fact, this event package allows for a presence server to be separated from a SIP registration server, yet still use registration information to construct a presence document. When a presence server receives a presence subscription for some user, the presence server itself would generate a subscription to the registration server for the registration event package. As a result, the presence server would learn about the registration state for that user, and it could use that information to generate presence documents.
事実上、まだそれでも、このイベントパッケージで存在サーバがSIP登録サーバと切り離されるのをレジスト情報を使用して、存在ドキュメントを構成してください。 存在サーバがユーザのために存在購読を受けるとき、存在サーバ自体は登録イベントパッケージのために登録サーバの購読を生成するでしょう。 その結果、存在サーバはそのユーザのために登録状態に関して学ぶでしょう、そして、それは存在ドキュメントを作るのにその情報を使用するかもしれません。
3.3. Welcome Notices
3.3. 歓迎された通知
A common service in current mobile networks are "welcome notices". When the user turns on their phone in a foreign country, they receive a message that welcomes them to the country, and provides information on transportation services, for example.
現在のモバイルネットワークにおける共益サービスは「歓迎に気付きます」です。 ユーザが異国の空でそれらの電話をつけるとき、彼らは国にそれらを歓迎して、例えば、輸送サービスで情報を提供するメッセージを受け取ります。
In order to implement this service in a SIP system, an application server can subscribe to the registration state of the user. When the user turns on their phone, the phone will generate a registration. This will result in a notification being sent to the application that the user has registered. The application can then send a SIP MESSAGE request [10] to the device, welcoming the user and providing any necessary information.
SIPシステムでこのサービスを実装するために、アプリケーション・サーバーはユーザの登録状態に加入できます。 ユーザがそれらの電話をつけると、電話は登録を生成するでしょう。 これはユーザが登録したというアプリケーションに送られる通知をもたらすでしょう。 次に、アプリケーションはSIP MESSAGE要求[10]をデバイスに送ることができます、ユーザを歓迎して、どんな必要事項も提供して。
4. Package Definition
4. パッケージ定義
This section fills in the details needed to specify an event package as defined in Section 4.4 of [2].
このセクションは[2]のセクション4.4で定義されるようにイベントパッケージを指定するのに必要である詳細に記入します。
4.1. Event Package Name
4.1. イベントパッケージ名
The SIP Events specification requires package definitions to specify the name of their package or template-package.
SIP Events仕様は、それらのパッケージかテンプレートパッケージの名前を指定するためにパッケージ定義を必要とします。
The name of this package is "reg". As specified in [2], this value appears in the Event header present in SUBSCRIBE and NOTIFY requests.
このパッケージの名前は"reg"です。 この値が[2]で指定されるようにEventヘッダーで存在しているように見える、登録、そして、NOTIFY要求。
Rosenberg Standards Track [Page 4] RFC 3680 SIP Registrations Event March 2004
ローゼンバーグ標準化過程[4ページ]RFC3680は2004年の登録証明書イベント行進のときにちびちび飲みます。
Example:
例:
Event: reg
イベント: reg
4.2. Event Package Parameters
4.2. イベントパッケージパラメタ
The SIP Events specification requires package and template-package definitions to specify any package specific parameters of the Event header that are used by it.
SIP Events仕様はパッケージを必要とします、そして、いずれも指定するテンプレートパッケージ定義はそれによって使用されるEventヘッダーの特定のパラメタをパッケージします。
No package specific Event header parameters are defined for this event package.
どんなパッケージの特定のEventヘッダーパラメタもこのイベントパッケージのために定義されません。
4.3. SUBSCRIBE Bodies
4.3. ボディーを申し込んでください。
The SIP Events specification requires package or template-package definitions to define the usage, if any, of bodies in SUBSCRIBE requests.
SIP Events仕様が中でボディーについてもしあれば用法を定義するためにパッケージかテンプレートパッケージ定義を必要とする、登録、要求。
A SUBSCRIBE for registration events MAY contain a body. This body would serve the purpose of filtering the subscription. The definition of such a body is outside the scope of this specification.
登録は登録イベントのためにボディーを含むかもしれません。 このボディーは購読をフィルターにかける目的に役立つでしょう。 この仕様の範囲の外にそのようなボディーの定義があります。
A SUBSCRIBE for the registration package MAY be sent without a body. This implies that the default registration filtering policy has been requested. The default policy is:
ボディーなしで登録を登録パッケージのために送るかもしれません。 これは、デフォルト登録フィルタリング方針が要求されているのを含意します。 デフォルト方針は以下の通りです。
o Notifications are generated every time there is any change in
the state of any of the registered contacts for the resource
being subscribed to. Those notifications only contain
information on the contacts whose state has changed.
o いくらかの変化が加入されるリソースに関する登録された接触のどれかの状態にあるときはいつも、通知は発生しています。 それらの通知は状態が変化した接触の情報を含むだけです。
o Notifications triggered from a SUBSCRIBE contain full state
(the list of all contacts bound to the address-of-record).
o 登録から引き起こされた通知は完全な状態を含んでいます(すべての接触のリストは記録されている住所に付きました)。
Of course, the server can apply any policy it likes to the subscription.
もちろん、サーバはそれが購読に好きであるどんな方針も当てはまることができます。
4.4. Subscription Duration
4.4. 購読持続時間
The SIP Events specification requires package definitions to define a default value for subscription durations, and to discuss reasonable choices for durations when they are explicitly specified.
仕様が必要とするSIP Eventsは購読持続時間のためにデフォルト値を定義して、持続時間のための正当な選択について議論するそれらが明らかに指定されるときの定義をパッケージします。
Registration state changes as contacts are created through REGISTER requests, and then time out due to lack of refresh. Their rate of change is therefore related to the typical registration expiration. Since the default expiration for registrations is 3600 seconds, the
接触がREGISTER要求で引き起こされるとき、登録状態は変化します、そして、次に、欠けているタイムアウト支払われるべきものはリフレッシュします。 したがって、それらの増減率は典型的な登録満了に関連します。 以来、登録証明書のためのデフォルト満了は3600秒です。
Rosenberg Standards Track [Page 5] RFC 3680 SIP Registrations Event March 2004
ローゼンバーグ標準化過程[5ページ]RFC3680は2004年の登録証明書イベント行進のときにちびちび飲みます。
default duration of subscriptions to registration state is slightly longer, 3761 seconds. This helps avoid any potential problems with coupling of subscription and registration refreshes. Of course, clients MAY include an Expires header in the SUBSCRIBE request asking for a different duration.
登録状態の購読のデフォルト持続時間は3761秒にわずかに長いです。 これは、購読のカップリングのどんな潜在的な問題も避けるのを助けます、そして、登録はリフレッシュします。 もちろん、クライアントがExpiresヘッダーを入れるかもしれない、登録、異なった持続時間のための尋ねることを要求してください。
4.5. NOTIFY Bodies
4.5. ボディーに通知してください。
The SIP Events specification requires package definitions to describe the allowed set of body types in NOTIFY requests, and to specify the default value to be used when there is no Accept header in the SUBSCRIBE request.
SIP Events仕様が、Acceptヘッダーが全くないとNOTIFY要求で許容セットのボディータイプについて説明して、デフォルト値を指定するパッケージ定義が使用されているのを必要とする、登録、要求。
The body of a notification of a change in registration state contains a registration information document. This document describes some or all of the contacts associated with a particular address-of-record. All subscribers and notifiers MUST support the "application/reginfo+xml" format described in Section 5. The subscribe request MAY contain an Accept header field. If no such header field is present, it has a default value of "application/reginfo+xml". If the header field is present, it MUST include "application/reginfo+xml", and MAY include any other types capable of representing registration information.
登録状態の変化の通知のボディーはレジスト情報ドキュメントを含みます。 このドキュメントは特定の記録されている住所に関連している接触のいくつかかすべてについて説明します。 すべての加入者とnotifiersは、「アプリケーション/reginfo+xml」がセクション5で説明された形式であるとサポートしなければなりません。 5月がAcceptヘッダーフィールドを含んでいるという要求を申し込んでください。 そのような何かヘッダーフィールドが存在していないなら、それには、「アプリケーション/reginfo+xml」のデフォルト値があります。 ヘッダーフィールドが存在しているなら、それは、「アプリケーション/reginfo+xml」を含まなければならなくて、レジスト情報を表すことができるいかなる他のタイプも含むかもしれません。
Of course, the notifications generated by the server MUST be in one of the formats specified in the Accept header field in the SUBSCRIBE request.
もちろん、中でAcceptヘッダーフィールドで指定された形式の1つにはサーバによって生成された通知があるに違いない、登録、要求。
4.6. Notifier Processing of SUBSCRIBE Requests
4.6. より多くのNotifierに処理する、要求を申し込んでください。
The SIP Events framework specifies that packages should define any package-specific processing of SUBSCRIBE requests at a notifier, specifically with regards to authentication and authorization.
パッケージがどんなパッケージ詳細処理も定義するはずであるSIP Eventsフレームワークが指定する、登録、notifierでの特に認証と承認への尊敬による要求。
Registration state can be sensitive information. Therefore, all subscriptions to it SHOULD be authenticated and authorized before approval. Authentication MAY be performed using any of the techniques available through SIP, including digest, S/MIME, TLS or other transport specific mechanisms [1]. Authorization policy is at the discretion of the administrator, as always. However, a few recommendations can be made.
登録状態は機密情報であるかもしれません。 したがって、すべての購読、それに、SHOULDは認証されて、以前、承認を認可しました。 認証はSIP、包含で利用可能なテクニックのいずれも読みこなす実行された使用、S/MIME、何らかのTLSが特定のメカニズム[1]を輸送するということであるかもしれません。 管理者の裁量には承認方針がいつものようにあります。 しかしながら、いくつかの推薦状をすることができます。
It is RECOMMENDED that a user be allowed to subscribe to their own registration state. Such subscriptions are useful when there are many devices that represent a user, each of which needs to learn the registration state of the other devices. We also anticipate that applications and automata will frequently be subscribers to the
ユーザがそれら自身の登録状態に加入できるのは、RECOMMENDEDです。 ユーザの代理をして、それのそれぞれが対向機器の登録状態を学ぶ必要がある多くのデバイスがあるとき、そのような購読は役に立ちます。 また、私たちは、そのアプリケーションとオートマトンが頻繁の加入者であるために望んでいると予期します。
Rosenberg Standards Track [Page 6] RFC 3680 SIP Registrations Event March 2004
ローゼンバーグ標準化過程[6ページ]RFC3680は2004年の登録証明書イベント行進のときにちびちび飲みます。
registration state. In those cases, authorization policy will typically be provided ahead of time.
登録状態。 それらの場合では、早めに、承認方針を通常提供するでしょう。
4.7. Notifier Generation of NOTIFY Requests
4.7. Notifier世代、要求に通知してください。
The SIP Event framework requests that packages specify the conditions under which notifications are sent for that package, and how such notifications are constructed.
そのパッケージと、そのような通知がどう構成されるかために、パッケージがどの通知で状態を指定するかというSIP Eventフレームワーク要求を送ります。
To determine when a notifier should send notifications of changes in registration state, we define a finite state machine (FSM) that represents the state of a contact for a particular address-of-record. Transitions in this state machine MAY result in the generation of notifications. These notifications will carry information on the new state and the event which triggered the state change. It is important to note that this FSM is just a model of the registration state machinery maintained by a server. An implementation would map its own state machines to this one in an implementation-specific manner.
notifierがいつ登録状態の変化の通知を送るはずであるかを決定するために、私たちは特定の記録されている住所のために接触の状態を表す有限状態機械(FSM)を定義します。 この州のマシンの変遷は通知の世代で結果として生じるかもしれません。 これらの通知は州の変化の引き金となった新しい状態とイベントの情報を運ぶでしょう。 このFSMがただサーバによって維持された登録州の機械のモデルであることに注意するのは重要です。実装は実装特有の方法でそれ自身の州のマシンをこれに写像するでしょう。
4.7.1. The Registration State Machine
4.7.1. 登録州のマシン
The underlying state machine for a registration is shown in Figure 1. The machine is very simple. An instance of this machine is associated with each address-of-record. When there are no contacts registered to the address-of-record, the state machine is in the init state. It is important to note that this state machine exists, and is well-defined, for each address-of-record in the domain, even if there are no contacts registered to it. This allows a user agent to subscribe to an address-of-record, and learn that there are no contacts registered to it. When the first contact is registered to that address-of-record, the state machine moves from init to active.
登録のための基本的な州のマシンは図1で見せられます。 マシンは非常に簡単です。 このマシンのインスタンスは各記録されている住所に関連しています。 記録されている住所に登録された接触が全くないとき、州のマシンがイニット状態にあります。 この州のマシンが存在していて、明確であることに注意するのは重要です、そのドメインの各記録されている住所のために、それに登録された接触が全くなくても。 これで、ユーザエージェントを記録されている住所を購読して、それに登録された接触が全くないことを学びます。 最初の接触がその記録されている住所に登録されるとき、州のマシンはイニットからアクティブになるまで移行します。
Rosenberg Standards Track [Page 7] RFC 3680 SIP Registrations Event March 2004
ローゼンバーグ標準化過程[7ページ]RFC3680は2004年の登録証明書イベント行進のときにちびちび飲みます。
+------------+
| |
| Init |
| |
+------------+
|
V
+------------+
| |
| Active |
| |
+------------+
|
V
+------------+
| |
| Terminated |
| |
+------------+
+------------+ | | | イニット| | | +------------+ | +に対して------------+ | | | アクティブ| | | +------------+ | +に対して------------+ | | | 終わります。| | | +------------+
Figure 1: Registration State Machine
図1: 登録州のマシン
As long as there is at least one contact bound to the address-of- record, the state machine remains in the active state. When the last contact expires or is removed, the registration transitions to terminated. From there, it immediately transitions back to the init state. This transition is invisible, in that it MUST NOT ever be reported to a subscriber in a NOTIFY request.
少なくとも1つの接触がある限り、アドレスにバウンドしてください。-記録では、州のマシンは活動的な州に残っています。 最後の接触を期限が切れるか、または取り除くとき、登録は終えられるのに移行します。 そこから、それはすぐに、イニット状態に移行して戻ります。 この変遷は、かつてNOTIFY要求における加入者にそれを報告してはいけないので、目に見えません。
This allows for an implementation optimization whereby the
registrar can destroy the objects associated with the registration
state machine once it enters the terminated state and a NOTIFY has
been sent. Instead, the registrar can assume that, if the objects
for that state machine no longer exist, the state machine is in
the init state.
これはいったんそれが終えられた状態に入れて、NOTIFYを送ると記録係が登録州のマシンに関連しているオブジェクトを破壊できる実装最適化を考慮します。 代わりに、記録係は、その州のマシンのためのオブジェクトがもう存在していないなら州のマシンがイニット状態にあると仮定できます。
In addition to this state machine, each registration is associated with a set of contacts, each of which is modeled with its own state machine. Unlike the FSM for the address-of-record, which exists even when no contacts are registered, the per-contact FSM is instantiated when the contact is registered, and deleted when it is removed. The diagram for the per-contact state machine is shown in Figure 2. This FSM is identical to the registration state machine in terms of its states, but has many more transition events.
この州のマシンに加えて、それぞれの登録は1セットの接触に関連しています。それはそれ自身の州のマシンでそれぞれモデル化されます。 それを取り除くとき、接触を登録して、削除するとき、どんな接触も登録されてさえいないとき存在する記録されている住所のためのFSMと異なって、接触FSMを例示します。 1接触あたりの州のマシンのためのダイヤグラムは図2で見せられます。 このFSMには、州が登録州のマシンと同じですが、ずっと多くの変遷イベントがあります。
When a new contact is added, the FSM for it is instantiated, and it moves into the active state. Because of that, the init state here is transient. There are two ways in which it can become active. One is
新しい接触が加えられるとき、それのためのFSMは例示されます、そして、それは活動的な状態に移行します。 それのために、ここのイニット状態は一時的です。 それがアクティブになることができる2つの方法があります。 1つはそうです。
Rosenberg Standards Track [Page 8] RFC 3680 SIP Registrations Event March 2004
ローゼンバーグ標準化過程[8ページ]RFC3680は2004年の登録証明書イベント行進のときにちびちび飲みます。
through an actual SIP REGISTER request (corresponding to the registered event), and the other is when the contact is created administratively, or through some non-SIP means (the created event).
実際のSIP REGISTERを通して、(登録されたイベントとの対応)を要求して、もう片方が接触が行政上引き起こされる時であるかいくつかを通して、非SIPは(作成されたイベント)を意味します。
+------+
| | refreshed
| | shortened
V |
+------------+ +------------+ +------------+
| | | | | |
| Init |----------->| Active |----------->| Terminated |
| | | | | |
+------------+ registered +------------+ expired +------------+
created deactivated
probation
unregistered
rejected
+------+ | | リフレッシュされます。| | 短くされたV| +------------+ +------------+ +------------+ | | | | | | | イニット|、-、-、-、-、-、-、-、-、-、--、>| アクティブ|、-、-、-、-、-、-、-、-、-、--、>| 終わります。| | | | | | | +------------+は+を登録しました。------------+ 満期の+------------拒絶されて、非活性化された執行猶予登録されていない状態で作成された+
Figure 2: Contact State Machine
図2: 接触州のマシン
The FSM remains in the active state so long as the contact is bound to the address-of-record. When a contact is refreshed through a REGISTER request, the FSM stays in the same state, but a refreshed event is generated. Likewise, when an administrator modifies the expiration time of a binding (without deleting the binding) to trigger the contact to re-register and possibly re-authenticate, the FSM stays in the active state, but a shortened event is generated.
接触が記録されている住所に縛られる限り、FSMは活動的な州に残っています。 接触がREGISTER要求でリフレッシュされるとき、FSMは同じ状態にいますが、壮快なイベントは発生しています。 同様に、管理者が結合(結合を削除することのない)が再登録して、ことによると再認証する接触の引き金となる満了時間を変更すると、FSMは活動的な状態にいますが、短くされたイベントは発生しています。
When the contact is no longer bound to the address-of-record, the FSM moves to the terminated state, and once a NOTIFY is sent, the state machine is destroyed. As a result, the terminated state is effectively transient. There are several reasons this can happen. The first is an expiration, which occurs when the contact was not refreshed by a REGISTER request. The second reason is deactivated. This occurs when the administrator has removed the contact as a valid binding, but still wishes the client to attempt to re-register the contact. In contrast, the rejected event occurs when an active contact is removed by the administrator, but re-registrations will not help to re-establish it. This might occur if a user does not pay their bills, for example. The probation event occurs when an active contact is removed by the administrator, and the administrator wants the client to re-register, but to do so at a later time. The unregistered event occurs when a REGISTER request sets the expiration time of that contact to zero.
接触がもう記録されている住所に縛られないとき、FSMは終えられた状態に移行します、そして、いったんNOTIFYを送ると、州のマシンを破壊します。 その結果、事実上、終えられた状態は一時的です。 これが起こることができるいくつかの理由があります。 1番目は満了です。(接触がREGISTER要求でリフレッシュされなかったとき、その満了は起こります)。 2番目の理由は非活性化されます。 これは、管理者が有効な結合として接触を取り除いたとき、起こりますが、まだクライアントが、接触を再登録するのを試みる必要があります。 アクティブな接触が管理者によって取り除かれるとき、対照的に、拒絶されたイベントは起こりますが、再登録証明書は、それを復職させるのを助けないでしょう。 ユーザが例えばそれらの勘定を支払わないなら、これは起こるかもしれません。 アクティブな接触が管理者によって取り除かれるとき、執行猶予イベントは起こります、そして、管理者は後でそうするためにしかし、クライアントに再登録して欲しいです。 REGISTER要求がその接触の満了時間をゼロに設定すると、登録されていないイベントは起こります。
Rosenberg Standards Track [Page 9] RFC 3680 SIP Registrations Event March 2004
ローゼンバーグ標準化過程[9ページ]RFC3680は2004年の登録証明書イベント行進のときにちびちび飲みます。
4.7.2. Applying the state machine
4.7.2. 州のマシンを適用します。
The server MAY generate a notification to subscribers when any event occurs in either the address-of-record or per-contact state machines, except for the transition from terminated to init in the address-of- record state machine. As noted above, a notification MUST NOT be sent in this case. For other transitions, whether the server sends a notification or not is policy dependent. However, several guidelines are defined.
サーバはどんなイベントも記録されている住所か州が機械加工する接触のどちらかで起こる加入者に通知を生成するかもしれません、アドレスにおける終えられるのからイニットまでの変遷を除いて。-記録では、マシンを述べてください。 上で述べたように、この場合通知を送ってはいけません。 他の変遷において、サーバが通知書を送るかどうかが、方針に依存しています。 しかしながら、いくつかのガイドラインが定義されます。
As a general rule, when a subscriber is authorized to receive notifications about a set of registrations, it is RECOMMENDED that notifications contain information about those contacts which have changed state (and thus triggered a notification), instead of delivering the current state of every contact in all registrations. However, notifications triggered as a result of a fetch operation (a SUBSCRIBE with Expires of 0) SHOULD result in the full state of all contacts for all registrations to be present in the NOTIFY.
加入者が1セットの登録証明書に関する通知を受け取るのに権限を与えられるとき、概して、通知が状態(そして、その結果、通知の引き金となる)を変えたそれらの接触の情報を含んでいるのは、RECOMMENDEDです、すべての登録証明書におけるあらゆる接触の現状を提供することの代わりに。 しかしながら、通知は、フェッチ操作(0のExpiresと共に登録)の結果、すべての登録証明書がNOTIFYで現在ためにすべての接触の完全な状態でSHOULD結果の引き金となりました。
4.8. Subscriber Processing of NOTIFY Requests
4.8. 加入者、処理する、要求に通知してください。
The SIP Events framework expects packages to specify how a subscriber processes NOTIFY requests in any package specific ways, and in particular, how it uses the NOTIFY requests to construct a coherent view of the state of the subscribed resource. Typically, the NOTIFY will only contain information for contacts whose state has changed. To construct a coherent view of the total state of all registrations, the subscriber will need to combine NOTIFYs received over time. The details of this process depend on the document format used to convey registration state. Section 5 outlines the process for the application/reginfo+xml format.
SIP Eventsフレームワークは、加入者がいずれでもどうNOTIFY要求を処理するかを指定するパッケージが特定の道と、それが特に、どう、申し込まれたリソースの状態の論理的な視点を構成するというNOTIFY要求を使用するかをパッケージすると予想します。 通常、NOTIFYは状態が変化した接触のための情報を含むだけでしょう。 すべての登録証明書の総状態の論理的な視点を構成するために、加入者は、時間がたつにつれて受け取られたNOTIFYsを結合する必要があるでしょう。 このプロセスの細部は登録状態を運ぶのに使用されるドキュメント・フォーマットに依存します。 セクション5はアプリケーション/reginfo+xml形式のためにプロセスについて概説します。
4.9. Handling of Forked Requests
4.9. 股状の要求の取り扱い
The SIP Events framework mandates that packages indicate whether or not forked SUBSCRIBE requests can install multiple subscriptions.
SIP Eventsフレームワークは、分岐するか否かに関係なく、そのパッケージが示すのを強制します。登録、要求はインストール複数の購読をそうすることができます。
Registration state is normally stored in some repository (whether it be co-located with a proxy/registrar or in a separate database). As such, there is usually a single place where the contact information for a particular address-of-record is resident. This implies that a subscription for this information is readily handled by a single element with access to this repository. There is, therefore, no compelling need for a subscription to registration information to fork. As a result, a subscriber MUST NOT create multiple dialogs as a result of a single subscription request. The required processing to guarantee that only a single dialog is established is described in Section 4.4.9 of the SIP Events framework [2].
Registration state is normally stored in some repository (whether it be co-located with a proxy/registrar or in a separate database). As such, there is usually a single place where the contact information for a particular address-of-record is resident. This implies that a subscription for this information is readily handled by a single element with access to this repository. There is, therefore, no compelling need for a subscription to registration information to fork. As a result, a subscriber MUST NOT create multiple dialogs as a result of a single subscription request. The required processing to guarantee that only a single dialog is established is described in Section 4.4.9 of the SIP Events framework [2].
Rosenberg Standards Track [Page 10] RFC 3680 SIP Registrations Event March 2004
Rosenberg Standards Track [Page 10] RFC 3680 SIP Registrations Event March 2004
4.10. Rate of Notifications
4.10. Rate of Notifications
The SIP Events framework mandates that packages define a maximum rate of notifications for their package.
The SIP Events framework mandates that packages define a maximum rate of notifications for their package.
For reasons of congestion control, it is important that the rate of notifications not become excessive. As a result, it is RECOMMENDED that the server not generate notifications for a single subscriber at a rate faster than once every 5 seconds.
For reasons of congestion control, it is important that the rate of notifications not become excessive. As a result, it is RECOMMENDED that the server not generate notifications for a single subscriber at a rate faster than once every 5 seconds.
4.11. State Agents
4.11. State Agents
The SIP Events framework asks packages to consider the role of state agents in their design.
The SIP Events framework asks packages to consider the role of state agents in their design.
State agents have no role in the handling of this package.
State agents have no role in the handling of this package.
5. Registration Information
5. Registration Information
5.1. Structure of Registration Information
5.1. Structure of Registration Information
Registration information is an XML document [4] that MUST be well-formed and SHOULD be valid. Registration information documents MUST be based on XML 1.0 and MUST be encoded using UTF-8. This specification makes use of XML namespaces for identifying registration information documents and document fragments. The namespace URI for elements defined by this specification is a URN [5], using the namespace identifier 'ietf' defined by [6] and extended by [7]. This URN is:
Registration information is an XML document [4] that MUST be well-formed and SHOULD be valid. Registration information documents MUST be based on XML 1.0 and MUST be encoded using UTF-8. This specification makes use of XML namespaces for identifying registration information documents and document fragments. The namespace URI for elements defined by this specification is a URN [5], using the namespace identifier 'ietf' defined by [6] and extended by [7]. This URN is:
urn:ietf:params:xml:ns:reginfo
urn:ietf:params:xml:ns:reginfo
A registration information document begins with the root element tag "reginfo". It consists of any number of "registration" sub-elements, each of which contains the registration state for a particular address-of-record. The registration information for a particular address-of-record MUST be contained within a single "registration" element; it cannot be spread across multiple "registration" elements within a document. Other elements from different namespaces MAY be present for the purposes of extensibility; elements or attributes from unknown namespaces MUST be ignored. There are two attributes associated with the "reginfo" element, both of which MUST be present:
A registration information document begins with the root element tag "reginfo". It consists of any number of "registration" sub-elements, each of which contains the registration state for a particular address-of-record. The registration information for a particular address-of-record MUST be contained within a single "registration" element; it cannot be spread across multiple "registration" elements within a document. Other elements from different namespaces MAY be present for the purposes of extensibility; elements or attributes from unknown namespaces MUST be ignored. There are two attributes associated with the "reginfo" element, both of which MUST be present:
version: This attribute allows the recipient of registration
information documents to properly order them. Versions
start at 0, and increment by one for each new document
sent to a subscriber. Versions are scoped within a
version: This attribute allows the recipient of registration information documents to properly order them. Versions start at 0, and increment by one for each new document sent to a subscriber. Versions are scoped within a
Rosenberg Standards Track [Page 11] RFC 3680 SIP Registrations Event March 2004
Rosenberg Standards Track [Page 11] RFC 3680 SIP Registrations Event March 2004
subscription. Versions MUST be representable using a
32 bit integer.
subscription. Versions MUST be representable using a 32 bit integer.
state: This attribute indicates whether the document contains
the full registration state, or whether it contains
only information on those registrations which have
changed since the previous document (partial).
state: This attribute indicates whether the document contains the full registration state, or whether it contains only information on those registrations which have changed since the previous document (partial).
Note that the document format explicitly allows for conveying information on multiple addresses-of-record. This enables subscriptions to groups of registrations, where such a group is identified by some kind of URI. For example, a domain might define sip:allusers@example.com as a subscribable resource that generates notifications when the state of any address-of-record in the domain changes.
Note that the document format explicitly allows for conveying information on multiple addresses-of-record. This enables subscriptions to groups of registrations, where such a group is identified by some kind of URI. For example, a domain might define sip:allusers@example.com as a subscribable resource that generates notifications when the state of any address-of-record in the domain changes.
The "registration" element has a list of any number of "contact" sub-elements, each of which contains information on a single contact. Other elements from different namespaces MAY be present for the purposes of extensibility; elements or attributes from unknown namespaces MUST be ignored. There are three attributes associated with the "registration" element, all of which MUST be present:
The "registration" element has a list of any number of "contact" sub-elements, each of which contains information on a single contact. Other elements from different namespaces MAY be present for the purposes of extensibility; elements or attributes from unknown namespaces MUST be ignored. There are three attributes associated with the "registration" element, all of which MUST be present:
aor: The aor attribute contains a URI which is the address-of-
record this registration refers to.
aor: The aor attribute contains a URI which is the address-of- record this registration refers to.
id: The id attribute identifies this registration. It MUST be
unique amongst all other id attributes present in other
registration elements conveyed to the subscriber within the
scope of their subscription. In particular, if two URI
identifying an address-of-record differ after their
canonicalization according to the procedures in step 5 of
Section 10.3 of RFC 3261 [1], the id attributes in the
"registration" elements for those addresses-of-record MUST
differ. Furthermore, the id attribute for a "registration"
element for a particular address-of-record MUST be the same
across all notifications sent within the subscription.
id: The id attribute identifies this registration. It MUST be unique amongst all other id attributes present in other registration elements conveyed to the subscriber within the scope of their subscription. In particular, if two URI identifying an address-of-record differ after their canonicalization according to the procedures in step 5 of Section 10.3 of RFC 3261 [1], the id attributes in the "registration" elements for those addresses-of-record MUST differ. Furthermore, the id attribute for a "registration" element for a particular address-of-record MUST be the same across all notifications sent within the subscription.
state: The state attribute indicates the state of the
registration. The valid values are "init", "active" and
"terminated".
state: The state attribute indicates the state of the registration. The valid values are "init", "active" and "terminated".
The "contact" element contains a "uri" element, an optional "display-name" element, and an optional "unknown-param" element. Other elements from different namespaces MAY be present for the purposes of extensibility; elements or attributes from unknown namespaces MUST be ignored. There are several attributes associated with the "contact" element which MUST be present:
The "contact" element contains a "uri" element, an optional "display-name" element, and an optional "unknown-param" element. Other elements from different namespaces MAY be present for the purposes of extensibility; elements or attributes from unknown namespaces MUST be ignored. There are several attributes associated with the "contact" element which MUST be present:
Rosenberg Standards Track [Page 12] RFC 3680 SIP Registrations Event March 2004
Rosenberg Standards Track [Page 12] RFC 3680 SIP Registrations Event March 2004
id: The id attribute identifies this contact. It MUST be
unique amongst all other id attributes present in other
contact elements conveyed to the subscriber within the
scope of their subscription. In particular, if the URI for
two contacts differ (based on the URI comparison rules in
RFC 3261 [1]), the id attributes for those contacts MUST
differ. However, unlike the id attribute for an address-
of-record, if the URI for two contacts are the same, their
id attributes SHOULD be the same across notifications.
This requirement is at SHOULD strength, and not MUST
strength, since it is difficult to compute such an id as a
function of the URI without retaining additional state. No
hash function applied to the URI can, in fact, meet a MUST
requirement. This is because equality of the SIP URI is
not transitive. However, a hash function which includes
unknown URI parameters (that is, any not defined in RFC
3261), will always result in a value that is the different
if two URI are different, and usually the same if the URI
are equal.
id: The id attribute identifies this contact. It MUST be unique amongst all other id attributes present in other contact elements conveyed to the subscriber within the scope of their subscription. In particular, if the URI for two contacts differ (based on the URI comparison rules in RFC 3261 [1]), the id attributes for those contacts MUST differ. However, unlike the id attribute for an address- of-record, if the URI for two contacts are the same, their id attributes SHOULD be the same across notifications. This requirement is at SHOULD strength, and not MUST strength, since it is difficult to compute such an id as a function of the URI without retaining additional state. No hash function applied to the URI can, in fact, meet a MUST requirement. This is because equality of the SIP URI is not transitive. However, a hash function which includes unknown URI parameters (that is, any not defined in RFC 3261), will always result in a value that is the different if two URI are different, and usually the same if the URI are equal.
state: The state attribute indicates the state of the contact.
The valid values are "active" and "terminated".
state: The state attribute indicates the state of the contact. The valid values are "active" and "terminated".
event: The event attribute indicates the event which caused the
contact state machine to go into its current state. Valid
values are registered, created, refreshed, shortened,
expired, deactivated, probation, unregistered and rejected.
event: The event attribute indicates the event which caused the contact state machine to go into its current state. Valid values are registered, created, refreshed, shortened, expired, deactivated, probation, unregistered and rejected.
If the event attribute has a value of shortened, the "expires" attribute MUST be present. It contains an unsigned long integer which indicates the number of seconds remaining until the binding is due to expire. This attribute MAY be included with any event attribute value for which the state of the contact is active.
If the event attribute has a value of shortened, the "expires" attribute MUST be present. It contains an unsigned long integer which indicates the number of seconds remaining until the binding is due to expire. This attribute MAY be included with any event attribute value for which the state of the contact is active.
If the event attribute has a value of probation, the "retry-after" attribute MUST be present. It contains an unsigned long integer which indicates the amount of seconds after which the owner of the contact is expected to retry its registration.
If the event attribute has a value of probation, the "retry-after" attribute MUST be present. It contains an unsigned long integer which indicates the amount of seconds after which the owner of the contact is expected to retry its registration.
The optional "duration-registered" attribute conveys the amount of time that the contact has been bound to the address-of-record, in seconds. The optional "q" attribute conveys the relative priority of this contact compared to other registered contacts. The optional "callid" attribute contains the current Call-ID carried in the REGISTER that was last used to update this contact, and the optional "cseq" attribute contains the last CSeq value present in a REGISTER request that updated this contact value.
The optional "duration-registered" attribute conveys the amount of time that the contact has been bound to the address-of-record, in seconds. The optional "q" attribute conveys the relative priority of this contact compared to other registered contacts. The optional "callid" attribute contains the current Call-ID carried in the REGISTER that was last used to update this contact, and the optional "cseq" attribute contains the last CSeq value present in a REGISTER request that updated this contact value.
Rosenberg Standards Track [Page 13] RFC 3680 SIP Registrations Event March 2004
Rosenberg Standards Track [Page 13] RFC 3680 SIP Registrations Event March 2004
The "uri" element contains the URI associated with that contact. The "display-name" element contains the display name for the contact. The "display-name" element MAY contain the xml:lang attribute to indicate the language of the display name.
The "uri" element contains the URI associated with that contact. The "display-name" element contains the display name for the contact. The "display-name" element MAY contain the xml:lang attribute to indicate the language of the display name.
The "unknown-param" element is used to convey contact header field parameters that are not specified in RFC 3261. One example are the user agent capability parameters specified in [11]. Each "unknown- param" element describes a single contact header field parameter. The name of the parameter is contained in the mandatory name attribute of the "unknown-param" element, and the value of the parameter is the content of the "unknown-param" element. For contact header field parameters that have no value, the content of the "unknown-param" element is empty.
The "unknown-param" element is used to convey contact header field parameters that are not specified in RFC 3261. One example are the user agent capability parameters specified in [11]. Each "unknown- param" element describes a single contact header field parameter. The name of the parameter is contained in the mandatory name attribute of the "unknown-param" element, and the value of the parameter is the content of the "unknown-param" element. For contact header field parameters that have no value, the content of the "unknown-param" element is empty.
5.2. Computing Registrations from the Document
5.2. Computing Registrations from the Document
Typically, the NOTIFY for registration information will only contain information about those contacts whose state has changed. To construct a coherent view of the total state of all registrations, a subscriber will need to combine NOTIFYs received over time. The subscriber maintains a table for each registration it receives information for. Each registration is uniquely identified by the "id" attribute in the "registration" element. Each table contains a row for each contact in that registration. Each row is indexed by the unique ID for that contact. It is conveyed in the "id" attribute of the "contact" element. The contents of each row contain the state of that contact as conveyed in the "contact" element. The tables are also associated with a version number. The version number MUST be initialized with the value of the "version" attribute from the "reginfo" element in the first document received. Each time a new document is received, the value of the local version number, and the "version" attribute in the new document, are compared. If the value in the new document is one higher than the local version number, the local version number is increased by one, and the document is processed. If the value in the document is more than one higher than the local version number, the local version number is set to the value in the new document, the document is processed, and the subscriber SHOULD generate a refresh request to trigger a full state notification. If the value in the document is less than the local version, the document is discarded without processing.
Typically, the NOTIFY for registration information will only contain information about those contacts whose state has changed. To construct a coherent view of the total state of all registrations, a subscriber will need to combine NOTIFYs received over time. The subscriber maintains a table for each registration it receives information for. Each registration is uniquely identified by the "id" attribute in the "registration" element. Each table contains a row for each contact in that registration. Each row is indexed by the unique ID for that contact. It is conveyed in the "id" attribute of the "contact" element. The contents of each row contain the state of that contact as conveyed in the "contact" element. The tables are also associated with a version number. The version number MUST be initialized with the value of the "version" attribute from the "reginfo" element in the first document received. Each time a new document is received, the value of the local version number, and the "version" attribute in the new document, are compared. If the value in the new document is one higher than the local version number, the local version number is increased by one, and the document is processed. If the value in the document is more than one higher than the local version number, the local version number is set to the value in the new document, the document is processed, and the subscriber SHOULD generate a refresh request to trigger a full state notification. If the value in the document is less than the local version, the document is discarded without processing.
The processing of the document depends on whether it contains full or partial state. If it contains full state, indicated by the value of the "state" attribute in the "reginfo" element, the contents of all tables associated with this subscription are flushed. They are re-populated from the document. A new table is created for each "registration" element, and a new row in each table is created for
The processing of the document depends on whether it contains full or partial state. If it contains full state, indicated by the value of the "state" attribute in the "reginfo" element, the contents of all tables associated with this subscription are flushed. They are re-populated from the document. A new table is created for each "registration" element, and a new row in each table is created for
Rosenberg Standards Track [Page 14] RFC 3680 SIP Registrations Event March 2004
Rosenberg Standards Track [Page 14] RFC 3680 SIP Registrations Event March 2004
each "contact" element. If the reginfo contains partial state, as indicated by the value of the "state" attribute in the "reginfo" element, the document is used to update the existing tables. For each "registration" element, the subscriber checks to see if a table exists for that registration. This check is done by comparing the value in the "id" attribute of the "registration" element with the ID associated with the table. If a table doesn't exist for that registration, one is created. For each "contact" element in the registration, the subscriber checks to see whether a row exists for that contact. This check is done by comparing the ID in the "id" attribute of the "contact" element with the ID associated with the row. If the contact doesn't exist in the table, a row is added, and its state is set to the information from that "contact" element. If the contact does exist, its state is updated to be the information from that "contact" element. If a row is updated or created, such that its state is now terminated, that entry MAY be removed from the table at any time.
each "contact" element. If the reginfo contains partial state, as indicated by the value of the "state" attribute in the "reginfo" element, the document is used to update the existing tables. For each "registration" element, the subscriber checks to see if a table exists for that registration. This check is done by comparing the value in the "id" attribute of the "registration" element with the ID associated with the table. If a table doesn't exist for that registration, one is created. For each "contact" element in the registration, the subscriber checks to see whether a row exists for that contact. This check is done by comparing the ID in the "id" attribute of the "contact" element with the ID associated with the row. If the contact doesn't exist in the table, a row is added, and its state is set to the information from that "contact" element. If the contact does exist, its state is updated to be the information from that "contact" element. If a row is updated or created, such that its state is now terminated, that entry MAY be removed from the table at any time.
5.3. Example
5.3. Example
The following is an example registration information document:
The following is an example registration information document:
<?xml version="1.0"?>
<reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
version="0" state="full">
<registration aor="sip:user@example.com" id="as9"
state="active">
<contact id="76" state="active" event="registered"
duration-registered="7322"
q="0.8">
<uri>sip:user@pc887.example.com</uri>
</contact>
<contact id="77" state="terminated" event="expired"
duration-registered="3600"
q="0.5">
<uri>sip:user@university.edu</uri>
</contact>
</registration>
</reginfo>
<?xml version="1.0"?> <reginfo xmlns="urn:ietf:params:xml:ns:reginfo" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="0" state="full"> <registration aor="sip:user@example.com" id="as9" state="active"> <contact id="76" state="active" event="registered" duration-registered="7322" q="0.8"> <uri>sip:user@pc887.example.com</uri> </contact> <contact id="77" state="terminated" event="expired" duration-registered="3600" q="0.5"> <uri>sip:user@university.edu</uri> </contact> </registration> </reginfo>
Rosenberg Standards Track [Page 15] RFC 3680 SIP Registrations Event March 2004
Rosenberg Standards Track [Page 15] RFC 3680 SIP Registrations Event March 2004
5.4. XML Schema
5.4. XML Schema
The following is the schema definition of the reginfo format:
The following is the schema definition of the reginfo format:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:reginfo"
xmlns:tns="urn:ietf:params:xml:ns:reginfo"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<!-- This import brings in the XML language attribute xml:lang-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/03/xml.xsd"/>
<xs:element name="reginfo">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:registration" minOccurs="0"
maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="version" type="xs:nonNegativeInteger"
use="required"/>
<xs:attribute name="state" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="full"/>
<xs:enumeration value="partial"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:element name="registration">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:contact" minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="aor" type="xs:anyURI" use="required"/>
<xs:attribute name="id" type="xs:string" use="required"/>
<xs:attribute name="state" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="init"/>
<xs:enumeration value="active"/>
<xs:enumeration value="terminated"/>
</xs:restriction>
<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="urn:ietf:params:xml:ns:reginfo" xmlns:tns="urn:ietf:params:xml:ns:reginfo" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <!-- This import brings in the XML language attribute xml:lang--> <xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/03/xml.xsd"/> <xs:element name="reginfo"> <xs:complexType> <xs:sequence> <xs:element ref="tns:registration" minOccurs="0" maxOccurs="unbounded"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="version" type="xs:nonNegativeInteger" use="required"/> <xs:attribute name="state" use="required"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="full"/> <xs:enumeration value="partial"/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:complexType> </xs:element> <xs:element name="registration"> <xs:complexType> <xs:sequence> <xs:element ref="tns:contact" minOccurs="0" maxOccurs="unbounded"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="aor" type="xs:anyURI" use="required"/> <xs:attribute name="id" type="xs:string" use="required"/> <xs:attribute name="state" use="required"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="init"/> <xs:enumeration value="active"/> <xs:enumeration value="terminated"/> </xs:restriction>
Rosenberg Standards Track [Page 16] RFC 3680 SIP Registrations Event March 2004
Rosenberg Standards Track [Page 16] RFC 3680 SIP Registrations Event March 2004
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:element name="contact">
<xs:complexType>
<xs:sequence>
<xs:element name="uri" type="xs:anyURI"/>
<xs:element name="display-name" minOccurs="0">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="unknown-param" minOccurs="0"
maxOccurs="unbounded">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="name" type="xs:string" use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="state" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="active"/>
<xs:enumeration value="terminated"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="event" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="registered"/>
<xs:enumeration value="created"/>
<xs:enumeration value="refreshed"/>
<xs:enumeration value="shortened"/>
<xs:enumeration value="expired"/>
<xs:enumeration value="deactivated"/>
<xs:enumeration value="probation"/>
</xs:simpleType> </xs:attribute> </xs:complexType> </xs:element> <xs:element name="contact"> <xs:complexType> <xs:sequence> <xs:element name="uri" type="xs:anyURI"/> <xs:element name="display-name" minOccurs="0"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute ref="xml:lang" use="optional"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:element name="unknown-param" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="name" type="xs:string" use="required"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="state" use="required"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="active"/> <xs:enumeration value="terminated"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="event" use="required"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="registered"/> <xs:enumeration value="created"/> <xs:enumeration value="refreshed"/> <xs:enumeration value="shortened"/> <xs:enumeration value="expired"/> <xs:enumeration value="deactivated"/> <xs:enumeration value="probation"/>
Rosenberg Standards Track [Page 17] RFC 3680 SIP Registrations Event March 2004
Rosenberg Standards Track [Page 17] RFC 3680 SIP Registrations Event March 2004
<xs:enumeration value="unregistered"/>
<xs:enumeration value="rejected"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="duration-registered" type="xs:unsignedLong"/>
<xs:attribute name="expires" type="xs:unsignedLong"/>
<xs:attribute name="retry-after" type="xs:unsignedLong"/>
<xs:attribute name="id" type="xs:string" use="required"/>
<xs:attribute name="q" type="xs:string"/>
<xs:attribute name="callid" type="xs:string"/>
<xs:attribute name="cseq" type="xs:unsignedLong"/>
</xs:complexType>
</xs:element>
</xs:schema>
<xs:enumeration value="unregistered"/> <xs:enumeration value="rejected"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="duration-registered" type="xs:unsignedLong"/> <xs:attribute name="expires" type="xs:unsignedLong"/> <xs:attribute name="retry-after" type="xs:unsignedLong"/> <xs:attribute name="id" type="xs:string" use="required"/> <xs:attribute name="q" type="xs:string"/> <xs:attribute name="callid" type="xs:string"/> <xs:attribute name="cseq" type="xs:unsignedLong"/> </xs:complexType> </xs:element> </xs:schema>
6. Example Call Flow
6. Example Call Flow
User Registrar Application
| |(1) SUBSCRIBE |
| |Event:reg |
| |<------------------|
| |(2) 200 OK |
| |------------------>|
| |(3) NOTIFY |
| |------------------>|
| |(4) 200 OK |
| |<------------------|
|(5) REGISTER | |
|------------------>| |
|(6) 200 OK | |
|<------------------| |
| |(7) NOTIFY |
| |------------------>|
| |(8) 200 OK |
| |<------------------|
|(9) MESSAGE | |
|<--------------------------------------|
User Registrar Application | |(1) SUBSCRIBE | | |Event:reg | | |<------------------| | |(2) 200 OK | | |------------------>| | |(3) NOTIFY | | |------------------>| | |(4) 200 OK | | |<------------------| |(5) REGISTER | | |------------------>| | |(6) 200 OK | | |<------------------| | | |(7) NOTIFY | | |------------------>| | |(8) 200 OK | | |<------------------| |(9) MESSAGE | | |<--------------------------------------|
Figure 3: Example Call Flow
Figure 3: Example Call Flow
Rosenberg Standards Track [Page 18] RFC 3680 SIP Registrations Event March 2004
Rosenberg Standards Track [Page 18] RFC 3680 SIP Registrations Event March 2004
This section provides an example call flow, shown in Figure 3. It shows an implementation of the welcome notice application described in Section 3.3. First, the application SUBSCRIBEs to the registration event package for the desired user (1):
This section provides an example call flow, shown in Figure 3. It shows an implementation of the welcome notice application described in Section 3.3. First, the application SUBSCRIBEs to the registration event package for the desired user (1):
SUBSCRIBE sip:joe@example.com SIP/2.0 Via: SIP/2.0/UDP app.example.com;branch=z9hG4bKnashds7 From: sip:app.example.com;tag=123aa9 To: sip:joe@example.com Call-ID: 9987@app.example.com CSeq: 9887 SUBSCRIBE Contact: sip:app.example.com Event: reg Max-Forwards: 70 Accept: application/reginfo+xml
SUBSCRIBE sip:joe@example.com SIP/2.0 Via: SIP/2.0/UDP app.example.com;branch=z9hG4bKnashds7 From: sip:app.example.com;tag=123aa9 To: sip:joe@example.com Call-ID: 9987@app.example.com CSeq: 9887 SUBSCRIBE Contact: sip:app.example.com Event: reg Max-Forwards: 70 Accept: application/reginfo+xml
The registrar (which is acting as the notifier for the registration event package) generates a 200 OK to the SUBSCRIBE:
The registrar (which is acting as the notifier for the registration event package) generates a 200 OK to the SUBSCRIBE:
SIP/2.0 200 OK
Via: SIP/2.0/UDP app.example.com;branch=z9hG4bKnashds7
;received=192.0.2.1
From: sip:app.example.com;tag=123aa9
To: sip:joe@example.com;tag=xyzygg
Call-ID: 9987@app.example.com
CSeq: 9987 SUBSCRIBE
Contact: sip:server19.example.com
Expires: 3600
SIP/2.0 200 OK Via: SIP/2.0/UDP app.example.com;branch=z9hG4bKnashds7 ;received=192.0.2.1 From: sip:app.example.com;tag=123aa9 To: sip:joe@example.com;tag=xyzygg Call-ID: 9987@app.example.com CSeq: 9987 SUBSCRIBE Contact: sip:server19.example.com Expires: 3600
The registrar then generates a notification (3) with the current state. Since there is no active registration, the state of the registration is "init":
The registrar then generates a notification (3) with the current state. Since there is no active registration, the state of the registration is "init":
NOTIFY sip:app.example.com SIP/2.0 Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaii From: sip:joe@example.com;tag=xyzygg To: sip:app.example.com;tag=123aa9 Call-ID: 9987@app.example.com CSeq: 1288 NOTIFY Contact: sip:server19.example.com Event: reg Max-Forwards: 70 Content-Type: application/reginfo+xml Content-Length: ...
NOTIFY sip:app.example.com SIP/2.0 Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaii From: sip:joe@example.com;tag=xyzygg To: sip:app.example.com;tag=123aa9 Call-ID: 9987@app.example.com CSeq: 1288 NOTIFY Contact: sip:server19.example.com Event: reg Max-Forwards: 70 Content-Type: application/reginfo+xml Content-Length: ...
Rosenberg Standards Track [Page 19] RFC 3680 SIP Registrations Event March 2004
Rosenberg Standards Track [Page 19] RFC 3680 SIP Registrations Event March 2004
<?xml version="1.0"?>
<reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
version="0" state="full">
<registration aor="sip:joe@example.com" id="a7" state="init" />
</reginfo>
<?xml version="1.0"?> <reginfo xmlns="urn:ietf:params:xml:ns:reginfo" version="0" state="full"> <registration aor="sip:joe@example.com" id="a7" state="init" /> </reginfo>
Later on, the user registers (5):
Later on, the user registers (5):
REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/UDP pc34.example.com;branch=z9hG4bKnaaff From: sip:joe@example.com;tag=99a8s To: sip:joe@example.com Call-ID: 88askjda9@pc34.example.com CSeq: 9976 REGISTER Contact: sip:joe@pc34.example.com
REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/UDP pc34.example.com;branch=z9hG4bKnaaff From: sip:joe@example.com;tag=99a8s To: sip:joe@example.com Call-ID: 88askjda9@pc34.example.com CSeq: 9976 REGISTER Contact: sip:joe@pc34.example.com
This results in a NOTIFY being generated to the application (7):
This results in a NOTIFY being generated to the application (7):
NOTIFY sip:app.example.com SIP/2.0 Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaij From: sip:joe@example.com;tag=xyzygg To: sip:app.example.com;tag=123aa9 Call-ID: 9987@app.example.com CSeq: 1289 NOTIFY Contact: sip:server19.example.com Event: reg Max-Forwards: 70 Content-Type: application/reginfo+xml Content-Length: ...
NOTIFY一口: app.example.com SIP/2.0Via: 一口/2.0/UDP server19.example.com; ブランチ=z9hG4bKnasaij From: 一口: joe@example.com;tag はxyzygg To:と等しいです。 一口: app.example.com; =123aa9 Call IDにタグ付けをしてください: 9987@app.example.com CSeq: 1289は接触に通知します: 一口: server19.example.com Event: 前方へregマックス: 70コンテントタイプ: アプリケーション/reginfo+xml Content長さ: ...
<?xml version="1.0"?>
<reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
version="1" state="partial">
<registration aor="sip:joe@example.com" id="a7" state="active">
<contact id="76" state="active" event="registered"
duration-registered="0">
<uri>sip:joe@pc34.example.com</uri>
</contact>
</registration>
</reginfo>
<?xmlバージョン= 「1インチ?」「アクティブな」アクティブな「><連絡イド=」76インチが述べる「a7"状態=」=イベント=が「登録した」「部分的な「><登録aor=」一口: 「1インチの状態=」という><reginfo xmlns=「つぼ:ietf:params:xml:ナノ秒: reginfo」バージョン= joe@example.com 」イド=が=を持続時間で登録した、「0インチの><uri>一口: joe@pc34.example.com 、lt;、/uri></接触></登録></reginfo>、」
Rosenberg Standards Track [Page 20] RFC 3680 SIP Registrations Event March 2004
ローゼンバーグ標準化過程[20ページ]RFC3680は2004年の登録証明書イベント行進のときにちびちび飲みます。
The application can then send its instant message to the device (9):
次に、アプリケーションはデバイス(9)にインスタントメッセージを送ることができます:
MESSAGE sip:joe@pc34.example.com SIP/2.0 Via: SIP/2.0/UDP app.example.com;branch=z9hG4bKnashds8 From: sip:app.example.com;tag=123aa10 To: sip:joe@example.com Call-ID: 9988@app.example.com CSeq: 82779 MESSAGE Max-Forwards: 70 Content-Type: text/plain Content-Length: ...
MESSAGE一口: joe@pc34.example.com SIP/2.0Via: 一口/2.0/UDP app.example.com; ブランチ=z9hG4bKnashds8From: 一口: app.example.com; =123aa10To:にタグ付けをしてください。 一口: joe@example.com Call-ID: 9988@app.example.com CSeq: 82779 前方へMESSAGEマックス: 70コンテントタイプ: テキスト/明瞭なContent-長さ: ...
Welcome to the example.com service!
example.comサービスへようこそ!
7. Security Considerations
7. セキュリティ問題
Security considerations for SIP event packages are discussed in RFC 3265 [2], and those considerations apply here.
RFC3265[2]でSIPイベントパッケージのためのセキュリティ問題について議論します、そして、それらの問題はここに適用されます。
Registration information is sensitive, potentially private, information. Subscriptions to this event package SHOULD be authenticated and authorized according to local policy. Some policy guidelines are suggested in Section 4.6. In addition, notifications SHOULD be sent in such a way to ensure confidentiality, message integrity and verification of subscriber identity, such as sending subscriptions and notifications using a SIPS URL or protecting the notification bodies with S/MIME.
レジスト情報は敏感で、潜在的に個人的な情報です。 このイベントの購読は認証されて、ローカルの方針によると、認可されたSHOULDをパッケージします。 いくつかの政策文書がセクション4.6に示されます。 追加、SIPS URLを使用することで購読と通知を送ることなどの加入者のアイデンティティの秘密性、メッセージの保全、および検証を確実にするそのような方法を送るか、またはS/MIMEで通知本体を保護することである通知SHOULDで。
8. IANA Considerations
8. IANA問題
This document registers a new SIP Event Package, a new MIME type (application/reginfo+xml), and a new XML namespace.
このドキュメントは新しいSIP Eventパッケージ、新しいMIMEの種類(アプリケーション/reginfo+xml)、および新しいXML名前空間を登録します。
8.1. SIP Event Package Registration
8.1. 一口イベントパッケージ登録
Package name: reg
名前をパッケージしてください: reg
Type: package
以下をタイプしてください。 パッケージ
Contact: Jonathan Rosenberg, <jdrosen@jdrosen.net>
接触: ジョナサン・ローゼンバーグ、 <jdrosen@jdrosen.net 、gt。
Published Specification: RFC 3680.
広められた仕様: RFC3680。
Rosenberg Standards Track [Page 21] RFC 3680 SIP Registrations Event March 2004
ローゼンバーグ標準化過程[21ページ]RFC3680は2004年の登録証明書イベント行進のときにちびちび飲みます。
8.2. application/reginfo+xml MIME Registration
8.2. アプリケーション/reginfo+xml MIME Registration
MIME media type name: application
MIMEメディア型名: アプリケーション
MIME subtype name: reginfo+xml
MIME「副-タイプ」は以下を命名します。 reginfo+xml
Mandatory parameters: none
義務的なパラメタ: なし
Optional parameters: Same as charset parameter application/xml
as specified in RFC 3023 [8].
任意のパラメタ: RFC3023[8]の指定されるとしてのcharsetパラメタアプリケーション/xmlと同じです。
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [8].
問題をコード化します: RFC3023[8]の指定されるとしてのアプリケーション/xmlの問題をコード化するのと同じです。
Security considerations: See Section 10 of RFC 3023 [8] and
Section 7 of this specification.
セキュリティ問題: RFC3023[8]のセクション10とこの仕様のセクション7を見てください。
Interoperability considerations: none.
相互運用性問題: なし。
Published specification: This document.
広められた仕様: このドキュメント。
Applications which use this media type: This document type is
being used in notifications to alert SIP user agents that
their registrations have expired and must be redone.
このメディアタイプを使用するアプリケーション: このドキュメントタイプを彼らの登録証明書が期限が切れたとSIPユーザエージェントに警告するのに通知で使用されていて、やり直さなければなりません。
Additional Information:
追加情報:
Magic Number: None
マジックナンバー: なし
File Extension: .rif or .xml
ファイル拡張子: .rifか.xml
Macintosh file type code: "TEXT"
マッキントッシュファイルの種類コード: 「テキスト」
Personal and email address for further information: Jonathan
Rosenberg, <jdrosen@jdrosen.net>
詳細のためのパーソナルとEメールアドレス: ジョナサン・ローゼンバーグ、 <jdrosen@jdrosen.net 、gt。
Intended usage: COMMON
意図している用法: 一般的
Author/Change controller: The IETF.
コントローラを書くか、または変えてください: IETF。
Rosenberg Standards Track [Page 22] RFC 3680 SIP Registrations Event March 2004
ローゼンバーグ標準化過程[22ページ]RFC3680は2004年の登録証明書イベント行進のときにちびちび飲みます。
8.3. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:reginfo
8.3. つぼ:ietf:paramsのためのURN Sub-名前空間Registration: xml:ナノ秒:reginfo
This section registers a new XML namespace, as per the guidelines in [7].
このセクションは[7]のガイドラインに従って新しいXML名前空間を登録します。
URI: The URI for this namespace is
urn:ietf:params:xml:ns:reginfo.
URI: この名前空間のためのURIはつぼ:ietf:paramsです: xml:ナノ秒:reginfo。
Registrant Contact: IETF, SIMPLE working group,
<simple@ietf.org>, Jonathan Rosenberg
<jdrosen@jdrosen.net>.
記入者接触: IETF、SIMPLEワーキンググループ、 <simple@ietf.org 、gt;、ジョナサン Rosenberg <jdrosen@jdrosen.net 、gt。
XML:
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Registration Information Namespace</title>
</head>
<body>
<h1>Namespace for Registration Information</h1>
<h2>urn:ietf:params:xml:ns:reginfo</h2>
<p>See <a href="ftp://ftp.rfc-editor.org/in-notes/rfc3680.txt">
RFC3680</a>.</p>
</body>
</html>
END
BEGIN<?xmlバージョン= 「1インチ?」><!DOCTYPE html PUBLIC「-//W3C//DTD XHTML基礎1.0//アン」、「 http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd 「><html xmlns=「 http://www.w3.org/1999/xhtml 「><ヘッド><メタhttp-equiv=」content type」」; 内容が等しい、「テキスト/html;、charset=iso8859、1インチ、Registration情報</h1><h2>つぼのための/><タイトル>Registration情報Namespace</タイトル></ヘッド><ボディー><h1>Namespace:、」; ietf:params:xml:ナノ秒:reginfo</h2><p>See<a hrefが等しい、「 ftp://ftp.rfc-editor.org/in-notes/rfc3680.txt 「>RFC3680</a>。」; </p></ボディー></html>エンド
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[1] 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.
[1] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[2] ローチ、A.、「セッション開始プロトコル(一口)特定のイベント通知」、RFC3265、2002年6月。
[3] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", BCP 14, RFC 2119, March 1997.
[3] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。
Rosenberg Standards Track [Page 23] RFC 3680 SIP Registrations Event March 2004
ローゼンバーグ標準化過程[23ページ]RFC3680は2004年の登録証明書イベント行進のときにちびちび飲みます。
[4] W. W. W. C. (W3C), "Extensible markup language (xml) 1.0." The
XML 1.0 spec can be found at
http://www.w3.org/TR/1998/REC-xml-19980210.
[4] W.W.W.C.(W3C)、「エクステンシブルマークアップランゲージ(xml)1.0。」 http://www.w3.org/TR/1998/REC-xml-19980210 でXML1.0仕様を見つけることができます。
[5] Moats, R., "URN Syntax", RFC 2141, May 1997.
[5]堀(R.、「つぼの構文」、RFC2141)は1997がそうするかもしれません。
[6] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
August 1999.
[6] モウツ、R.、「IETFドキュメントのためのつぼの名前空間」、RFC2648、1999年8月。
[7] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January
2004.
[7] 食事、M.、「IETF XML登録」、BCP81、RFC3688、2004年1月。
[8] Murata, M., St. Laurent, S. and D. Kohn, "XML media types", RFC
3023, January 2001.
[8] ムラタとM.と聖ローランとS.とD.コーン、「XMLメディアタイプ」、RFC3023、2001年1月。
9.2. Informative References
9.2. 有益な参照
[9] Rosenberg, J., "Session initiation protocol (SIP) extensions for
presence", Work In Progress.
[9] ローゼンバーグ、J.、「存在のためのセッション開始プロトコル(SIP)拡大」、Work In Progress。
[10] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and D.
Gurle, "Session Initiation Protocol (SIP) Extension for Instant
Messaging", RFC 3428, December 2002.
[10] キャンベルとB.とローゼンバーグとJ.とSchulzrinneとH.、HuitemaとC.とD.Gurle、「インスタントメッセージングのためのセッション開始プロトコル(一口)拡大」RFC3428(2002年12月)。
[11] Schulzrinne, H. and J. Rosenberg, "Session initiation protocol
(SIP) caller preferences and callee capabilities", Work In
Progress.
[11]SchulzrinneとH.とJ.ローゼンバーグ、「セッション開始は(SIP)訪問者好みと訪問される人能力について議定書の中で述べる」Work In Progress。
[12] Mayer, G. and M. Beckmann, "Registration event package", Work In
Progress.
[12] マイヤーとG.とM.Beckmann、「登録イベントパッケージ」、Work In Progress。
Rosenberg Standards Track [Page 24] RFC 3680 SIP Registrations Event March 2004
ローゼンバーグ標準化過程[24ページ]RFC3680は2004年の登録証明書イベント行進のときにちびちび飲みます。
10. Contributors
10. 貢献者
This document is based heavily on the registration event package originally proposed by Beckmann and Mayer in [12]. They can be contacted at:
このドキュメントはずっしりと元々[12]でBeckmannとマイヤーによって提案された登録イベントパッケージに基づいています。 以下でそれらに連絡できます。
Georg Mayer Siemens AG Hoffmannstr. 51 Munich 81359 Germany
ゲオルクマイヤージーメンス株式会社Hoffmannstr。 51 ミュンヘン81359ドイツ
EMail: Georg.Mayer@icn.siemens.de
メール: Georg.Mayer@icn.siemens.de
Mark Beckmann Siemens AG P.O. Box 100702 Salzgitter 38207 Germany
マークBeckmannジーメンス株式会社私書箱100702ザルツギター38207ドイツ
EMail: Mark.Beckmann@siemens.com
メール: Mark.Beckmann@siemens.com
Rohan Mahy provided editorial work in order to progress this specification. His contact address is:
Rohanマーイは、この仕様を進行するように編集の仕事を提供しました。 彼の連絡先は以下の通りです。
Rohan Mahy Cisco Systems 170 West Tasman Dr, MS: SJC-21/3/3
Rohanマーイシスコシステムズ170の西タスマン博士、MS: SJC-21/3/3
Phone: +1 408 526 8570 EMail: rohan@cisco.com
以下に電話をしてください。 +1 8570年の408 526メール: rohan@cisco.com
11. Acknowledgements
11. 承認
We would like to thank Dean Willis for his support.
彼のサポートについてディーン・ウィリスに感謝申し上げます。
12. Author's Address
12. 作者のアドレス
Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054
Lanidex Plazaパーシッパニー、ジョナサンローゼンバーグdynamicsoft600ニュージャージー 07054
EMail: jdrosen@dynamicsoft.com
メール: jdrosen@dynamicsoft.com
Rosenberg Standards Track [Page 25] RFC 3680 SIP Registrations Event March 2004
ローゼンバーグ標準化過程[25ページ]RFC3680は2004年の登録証明書イベント行進のときにちびちび飲みます。
13. Full Copyright Statement
13. 完全な著作権宣言文
Copyright (C) The Internet Society (2004). 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.
Copyright(C)インターネット協会(2004)。 このドキュメントは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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Rosenberg Standards Track [Page 26]
ローゼンバーグ標準化過程[26ページ]
一覧
スポンサーリンク
