[要約] RFC 3842は、SIPにおけるメッセージの要約とメッセージ待機通知イベントのパッケージに関する仕様です。このRFCの目的は、SIPセッションに関連するメッセージの要約と待機通知を効果的に処理するための仕組みを提供することです。
Network Working Group R. Mahy
Request for Comments: 3842 Cisco Systems, Inc.
Category: Standards Track August 2004
A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)
セッション開始プロトコル（SIP）のメッセージの概要とメッセージ待機表示イベントパッケージ
Status of this 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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（2004）。
Abstract
概要
This document describes a Session Initiation Protocol (SIP) event package to carry message waiting status and message summaries from a messaging system to an interested User Agent.
このドキュメントでは、メッセージの待機状況とメッセージの概要をメッセージングシステムから関心のあるユーザーエージェントに伝えるセッション開始プロトコル（SIP）イベントパッケージについて説明します。
Table of Contents
目次
1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background and Appropriateness . . . . . . . . . . . . . . . 3
3. Event Package Formal Definition . . . . . . . . . . . . . . 4
3.1. Event Package Name . . . . . . . . . . . . . . . . . . 4
3.2. Event Package Parameters . . . . . . . . . . . . . . . 4
3.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . 4
3.4. Subscription Duration. . . . . . . . . . . . . . . . . 4
3.5. NOTIFY Bodies. . . . . . . . . . . . . . . . . . . . . 4
3.6. Subscriber Generation of SUBSCRIBE Requests. . . . . . 6
3.7. Notifier Processing of SUBSCRIBE Requests. . . . . . . 6
3.8. Notifier Generation of NOTIFY Requests . . . . . . . . 7
3.9. Subscriber Processing of NOTIFY Requests . . . . . . . 7
3.10. Handling of Forked Requests. . . . . . . . . . . . . . 7
3.11. Rate of Notifications. . . . . . . . . . . . . . . . . 7
3.12. State Agents and Lists . . . . . . . . . . . . . . . . 8
3.13. Behavior of a Proxy Server . . . . . . . . . . . . . . 8
4. Examples of Usage . . . . . . . . . . . . . . . . . . . . . 8
4.1. Example Message Flow . . . . . . . . . . . . . . . . . 8
4.2. Example Usage with Callee Capabilities and Caller
Preferences. . . . . . . . . . . . . . . . . . . . . . 14
5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. New Event-Package Definition . . . . . . . . . . . . . 15
5.2. Body Format Syntax . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16
7.1. SIP Event Package Registration for message-summary . . 16
7.2. MIME Registration for application/
simple-message-summary . . . . . . . . . . . . . . . . 16
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . 17
10.2. Informational References . . . . . . . . . . . . . . . 18
11. Author's Address . . . . . . . . . . . . . . . . . . . . . . 18
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . 19
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [3].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、BCP 14、RFC 2119 [3]に記載されているように解釈される。
Message Waiting Indication is a common feature of telephone networks. It typically involves an audible or visible indication that messages are waiting, such as playing a special dial tone (which in telephone networks is called message-waiting dial tone), lighting a light or indicator on the phone, displaying icons or text, or some combination.
メッセージ待機の表示は、電話ネットワークの一般的な機能です。通常、特別なダイヤルトーン（電話ネットワークではメッセージを待機するダイヤルトーンと呼ばれる）を再生するなど、メッセージが待機しているという可聴または目に見える兆候、電話のライトまたはインジケーター、アイコンやテキストの表示、または一部組み合わせ。
Message-waiting dial tone is similar to but distinct from stutter dial tone. Both are defined in GR-506 [11].
メッセージを待機するダイヤルトーンは、Stutterダイヤルトーンとは異なりますが、異なります。どちらもGR-506で定義されています[11]。
The methods in the SIP [1] base specification were only designed to solve the problem of session initiation for multimedia sessions, and rendezvous. Since Message Waiting Indication is really status information orthogonal to a session, it was not clear how an IP telephone acting as a SIP User Agent would implement comparable functionality. Members of the telephony community viewed this as a shortcoming of SIP.
SIP [1]ベース仕様のメソッドは、マルチメディアセッションのセッション開始の問題とランデブーの問題を解決するためにのみ設計されました。メッセージ待機の表示は実際にセッションの正統派のステータス情報であるため、SIPユーザーエージェントとして機能するIP電話が同等の機能を実装する方法は明らかではありませんでした。テレフォニーコミュニティのメンバーは、これをSIPの欠点と見なしました。
Users want the useful parts of the functionality they have using traditional analog, mobile, and PBX telephones. It is also desirable to provide comparable functionality in a flexible way that allows for more customization and new features. SIP Specific Event Notification (RFC 3265 -- SIP Events) [2] is an appropriate mechanism to use in this environment, as it preserves the user mobility and rendezvous features which SIP provides.
ユーザーは、従来のアナログ、モバイル、およびPBX電話を使用している機能の有用な部分を望んでいます。また、より多くのカスタマイズと新機能を可能にする柔軟な方法で同等の機能を提供することも望ましいです。SIP固有のイベント通知（RFC 3265 -SIPイベント）[2]は、SIPが提供するユーザーのモビリティとランデブー機能を保持するため、この環境で使用する適切なメカニズムです。
Using SIP-Specific Event Notification, a Subscriber User Agent (typically an IP phone or SIP software User Agent) subscribes to the status of their messages. A SIP User Agent acting on behalf of the user's messaging system then notifies the Subscriber each time the messaging account's messages have changed. (This Notifier could be composed with a User Agent that provides a real-time media interface to send or receive messages, or it could be a stand-alone entity.) The Notifier sends a message summary in the body of a NOTIFY, encoded in a new MIME type defined later in this document. A User Agent can also explicitly fetch the current status.
SIP固有のイベント通知を使用して、サブスクライバーユーザーエージェント（通常はIP電話またはSIPソフトウェアユーザーエージェント）がメッセージのステータスを購読します。ユーザーのメッセージングシステムに代わって行動するSIPユーザーエージェントは、メッセージングアカウントのメッセージが変更されるたびにサブスクライバーに通知します。（この通知者は、メッセージを送信または受信するためのリアルタイムメディアインターフェイスを提供するユーザーエージェントで構成されている可能性があります。または、通知者は通知の本文でメッセージの概要を送信します。このドキュメントの後半で定義された新しいMIMEタイプ。ユーザーエージェントは、現在のステータスを明示的に取得することもできます。
A SIP User Agent MAY subscribe to multiple accounts (distinguished by the Request URI). Multiple SIP User Agents MAY subscribe to the same account.
SIPユーザーエージェントは、複数のアカウントを購読する場合があります（リクエストURIによって区別されます）。複数のSIPユーザーエージェントが同じアカウントを購読する場合があります。
Before any subscriptions or notifications are sent, each interested User Agent must be made aware of its messaging notifier(s). This MAY be manually configured on interested User Agents, manually configured on an appropriate SIP Proxy, or dynamically discovered based on requested caller preferences [4] and registered callee capabilities [5]. (For more information on usage with callee capabilities, see Section 4.2)
サブスクリプションまたは通知が送信される前に、各関心のあるユーザーエージェントは、メッセージング通知者を認識させる必要があります。これは、関心のあるユーザーエージェントで手動で構成され、適切なSIPプロキシで手動で構成されているか、要求された発信者の設定[4]および登録されたCallee機能[5]に基づいて動的に発見されます。（Callee機能を使用した使用に関する詳細については、セクション4.2を参照してください）
This document defines a SIP Event Package as defined in RFC 3265 [2]. The event-package token name for this package is:
このドキュメントでは、RFC 3265 [2]で定義されているSIPイベントパッケージを定義しています。このパッケージのイベントパッケージトークン名は次のとおりです。
"message-summary"
「メッセージサマリー」
This package does not define any event package parameters.
このパッケージは、イベントパッケージパラメーターを定義しません。
This package does not define any SUBSCRIBE bodies.
このパッケージは、購読局を定義しません。
Subscriptions to this event package MAY range from minutes to weeks. Subscriptions in hours or days are more typical and are RECOMMENDED. The default subscription duration for this event package is one hour.
このイベントパッケージのサブスクリプションは、数分から数週間の範囲です。時間または日のサブスクリプションはより典型的であり、推奨されます。このイベントパッケージのデフォルトのサブスクリプション期間は1時間です。
A simple text-based format is proposed to prevent an undue burden on low-end user agents, for example, inexpensive IP phones with no display. Although this format is text-based, it is intended for machine consumption only.
単純なテキストベースの形式が提案されており、たとえばディスプレイのない安価なIP電話など、ローエンドのユーザーエージェントに過度の負担を防ぐことができます。この形式はテキストベースですが、機械の消費のみを目的としています。
A future extension MAY define other NOTIFY bodies. If no "Accept" header is present in the SUBSCRIBE, the body type defined in this document MUST be assumed.
将来の拡張は、他の通知機関を定義する場合があります。サブスクライブに「受け入れる」ヘッダーが存在しない場合、このドキュメントで定義されているボディタイプを想定する必要があります。
The format specified in this proposal attempts to separate orthogonal attributes of messages as much as possible. Messages are separated by message-context-class (for example: voice-message, fax-message, pager-message, multimedia-message, text-message, and none), by message status (new and old), and urgent and non-urgent type.
この提案で指定された形式は、メッセージの直交属性を可能な限り分離しようとします。メッセージは、メッセージ - コンテキストクラス（たとえば、音声メッセージ、ファックスメッセージ、ページャーメサージ、マルチメディアメサージ、テキストメッセージなど）、メッセージステータス（新品および古い）、および緊急および非非存在によって区切られています。 - 緊急タイプ。
The text format begins with a simple status line, and optionally a summary line per message-context-class. Message-context-classes are defined in [7]. For each message-context-class, the total number of new and old messages is reported in the new and old fields.
テキスト形式は、単純なステータス行で始まり、オプションではメッセージ - コンテキストクラスごとの要約行があります。メッセージ - コンテキストクラスは[7]で定義されています。メッセージ - コンテキストクラスごとに、新しいメッセージと古いメッセージの総数が新しいフィールドと古いフィールドで報告されます。
In some cases, detailed message summaries are not available. The status line allows messaging systems or messaging gateways to provide the traditional boolean message waiting notification.
場合によっては、詳細なメッセージの概要は利用できません。ステータスラインを使用すると、メッセージングシステムまたはメッセージングゲートウェイが従来のブールメッセージ待機通知を提供できます。
Messages-Waiting: yes
メッセージ待合：はい
If the Request-URI or To header in a message-summary subscription corresponds to a group or collection of individual messaging accounts, the notifier MUST specify to which account the message-summary body corresponds. Note that the account URI MUST NOT be delimited with angle brackets ("<" and ">").
メッセージサマリーサブスクリプションのリクエスト-URIまたはヘッダーが個々のメッセージングアカウントのグループまたはコレクションに対応している場合、notifierはメッセージとムマリーの本文がどのアカウントに対応するかを指定する必要があります。アカウントURIは、アングルブラケット（ "<"および ">"）で区切られてはならないことに注意してください。
Message-Account: sip:alice@example.com
In the example that follows, more than boolean message summary information is available to the User Agent. There are two new and four old fax messages.
以下の例では、ユーザーエージェントがブールメッセージの概要情報を利用できます。2つの新しい古いファックスメッセージがあります。
Fax-Message: 2/4
ファックスメッセージ：2/4
After the summary, the format can optionally list a summary count of urgent messages. In the next example there are one new and three old voice messages, none of the new messages are urgent, but one of the old messages is. All counters have a maximum value of 4,294,967,295 ((2^32) - 1). Notifiers MUST NOT generate a request with a larger value. Subscribers MUST treat a larger value as 2^32-1.
概要の後、フォーマットはオプションで緊急メッセージの概要カウントをリストできます。次の例には、新しい3つの古い音声メッセージが1つあります。新しいメッセージは緊急ではありませんが、古いメッセージの1つは緊急です。すべてのカウンターの最大値は4,294,967,295（（2^32）-1）です。通知者は、より大きな値でリクエストを生成してはなりません。加入者は、より大きな値を2^32-1として扱う必要があります。
Voice-Message: 1/3 (0/1)
音声メッセージ：1/3（0/1）
Optionally, after the summary counts, the messaging systems MAY append RFC 2822 style message headers [9], which further describe newly added messages. Message headers MUST NOT be included in an initial NOTIFY, as new messages could be essentially unbounded in size. Message headers included in subsequent notifications MUST only correspond to messages added since the previous notification for that subscription. A messaging system which includes message headers in a NOTIFY MUST provide an administrator configurable mechanism to select which headers are sent. Headers likely for inclusion are To, From, Date, Subject, and Message-ID. Note that the formatting of these headers in this body is identical to that of SIP extension-headers, not the (similar) format defined in RFC 2822.
オプションで、要約数がカウントされた後、メッセージングシステムはRFC 2822スタイルのメッセージヘッダー[9]を追加する場合があります。これは、新しく追加されたメッセージをさらに説明します。新しいメッセージのサイズが本質的にバウンドされていない可能性があるため、メッセージヘッダーを最初の通知に含めることはできません。後続の通知に含まれるメッセージヘッダーは、そのサブスクリプションの前の通知以降に追加されたメッセージにのみ対応する必要があります。Notifyにメッセージヘッダーを含むメッセージングシステムは、[ヘッダーが送信されるヘッダーを選択するための管理者設定可能なメカニズムを提供する必要があります。おそらくインクルージョンのヘッダーは、日付、件名、およびメッセージ-IDからです。このボディのこれらのヘッダーのフォーマットは、RFC 2822で定義されている（同様の）形式ではなく、SIP拡張ヘッダーのフォーマットと同じであることに注意してください。
Implementations which generate large notifications are reminded to follow the message size restrictions for unreliable transports articulated in Section 18.1.1 of SIP [1].
大規模な通知を生成する実装は、SIPのセクション18.1.1で明確にされた信頼できないトランスポートのメッセージサイズ制限に従うことを思い出させます[1]。
Mapping local message state to new/old message status and urgency is an implementation issue of the messaging system. However, the messaging notifier MUST NOT consider a message "old" merely because it generated a notification, as this could prevent another subscription from accurately receiving message-summary notifications. Likewise, the messaging system MAY use any suitable algorithm to determine that a message is "urgent".
ローカルメッセージの状態を新/古いメッセージのステータスと緊急性にマッピングすることは、メッセージングシステムの実装問題です。ただし、メッセージング通知者は、通知を生成したという理由だけで「古い」メッセージを検討してはなりません。これにより、別のサブスクリプションがメッセージとムマリー通知を正確に受信できないためです。同様に、メッセージングシステムは、適切なアルゴリズムを使用して、メッセージが「緊急」であると判断する場合があります。
Messaging systems MAY use any algorithm for determining the appropriate message-context-class for a specific message. Systems which use Internet Mail SHOULD use the contents of the Message-Context header [7] (defined in RFC 3458) if present as a hint to make a context determination. Note that a composed messaging system does not need to support a given context in order to generate notifications identified with that context.
メッセージングシステムは、特定のメッセージに対して適切なメッセージコンテキストクラスを決定するために任意のアルゴリズムを使用する場合があります。インターネットメールを使用するシステムは、コンテキスト決定を行うためのヒントとして存在する場合は、メッセージ - コンテキストヘッダー[7]（RFC 3458で定義）のコンテンツを使用する必要があります。構成されたメッセージングシステムは、そのコンテキストで特定された通知を生成するために、特定のコンテキストをサポートする必要がないことに注意してください。
Subscriber User Agents will typically SUBSCRIBE to message summary information for a period of hours or days, and automatically attempt to re-SUBSCRIBE well before the subscription is completely expired. If re-subscription fails, the Subscriber SHOULD periodically retry again until a subscription is successful, taking care to backoff to avoid network congestion. If a subscription has expired, new re-subscriptions MUST use a new Call-ID.
サブスクライバーユーザーエージェントは通常、数時間または数日間メッセージサマリー情報を購読し、サブスクリプションが完全に期限切れになる前に自動的に再登録を試みます。再サブスクリプションが失敗した場合、サブスクライバーはサブスクリプションが成功するまで定期的に再度再試行する必要があります。サブスクリプションの有効期限が切れている場合、新しい再サブスクリプションは新しいCall-IDを使用する必要があります。
The Subscriber SHOULD SUBSCRIBE to that user's message summaries whenever a new user becomes associated with the device (a new login). The Subscriber MAY also explicitly fetch the current status at any time. The subscriber SHOULD renew its subscription immediately after a reboot, or when the subscriber's network connectivity has just been re-established.
サブスクライバーは、新しいユーザーがデバイス（新しいログイン）に関連付けられるたびに、そのユーザーのメッセージ要約を購読する必要があります。サブスクライバーは、いつでも現在のステータスを明示的に取得する場合があります。サブスクライバーは、再起動直後、またはサブスクライバーのネットワーク接続が再確立されたときにサブスクリプションを更新する必要があります。
The Subscriber MUST be prepared to receive and process a NOTIFY with new state immediately after sending a new SUBSCRIBE, a SUBSCRIBE renewal, an unsubscribe, a fetch, or at any other time during the subscription.
サブスクライバーは、新しいサブスクライブ、サブスクライブの更新、登録解除、フェッチ、またはサブスクリプション中に他の時間を送信した直後に、新しい状態で通知を受信および処理する準備をする必要があります。
When a user de-registers from a device (logoff, power down of a mobile device, etc.), subscribers SHOULD unsubscribe by sending a SUBSCRIBE message with an Expires header of zero.
ユーザーがデバイス（ログオフ、モバイルデバイスのパワーダウンなど）からレジスタを解除する場合、サブスクライバーは、ゼロの有効期限が付いたサブスクライブメッセージを送信して登録解除する必要があります。
When a SIP Messaging System receives SUBSCRIBE messages with the message-summary event-type, it SHOULD authenticate the subscription request. If authentication is successful, the Notifier MAY limit the duration of the subscription to an administrator defined amount of time as described in SIP Events [2].
SIPメッセージングシステムがメッセージサマリーイベントタイプでサブスクライブメッセージを受信すると、サブスクリプションリクエストを認証する必要があります。認証が成功した場合、通知者は、SIPイベント[2]で説明されているように、サブスクリプションの期間を管理者に定義された時間の定義時間に制限する場合があります。
Immediately after a subscription is accepted, the Notifier MUST send a NOTIFY with the current message summary information. This allows the Subscriber to resynchronize its state. This initial synchronization NOTIFY MUST NOT include the optional RFC 2822 style message headers [8].
サブスクリプションが受け入れられた直後に、通知者は現在のメッセージサマリー情報を使用して通知を送信する必要があります。これにより、サブスクライバーは状態を再同期させることができます。この最初の同期通知は、オプションのRFC 2822スタイルメッセージヘッダー[8]を含めてはなりません。
When the status of the messages changes sufficiently for a messaging account to change the number of new or old messages, the Notifier SHOULD send a NOTIFY message to all active subscribers of that account. NOTIFY messages sent to subscribers of a group or alias, MUST contain the message account name in the notification body.
メッセージのステータスが新規メッセージまたは古いメッセージの数を変更するために十分に変更された場合、Notifierはそのアカウントのすべてのアクティブなサブスクライバーに通知メッセージを送信する必要があります。グループまたはエイリアスのサブスクライバーに送信されたメッセージに通知には、通知本体にメッセージアカウント名を含める必要があります。
A Messaging System MAY send a NOTIFY with an "Expires" header of "0" and a "Subscription-State" header of "terminated" before a graceful shutdown.
メッセージングシステムは、「0」の「有効期限が切れる」ヘッダーと、優雅なシャットダウンの前に「終了」の「サブスクリプション状態」ヘッダーで通知を送信する場合があります。
Upon receipt of a valid NOTIFY request, the subscriber SHOULD immediately render the message status and summary information to the end user in an implementation specific way.
有効なNotifyリクエストを受信すると、サブスクライバーはすぐにメッセージステータスと要約情報を実装固有の方法でエンドユーザーにレンダリングする必要があります。
The Subscriber MUST be prepared to receive NOTIFYs from different Contacts corresponding to the same SUBSCRIBE. (The SUBSCRIBE may have been forked).
サブスクライバーは、同じサブスクライブに対応するさまざまな連絡先から通知を受信する準備をする必要があります。（購読はフォークされている可能性があります）。
Forked requests are allowed for this event type and may install multiple subscriptions. The Subscriber MAY render multiple summaries corresponding to the same account directly to the user, or MAY merge them as described below.
このイベントタイプにはフォークリクエストが許可されており、複数のサブスクリプションをインストールできます。サブスクライバーは、同じアカウントに直接ユーザーに対応する複数の要約をレンダリングするか、以下に説明するようにそれらをマージする場合があります。
If any of the "Messages-Waiting" status lines report "yes", then the merged state is "yes"; otherwise the merged state is "no".
「メッセージを待機する」ステータスラインのいずれかが「はい」を報告する場合、合併した状態は「はい」です。それ以外の場合、マージされた状態は「いいえ」です。
The Subscriber MAY merge summary lines in an implementation-specific way if all notifications contain at least one msg-summary line.
サブスクライバーは、すべての通知に少なくとも1つのMSG-Summary行が含まれている場合、実装固有の方法で要約行をマージすることができます。
A Notifier MAY choose to hold NOTIFY requests in "quarantine" for a short administrator-defined period (seconds or minutes) when the message status is changing rapidly. Requests in the quarantine which become invalid are replaced by newer notifications, thus reducing the total volume of notifications. This behavior is encouraged for implementations with heavy interactive use. Note that timely notification resulting in a change of overall state (messages waiting or not) and notification of newly added messages is probably more significant to the end user than a notification of newly deleted messages which do not affect the overall message waiting state (e.g., there are still new messages).
通知者は、メッセージステータスが迅速に変更されているときに、短い管理者定義の期間（秒または分）の「隔離」の通知を保持することを選択できます。無効になる隔離の要求は、新しい通知に置き換えられ、通知の総量が減少します。この動作は、インタラクティブな使用を重視した実装のために奨励されています。全体的な状態の変更をもたらすタイムリーな通知（待機しているかどうか）と新しく追加されたメッセージの通知は、メッセージ待機状態全体に影響しない新しく削除されたメッセージの通知よりも、おそらくエンドユーザーにとってより重要であることに注意してください（例えば、まだ新しいメッセージがあります）。
Notifiers SHOULD NOT generate NOTIFY requests more frequently than once per second.
Notifiersは、Notifyリクエストを1秒あたり1回より頻繁に生成しないでください。
A Subscriber MAY use an "alias" or "group" in the Request-URI of a subscription if that name is significant to the messaging system. Implementers MAY create a service which consolidates and summarizes NOTIFYs from many Contacts. This document does not preclude implementations from building state agents which support this event package. One way to implement such a service is with the event list extension [10].
サブスクライバーは、その名前がメッセージングシステムにとって重要である場合、サブスクリプションのリクエスト-URIで「エイリアス」または「グループ」を使用できます。実装者は、多くの連絡先から通知を統合および要約するサービスを作成する場合があります。このドキュメントは、このイベントパッケージをサポートする州のエージェントを構築することからの実装を排除するものではありません。このようなサービスを実装する1つの方法は、イベントリスト拡張[10]です。
There are no additional requirements on a SIP Proxy, other than to transparently forward the SUBSCRIBE and NOTIFY methods as required in SIP. However, Proxies SHOULD allow non-SIP URLs. Proxies and Redirect servers SHOULD be able to direct the SUBSCRIBE request to an appropriate messaging notifier User Agent.
SIPプロキシには、SIPで必要に応じてメソッドを透過的に転送し、通知する以外に、追加の要件はありません。ただし、プロキシは非SIP URLを許可する必要があります。プロキシおよびリダイレクトサーバーは、サブスクライブリクエストを適切なメッセージングnotifierユーザーエージェントに指示できる必要があります。
The examples shown below are for informational purposes only. For a normative description of the event package, please see sections 3 and 5 of this document.
以下に示す例は、情報提供のみを目的としています。イベントパッケージの規範的な説明については、このドキュメントのセクション3と5を参照してください。
In the example call flow below, Alice's IP phone subscribes to the status of Alice's messages. Via headers are omitted for clarity.
以下のコールフローの例では、アリスのIP電話はアリスのメッセージのステータスを購読しています。明確にするためにヘッダーを介して省略されています。
Subscriber Notifier
| |
| A1: SUBSCRIBE (new) |
|---------------------->|
| A2: 200 OK |
|<----------------------|
| |
| A3: NOTIFY (sync) |
|<----------------------|
| A4: 200 OK |
|---------------------->|
| |
| |
| A5: NOTIFY (change) |
|<----------------------|
| A6: 200 OK |
|---------------------->|
| |
| |
| A7: (re)SUBSCRIBE |
|---------------------->|
| A8: 200 OK |
|<----------------------|
| |
| A9: NOTIFY (sync) |
|<----------------------|
| A10: 200 OK |
|---------------------->|
| |
| |
| A11: (un)SUBSCRIBE |
|---------------------->|
| A12: 200 OK |
|<----------------------|
| |
| A13: NOTIFY (sync) |
|<----------------------|
| A14: 200 OK |
|---------------------->|
A1: Subscriber (Alice's phone) -> Notifier (Alice's voicemail gateway) Subscribe to Alice's message summary status for 1 day.
A1：サブスクライバー（アリスの電話） - > notifier（アリスのボイスメールゲートウェイ）は、アリスのメッセージサマリーステータスを1日間登録します。
SUBSCRIBE sip:alice@vmail.example.com SIP/2.0
To: <sip:alice@example.com>
From: <sip:alice@example.com>;tag=78923
Date: Mon, 10 Jul 2000 03:55:06 GMT
Call-Id: 1349882@alice-phone.example.com
CSeq: 4 SUBSCRIBE
Contact: <sip:alice@alice-phone.example.com>
Event: message-summary
Expires: 86400
Accept: application/simple-message-summary
Content-Length: 0
A2: Notifier -> Subscriber
SIP/2.0 200 OK
To: <sip:alice@example.com>;tag=4442
From: <sip:alice@example.com>;tag=78923
Date: Mon, 10 Jul 2000 03:55:07 GMT
Call-Id: 1349882@alice-phone.example.com
CSeq: 4 SUBSCRIBE
Expires: 86400
Content-Length: 0
A3: Notifier -> Subscriber
(immediate synchronization of current state:
2 new and 8 old [2 urgent] messages)
NOTIFY sip:alice@alice-phone.example.com SIP/2.0
To: <sip:alice@example.com>;tag=78923
From: <sip:alice@example.com>;tag=4442
Date: Mon, 10 Jul 2000 03:55:07 GMT
Call-Id: 1349882@alice-phone.example.com
CSeq: 20 NOTIFY
Contact: <sip:alice@vmail.example.com>
Event: message-summary
Subscription-State: active
Content-Type: application/simple-message-summary
Content-Length: 99
Messages-Waiting: yes
Message-Account: sip:alice@vmail.example.com
Voice-Message: 2/8 (0/2)
A4: Subscriber -> Notifier
SIP/2.0 200 OK
To: <sip:alice@example.com>;tag=78923
From: <sip:alice@example.com>;tag=4442
Date: Mon, 10 Jul 2000 03:55:08 GMT
Call-Id: 1349882@alice-phone.example.com
CSeq: 20 NOTIFY
Content-Length: 0
A5: Notifier -> Subscriber This is a notification of new messages. Some headers from each of the new messages are appended.
A5：Notifier->サブスクライバーこれは新しいメッセージの通知です。新しいメッセージのそれぞれからの一部のヘッダーが追加されます。
NOTIFY sip:alice@alice-phone.example.com SIP/2.0
To: <sip:alice@example.com>;tag=78923
From: <sip:alice@example.com>;tag=4442
Date: Mon, 10 Jul 2000 04:28:53 GMT
Contact: <sip:alice@vmail.example.com>
Call-ID: 1349882@alice-phone.example.com
CSeq: 31 NOTIFY
Event: message-summary
Subscription-State: active
Content-Type: application/simple-message-summary
Content-Length: 503
Messages-Waiting: yes
Message-Account: sip:alice@vmail.example.com
Voice-Message: 4/8 (1/2)
To: <alice@atlanta.example.com>
From: <bob@biloxi.example.com>
Subject: carpool tomorrow?
Date: Sun, 09 Jul 2000 21:23:01 -0700
Priority: normal
Message-ID: 13784434989@vmail.example.com
To: <alice@example.com>
From: <cathy-the-bob@example.com>
Subject: HELP! at home ill, present for me please
Date: Sun, 09 Jul 2000 21:25:12 -0700
Priority: urgent
Message-ID: 13684434990@vmail.example.com
A6: Subscriber -> Notifier
SIP/2.0 200 OK
To: <sip:alice@example.com>;tag=78923
From: <sip:alice@example.com>;tag=4442
Date: Mon, 10 Jul 2000 04:28:53 GMT
Call-ID: 1349882@alice-phone.example.com
CSeq: 31 NOTIFY
Content-Length: 0
A7: Subscriber -> Notifier Refresh subscription.
A7：サブスクライバー - > notifier更新サブスクリプション。
SUBSCRIBE sip:alice@vmail.example.com SIP/2.0
To: <sip:alice@example.com>;tag=4442
From: <sip:alice@example.com>;tag=78923
Date: Mon, 10 Jul 2000 15:55:06 GMT
Call-Id: 1349882@alice-phone.example.com
CSeq: 8 SUBSCRIBE
Contact: <sip:alice@alice-phone.example.com>
Event: message-summary
Expires: 86400
Accept: application/simple-message-summary
Content-Length: 0
A8: Notifier -> Subscriber
SIP/2.0 200 OK
To: <sip:alice@example.com>;tag=4442
From: <sip:alice@example.com>;tag=78923
Date: Mon, 10 Jul 2000 15:55:07 GMT
Call-Id: 1349882@alice-phone.example.com
CSeq: 8 SUBSCRIBE
Contact: <sip:alice@alice-phone.example.com>
Expires: 86400
Content-Length: 0
A9: Notifier -> Subscriber
(immediate synchronization of current state)
NOTIFY sip:alice@alice-phone.example.com SIP/2.0
To: <sip:alice@example.com>;tag=78923
From: <sip:alice@example.com>;tag=4442
Date: Mon, 10 Jul 2000 15:55:07 GMT
Call-Id: 1349882@alice-phone.example.com
CSeq: 47 NOTIFY
Contact: <sip:alice@vmail.example.com>
Event: message-summary
Subscription-State: active
Content-Type: application/simple-message-summary
Content-Length: 99
Messages-Waiting: yes
Message-Account: sip:alice@vmail.example.com
Voice-Message: 4/8 (1/2)
A10: Subscriber -> Notifier
SIP/2.0 200 OK
To: <sip:alice@example.com>;tag=78923
From: <sip:alice@example.com>;tag=4442
Date: Mon, 10 Jul 2000 15:55:08 GMT
Call-Id: 1349882@alice-phone.example.com
CSeq: 47 NOTIFY
Contact: <sip:alice@vmail.example.com>
A11: Subscriber -> Notifier Un-subscribe after "alice" logs out.
A11：サブスクライバー - >「アリス」がログアウトした後にnotifier un -subscribeを獲得します。
SUBSCRIBE sip:alice@vmail.example.com SIP/2.0
To: <sip:alice@example.com>;tag=4442
From: <sip:alice@example.com>;tag=78923
Date: Mon, 10 Jul 2000 19:35:06 GMT
Call-Id: 1349882@alice-phone.example.com
CSeq: 17 SUBSCRIBE
Contact: <sip:alice@alice-phone.example.com>
Event: message-summary
Expires: 0
Accept: application/simple-message-summary
Content-Length: 0
A12: Notifier -> Subscriber
SIP/2.0 200 OK
To: <sip:alice@example.com>;tag=4442
From: <sip:alice@example.com>;tag=78923
Date: Mon, 10 Jul 2000 19:35:07 GMT
Call-Id: 1349882@alice-phone.example.com
CSeq: 17 SUBSCRIBE
Contact: <sip:alice@alice-phone.example.com>
Expires: 0
Content-Length: 0
A13: Notifier -> Subscriber (immediate synchronization of current state, which the subscriber can now ignore)
A13：Notifier->サブスクライバー（現在の状態の即時同期、サブスクライバーがこれを無視できるようになりました）
NOTIFY sip:alice@alice-phone.example.com SIP/2.0
To: <sip:alice@example.com>;tag=78923
From: <sip:alice@example.com>;tag=4442
Date: Mon, 10 Jul 2000 19:35:07 GMT
Call-Id: 1349882@alice-phone.example.com
CSeq: 56 NOTIFY
Contact: <sip:alice@vmail.example.com>
Event: message-summary
Subscription-State: terminated;reason=timeout
Content-Type: application/simple-message-summary
Content-Length: 99
Messages-Waiting: yes
Message-Account: sip:alice@vmail.example.com
Voice-Message: 4/8 (1/2)
A14: Subscriber -> Notifier
SIP/2.0 200 OK
To: <sip:alice@example.com>;tag=78923
From: <sip:alice@example.com>;tag=4442
Date: Mon, 10 Jul 2000 19:35:08 GMT
Call-Id: 1349882@alice-phone.example.com
CSeq: 56 NOTIFY
Event: message-summary
Content-Length: 0
The use of callee capabilities is optional but encouraged. If callee capabilities are used, a messaging notifier MAY REGISTER a Contact with an appropriate methods and events tag as shown in the example below. To further distinguish itself, the messaging notifier MAY also REGISTER as a Contact with the actor="msg-taker" tag. An example of this kind of registration follows below.
Callee機能の使用はオプションですが、奨励されています。Callee機能が使用される場合、メッセージング通知者は、以下の例に示すように、適切な方法とイベントタグと連絡先を登録することができます。さらに区別するために、メッセージング通知者は、Actor = "MSG-Taker"タグとの接触として登録することもできます。この種の登録の例は、以下に次のとおりです。
REGISTER sip:sip3-sj.example.com SIP/2.0
To: <sip:alice@example.com>
From: <sip:alice@example.com>;tag=4442
...
Contact: <sip:alice@vm13-sj.example.com>
;actor="msg-taker";methods="SUBSCRIBE"
;automata;events="message-summary"
The following SUBSCRIBE message would find the Contact which registered in the example above.
次の購読メッセージは、上記の例に登録されている連絡先を見つけます。
SUBSCRIBE sip:alice@example.com SIP/2.0
...
Accept: application/simple-message-summary
Event: message-summary
Accept-Contact: *;automata;actor="msg-taker"
The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC 2234 [6].
次の構文仕様では、RFC 2234 [6]に記載されているように、拡張されたバックナウル形式（BNF）を使用しています。
This document defines a new event-package with the package name:
このドキュメントでは、パッケージ名を使用した新しいイベントパッケージを定義します。
message-summary
メッセージサマリー
The formal syntax for the application/simple-message-summary MIME type is described below. The message-context-class production is defined in Section 6.2 of RFC 3458 [7]. Note that all productions described here are case insensitive.
アプリケーション/シンプルなメッセージスマリーMIMEタイプの正式な構文を以下に説明します。メッセージ - コンテキストクラスの生成は、RFC 3458のセクション6.2で定義されています[7]。ここで説明するすべてのプロダクションは、症例鈍感であることに注意してください。
message-summary = msg-status-line CRLF
[msg-account CRLF]
[*(msg-summary-line CRLF)]
[ *opt-msg-headers ]
msg-status-line = "Messages-Waiting" HCOLON msg-status
msg-status = "yes" / "no"
msg-account = "Message-Account" HCOLON Account-URI
Account-URI = SIP-URI / SIPS-URI / absoluteURI
msg-summary-line = message-context-class HCOLON newmsgs SLASH oldmsgs [ LPAREN new-urgentmsgs SLASH old-urgentmsgs RPAREN ]
msg-summary-line = message-context-class hcolon newmsgs slash oldmsgs [lparen new-urgentmsgs slash old-urgentmsgs rparen]
opt-msg-headers = CRLF 1*(extension-header CRLF)
opt-msg-headers = crlf 1*（extension-header crlf）
newmsgs = msgcount
oldmsgs = msgcount
new-urgentmsgs = msgcount
old-urgentmsgs = msgcount
msgcount = 1*DIGIT ; MUST NOT exceed 2^32-1
Message summaries and optional message bodies contain information which is typically very privacy sensitive. At a minimum, subscriptions to this event package SHOULD be authenticated and properly authorized. Furthermore, notifications SHOULD be encrypted and integrity protected using either end-to-end mechanisms, or the hop-by-hop protection afforded messages sent to SIPS URIs.
メッセージの概要とオプションのメッセージ本文には、通常非常にプライバシーに敏感な情報が含まれています。少なくとも、このイベントパッケージのサブスクリプションは認証され、適切に承認される必要があります。さらに、通知は暗号化され、エンドツーエンドメカニズムのいずれかを使用して整合性を保護する必要があります。また、Hop-by-Hop保護には、SIPS URISに送信されたメッセージが提供されます。
Additional and privacy security considerations are discussed in detail in SIP [1] and SIP Events [2].
追加およびプライバシーセキュリティの考慮事項については、SIP [1]およびSIPイベント[2]で詳しく説明します。
Package name: message-summary
パッケージ名：メッセージサマリー
Type: package
タイプ：パッケージ
Contact: [Mahy]
連絡先：[Mahy]
Published Specification: This document.
公開された仕様：このドキュメント。
MIME media type name: application
MIMEメディアタイプ名：アプリケーション
MIME subtype name: simple-message-summary
MIMEサブタイプ名：Simple-Message-Summary
Required parameters: none.
必要なパラメーター：なし。
Optional parameters: none.
オプションのパラメーター：なし。
Encoding considerations: This MIME type was designed for use with protocols which can carry binary-encoded data. Although the format of this MIME type is similar to RFC 2822, it is not identical. (Specifically, line folding rules are SIP-specific and included URIs can contain non-ASCII characters.) Protocols which do not carry binary data (which have line length or character-set restrictions for example) MUST use a reversible transfer encoding (such as base64) to carry this MIME type.
考慮事項のエンコード：このMIMEタイプは、バイナリエンコードデータを運ぶことができるプロトコルで使用するために設計されました。このMIMEタイプの形式はRFC 2822に似ていますが、同一ではありません。（具体的には、ラインの折り畳みルールはSIP固有であり、urisに含まれる可能性が含まれます。）バイナリデータを運ばないプロトコル（たとえば、ラインの長さまたは文字セットの制限を持つ）は、可逆転送エンコードを使用する必要があります（base64）このマイムタイプを運ぶ。
Security considerations: See the "Security Considerations" section in this document.
セキュリティ上の考慮事項：このドキュメントの「セキュリティ上の考慮事項」セクションを参照してください。
Interoperability considerations: none
相互運用性の考慮事項：なし
Published specification: This document.
公開された仕様：このドキュメント。
Applications which use this media: The simple-message-summary application subtype supports the exchange of message waiting and message summary information in SIP networks.
このメディアを使用するアプリケーション：Simple-Message-Summary Applicationサブタイプは、SIPネットワークでのメッセージ待機とメッセージの概要情報の交換をサポートします。
Additional information:
追加情報：
1. Magic number(s): N/A
1. マジック番号：n/a
2. File extension(s): N/A
2. ファイル拡張子：n/a
3. Macintosh file type code: N/A
3. Macintoshファイルタイプコード：n/a
Ilya Slain came up with the initial format of the text body contained in this document. He was previously listed as a co-author, however, he is no longer reachable.
Ilya Slainは、このドキュメントに含まれるテキスト本体の初期形式を思いつきました。彼は以前は共著者としてリストされていましたが、彼はもはや到達できなくなりました。
Thanks to Dan Wing, Dave Oran, Bill Foster, Steve Levy, Denise Caballero-McCann, Jeff Michel, Priti Patil, Satyender Khatter, Bich Nguyen, Manoj Bhatia, David Williams, and Bryan Byerly of Cisco, Jonathan Rosenberg and Adam Roach of Dynamicsoft, Eric Burger of Snowshore, Nir Chen of Comverse, and Eric Tremblay of Mediatrix.
ダン・ウィング、デイブ・オラン、ビル・フォスター、スティーブ・レヴィ、デニス・カバレロ・マッキャン、ジェフ・ミシェル、プリティ・パティル、サティエンダー・カッター、ビッチ・ヌグエン、マノジ・バティア、デビッド・ウィリアムズ、ブライアン・バイアン・バイアン・バイアン・バイアン・バイアン、ジョナサン・ローゼンベルク、ダイナミクソフト、スノーショアのエリック・バーガー、コマバースのニール・チェン、メディアトリックスのエリック・トレンブレイ。
[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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INTIATION Protocol"、RFC 3261、2002年6月。
[2] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[2] Roach、A.B。、「セッション開始プロトコル（SIP）特異的イベント通知」、RFC 3265、2002年6月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[4] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[4] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「セッション開始プロトコル（SIP）に対する発信者の好み」、RFC 3841、2004年8月。
[5] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[5] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「セッション開始プロトコル（SIP）のユーザーエージェント機能を示す」、RFC 3840、2004年8月。
[6] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[6] Crocker、D.、ed。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 2234、1997年11月。
[7] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message Context for Internet Mail", RFC 3458, January 2003.
[7] Burger、E.、Candell、E.、Eliot、C。、およびG. Klyne、「インターネットメールのメッセージコンテキスト」、RFC 3458、2003年1月。
[8] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[8] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート2：メディアタイプ」、RFC 2046、1996年11月。
[9] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.
[9] Resnick、P.、ed。、「インターネットメッセージ形式」、RFC 2822、2001年4月。
[10] Rosenberg, J., Roach, A.B., and B. Campbell, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", Work in Progress, June 2003.
[10] Rosenberg、J.、Roach、A.B。、およびB. Campbell、「リソースリストのセッション開始プロトコル（SIP）イベント通知拡張機能」、2003年6月の作業。
[11] Telcordia, "GR-506: Signaling for Analog Interfaces, Issue 1, Revision 1", Nov 1996.
[11] Telcordia、「GR-506：アナログインターフェースのシグナリング、第1号、リビジョン1 "、1996年11月。
Rohan Mahy Cisco Systems, Inc. 5617 Scotts Valley Drive, Suite 200 Scotts Valley, CA 95066 USA
Rohan Mahy Cisco Systems、Inc。5617 Scotts Valley Drive、Suite 200 Scotts Valley、CA 95066 USA
EMail: rohan@cisco.com
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.
著作権（c）The Internet Society（2004）。この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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は、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
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エディター機能の資金は現在、インターネット協会によって提供されています。