[要約] RFC 3343は、APEXプレゼンスサービスに関する規格であり、プレゼンス情報の交換を目的としています。この規格は、ユーザーのオンライン状態や利用可能性などの情報を他のアプリケーションと共有するための方法を提供します。
Network Working Group M. Rose
Request for Comments: 3343 Dover Beach Consulting, Inc.
Category: Experimental G. Klyne
Nine by Nine
D. Crocker
Brandenburg InternetWorking
April 2003
The Application Exchange (APEX) Presence Service
Application Exchange（APEX）プレゼンスサービス
Status of this Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
This memo describes the Application Exchange (APEX) presence service, addressed as the well-known endpoint "apex=presence". The presence service is used to manage presence information for APEX endpoints.
このメモは、よく知られているエンドポイント「apex =存在」として扱われているアプリケーション交換（apex）プレゼンスサービスについて説明しています。プレゼンスサービスは、APEXエンドポイントの存在情報を管理するために使用されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Use and Management of Presence Information . . . . . . . . . . 3
2.1 Update of Presence Information . . . . . . . . . . . . . . . . 3
2.2 Distribution of Presence Information . . . . . . . . . . . . . 4
2.3 Distribution of Watcher Information . . . . . . . . . . . . . 7
3. Format of Presence Entries . . . . . . . . . . . . . . . . . . 10
4. The Presence Service . . . . . . . . . . . . . . . . . . . . . 11
4.1 Use of XML and MIME . . . . . . . . . . . . . . . . . . . . . 12
4.2 The Subscribe Operation . . . . . . . . . . . . . . . . . . . 13
4.3 The Watch Operation . . . . . . . . . . . . . . . . . . . . . 14
4.4 The Publish Operation . . . . . . . . . . . . . . . . . . . . 15
4.5 The Terminate Operation . . . . . . . . . . . . . . . . . . . 17
4.6 The Notify Operation . . . . . . . . . . . . . . . . . . . . . 17
4.7 The Reply Operation . . . . . . . . . . . . . . . . . . . . . 18
5. Registration: The Presence Service . . . . . . . . . . . . . . 18
6. The Presence Service DTD . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 23
This memo describes a presence service that is built upon the APEX [1] "relaying mesh". The APEX presence service is used to manage presence information for APEX endpoints.
このメモでは、頂点[1]「メッシュの中継」に基づいて構築されている存在サービスについて説明しています。Apex Presenceサービスは、Apexエンドポイントの存在情報を管理するために使用されます。
APEX, at its core, provides a best-effort datagram service. Within an administrative domain, all relays must be able to handle messages for any endpoint within that domain. APEX services are logically defined as endpoints, but given their ubiquitous semantics they do not necessarily need to be associated with a single physical endpoint. As such, they may be provisioned co-resident with each relay within an administrative domain, even though they are logically provided on top of the relaying mesh, i.e.,
Apexは、そのコアで、最良のデータグラムサービスを提供します。管理ドメイン内では、すべてのリレーがそのドメイン内の任意のエンドポイントのメッセージを処理できる必要があります。頂点サービスは論理的にエンドポイントとして定義されていますが、ユビキタスなセマンティクスを考えると、必ずしも単一の物理エンドポイントに関連付ける必要はありません。そのため、リレーのメッシュの上に論理的に提供されている場合でも、それらは管理ドメイン内の各リレーと共同居住者である可能性があります。
+----------+ +----------+ +----------+ +---------+
| APEX | | APEX | | APEX | | |
| access | | presence | | report | | ... |
| service | | service | | service | | |
+----------+ +----------+ +----------+ +---------+
| | | |
| | | |
+----------------------------------------------------------------+
| |
| APEX core |
| |
+----------------------------------------------------------------+
That is, applications communicate with an APEX service by exchanging data with a "well-known endpoint" (WKE).
つまり、アプリケーションは「よく知られているエンドポイント」（WKE）とデータを交換することにより、Apexサービスと通信します。
APEX applications communicate with the presence service by exchanging data with the well-known endpoint "apex=presence" in the corresponding administrative domain, e.g., "apex=presence@example.com" is the endpoint associated with the presence service in the "example.com" administrative domain.
APEXアプリケーションは、対応する管理ドメインのよく知られているエンドポイント「APEX =存在」とデータを交換することにより、存在サービスと通信します。.com "管理ドメイン。
Note that within a single administrative domain, the presence service makes use of the APEX access [3] service in order to determine if an originator is allowed to view or manage presence information.
単一の管理ドメイン内で、プレゼンスサービスはApex Access [3]サービスを利用して、オリジネーターがプレゼンス情報を表示または管理できるかどうかを判断することに注意してください。
Management of presence information falls into three categories:
存在情報の管理は3つのカテゴリに分類されます。
o applications may update the presence information associated with an endpoint;
o アプリケーションは、エンドポイントに関連する存在情報を更新する場合があります。
o applications may subscribe to receive presence information associated with an endpoint; and,
o アプリケーションは、エンドポイントに関連付けられた存在情報を受信するようにサブスクライブする場合があります。そして、
o applications may find out who is subscribed to receive presence information.
o アプリケーションは、存在情報を受信するために誰が購読されているかを見つけるかもしれません。
Each is now described in turn.
それぞれが順番に説明されています。
When an application wants to modify the presence information associated with an endpoint, it sends a publish operation to the service, e.g.,
アプリケーションがエンドポイントに関連する存在情報を変更したい場合、それはサービスにパブリッシュ操作を送信します。
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| | <--------- ok -- | |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='fred@example.com' />
<recipient identity='apex=presence@example.com' />
<data-content Name='Content'>
<publish publisher='fred@example.com' transID='1'
timeStamp='2000-05-14T13:30:00-08:00'>
<presence publisher='fred@example.com'
lastUpdate='2000-05-14T13:02:00-08:00'
publisherInfo='http://www.example.com/fred/'>
<tuple
destination='apex:fred/appl=im@example.com'
availableUntil='2000-05-14T14:02:00-08:00' />
<tuple destination='mailto:fred@flintstone.com'
availableUntil='2525-12-31T23:59:59-08:00' />
</presence>
</publish>
</data-content>
</data>
S: <ok />
Note that this example uses the "subaddress" convention specified in Section 2.2 of [1] (e.g., "fred/appl=im") to denote multiplexing of traffic for a particular endpoint. Of course, popular applications may have their own URI method assigned to them (e.g., "im:fred@example.com").
この例では、[1]のセクション2.2（たとえば、「Fred/Appl = IM」）のセクション2.2で指定された「サブアドレス」規則を使用して、特定のエンドポイントのトラフィックの多重化を示すことに注意してください。もちろん、一般的なアプリケーションには、独自のURIメソッドが割り当てられている場合があります（例：「IM：FRED@EXAMPLE.COM」）。
The service immediately responds with a reply operation containing the same transaction-identifier, e.g.,
このサービスは、同じトランザクションIDENTIFIERを含む返信操作ですぐに応答します。
+-------+ +-------+
| | <------- data -- | |
| relay | | pres. |
| | -- ok ---------> | svc. |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='apex=presence@example.com' />
<recipient identity='fred@example.com' />
<data-content Name='Content'>
<reply code='250' transID='1' />
</data-content>
</data>
S: <ok />
When an application wants to (periodically) receive the presence information associated with an endpoint, it sends a subscribe operation to the service, e.g.,
アプリケーションが（定期的に）エンドポイントに関連付けられている存在情報を（定期的に）受信したい場合、サブスクライブ操作をサービスに送信します。
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| | <--------- ok -- | |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='wilma@example.com' />
<recipient identity='apex=presence@example.com' />
<data-content Name='Content'>
<subscribe publisher='fred@example.com' duration='86400'
transID='100' />
</data-content>
</data>
S: <ok />
The service immediately responds with a publish operation containing the same transaction-identifier, e.g.,
このサービスは、同じトランザクション識別子を含むパブリッシュオペレーションですぐに応答します。
+-------+ +-------+
| | <------- data -- | |
| relay | | pres. |
| | -- ok ---------> | svc. |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='apex=presence@example.com' />
<recipient identity='wilma@example.com' />
<data-content Name='Content'>
<publish publisher='fred@example.com' transID='100'
timeStamp='2000-05-14T13:30:00-08:00'>
<presence publisher='fred@example.com'
lastUpdate='2000-05-14T13:02:00-08:00'
publisherInfo='http://www.example.com/fred/'>
<tuple
destination='apex:fred/appl=im@example.com'
availableUntil='2000-05-14T14:02:00-08:00' />
</presence>
</publish>
</data-content>
</data>
S: <ok />
Subsequently, for up to the specified "duration", the service sends new publish operations whenever there are any changes to the endpoint's presence information. If the "duration" is zero-valued, a one time poll of the presence information is achieved; otherwise, at the end of the "duration", a terminate operation is sent.
その後、指定された「持続時間」まで、サービスはエンドポイントの存在情報に変更がある場合はいつでも、新しいパブリッシュオペレーションを送信します。「持続時間」がゼロ値の場合、存在情報の1回限りの世論調査が達成されます。それ以外の場合、「期間」の終わりに、終了操作が送信されます。
Note that Step 5 of Section 4.4 requires that the "lastUpdate" attribute of a presence entry be supplied in order to update that entry; accordingly, applications must successfully retrieve a presence entry prior to trying to update that entry. This is usually accomplished by subscribing with a zero-valued duration. (Regardless, administrators should ensure that applications authorized to update a presence entry are also authorized to retrieve that entry.) Either the subscriber or the service may cancel a subscription by sending a terminate operation, e.g.,
セクション4.4のステップ5では、そのエントリを更新するために、存在エントリの「lastUpdate」属性が提供されることを要求していることに注意してください。したがって、アプリケーションは、そのエントリを更新しようとする前に、プレゼンスエントリを正常に取得する必要があります。これは通常、ゼロ値の持続時間で購読することで達成されます。（とにかく、管理者は、プレゼンスエントリの更新を許可されたアプリケーションがそのエントリを取得することを許可されることを確認する必要があります。）サブスクライバーまたはサービスのいずれかが終端操作を送信してサブスクリプションをキャンセルすることができます。
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| | <--------- ok -- | |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='wilma@example.com' />
<recipient identity='apex=presence@example.com' />
<data-content Name='Content'>
<terminate transID='100' />
</data-content>
</data>
S: <ok />
+-------+ +-------+
| | <------- data -- | |
| relay | | pres. |
| | -- ok ---------> | svc. |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='apex=presence@example.com' />
<recipient identity='wilma@example.com' />
<data-content Name='Content'>
<reply code='250' transID='100' />
</data-content>
</data>
S: <ok />
or
+-------+ +-------+
| | <------- data -- | |
| relay | | pres. |
| | -- ok ---------> | svc. |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='apex=presence@example.com' />
<recipient identity='wilma@example.com' />
<data-content Name='Content'>
<terminate transID='100' />
</data-content>
</data>
S: <ok />
When an application wants to (periodically) receive notices about endpoints that are subscribed to receive presence information, it sends a watch operation to the service, e.g.,
アプリケーションが（定期的に）存在情報を受信するためにサブスクライブされているエンドポイントに関する通知を（定期的に）受信したい場合、サービスに時計操作を送信します。
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| | <--------- ok -- | |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='fred@example.com' />
<recipient identity='apex=presence@example.com' />
<data-content Name='Content'>
<watch publisher='fred@example.com' duration='86400'
transID='2' />
</data-content>
</data>
S: <ok />
The service immediately responds with a reply operation containing the same transaction-identifier, e.g.,
このサービスは、同じトランザクションIDENTIFIERを含む返信操作ですぐに応答します。
+-------+ +-------+
| | <------- data -- | |
| relay | | pres. |
| | -- ok ---------> | svc. |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='apex=presence@example.com' />
<recipient identity='fred@example.com' />
<data-content Name='Content'
<reply code='250' transID='2' />
</data-content>
</data>
S: <ok />
For each current subscriber, the service immediately sends a notify operation containing the same transaction-identifier, e.g.,
現在のサブスクライバーごとに、サービスはすぐに同じトランザクション識別子を含む通知操作を送信します。
+-------+ +-------+
| | <------- data -- | |
| relay | | pres. |
| | -- ok ---------> | svc. |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='apex=presence@example.com' />
<recipient identity='fred@example.com' />
<data-content Name='Content'>
<notify subscriber='wilma@example.com' transID='2'
duration='86000' action='subscribe' />
</data-content>
</data>
S: <ok />
Subsequently, for up to the specified "duration", the service sends new notify operations whenever an application subscribes successfully or a subscription is terminated. If the "duration" is zero-valued, a one time poll of the watcher information is achieved; otherwise, at the end of the "duration", a terminate operation is sent.
その後、指定された「持続時間」まで、サービスはアプリケーションが正常にサブスクライブするか、サブスクリプションが終了するたびに新しいNotifyオペレーションを送信します。「持続時間」がゼロ値の場合、ウォッチャー情報の1回限りの世論調査が達成されます。それ以外の場合、「期間」の終わりに、終了操作が送信されます。
Either the watcher or the service may cancel the request by sending a terminate operation, e.g.,
ウォッチャーまたはサービスのいずれかが、終了操作を送信してリクエストをキャンセルすることができます。
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| | <--------- ok -- | |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='fred@example.com' />
<recipient identity='apex=presence@example.com' />
<data-content Name='Content'>
<terminate transID='2' />
</data-content>
</data>
S: <ok />
+-------+ +-------+
| | <------- data -- | |
| relay | | pres. |
| | -- ok ---------> | svc. |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='apex=presence@example.com' />
<recipient identity='fred@example.com' />
<data-content Name='Content'>
<reply code='250' transID='2' />
</data-content>
</data>
S: <ok />
or
+-------+ +-------+
| | <------- data -- | |
| relay | | pres. |
| | -- ok ---------> | svc. |
+-------+ +-------+
C: <data content='#Content'>
<originator identity='apex=presence@example.com' />
<recipient identity='fred@example.com' />
<data-content Name='Content'>
<terminate transID='2' />
</data-content>
</data>
S: <ok />
Each administrative domain is responsible for maintaining a "presence entry" for each of its endpoints (regardless of whether those endpoints are currently attached to the relaying mesh).
各管理ドメインは、各エンドポイントの「存在エントリ」を維持する責任があります（これらのエンドポイントが現在中継メッシュに接続されているかどうかに関係なく）。
Section 6 defines the syntax for presence entries. Each presence entry has a "publisher" attribute, a "lastUpdate" attribute, a "publisherInfo" attribute, and contains one or more "tuple" elements:
セクション6では、プレゼンスエントリの構文を定義します。各プレゼンスエントリには、「パブリッシャー」属性、「lastUpdate」属性、「publisherinfo」属性があり、1つ以上の「タプル」要素が含まれています。
o the "publisher" attribute specifies the endpoint associated with the presence entry;
o 「Publisher」属性は、プレゼンスエントリに関連付けられたエンドポイントを指定します。
o the "lastUpdate" attribute specifies the date and time that the service last updated the presence entry;
o 「LastUpDate」属性は、サービスが最後にプレゼンスエントリを更新した日付と時刻を指定します。
o the "publisherInfo" attribute specifies arbitrary information about the publisher (using a URI); and,
o 「PublisherInfo」属性は、パブリッシャーに関する任意の情報を指定します（URIを使用）。そして、
o each "tuple" element specifies information about an entity associated with the endpoint.
o 各「タプル」要素は、エンドポイントに関連付けられたエンティティに関する情報を指定します。
Each "tuple" element has a "destination" attribute, an "availableUntil" attribute, a "tupleInfo" attribute, and contains zero or more "capability" elements:
各「タプル」要素には、「宛先」属性、「利用可能な」属性、「tupleinfo」属性があり、ゼロ以上の「機能」要素が含まれています。
o the "destination" attribute identifies the entity as a URI (e.g., "apex:fred/appl=im@example.com" or "mailto:fred@flintstone.com");
o 「宛先」属性は、エンティティをURI（「apex：fred/appl=im@example.com」または「mailto：fred@flintstone.com」）として識別します。
o the "availableUntil" attribute specifies the latest date and time that the entity is capable of receiving messages;
o 「利用可能な」属性は、エンティティがメッセージを受信できる最新の日付と時刻を指定します。
o the "tupleInfo" attribute specifies arbitrary information about the entity (using a URI); and,
o 「Tupleinfo」属性は、エンティティに関する任意の情報を指定します（URIを使用）。そして、
o each "capability" element contains a specification as to the kinds of content the entity is capable of receiving.
o 各「機能」要素には、エンティティが受信できるコンテンツの種類に関する仕様が含まれています。
Each "capability" element contains arbitrary character data formatted according to the standard indicated in the element's "baseline" attribute.
各「機能」要素には、要素の「ベースライン」属性に示されている標準に従ってフォーマットされた任意の文字データが含まれています。
Section 5 contains the APEX service registration for the presence service:
セクション5には、プレゼンスサービスの頂点サービス登録が含まれています。
o Within an administrative domain, the service is addressed using the well-known endpoint of "apex=presence".
o 管理ドメイン内では、「APEX =存在」のよく知られているエンドポイントを使用して、サービスは対処されます。
o Section 6 defines the syntax of the operations exchanged with the service.
o セクション6では、サービスと交換された操作の構文を定義します。
o A consumer of the service initiates communications by sending data containing the subscribe, watch, or publish operation.
o サービスの消費者は、購読、監視、または公開操作を含むデータを送信することにより、コミュニケーションを開始します。
o In addition to replying to these operations, the service may also initiate communications by sending data containing the terminate, publish, or notify operations.
o これらのオペレーションへの返信に加えて、サービスは、終了、公開、または通知を含むデータを送信することにより、コミュニケーションを開始する場合があります。
An implementation of the service must maintain information about both presence entries and in-progress operations in persistent storage.
サービスの実装は、永続的なストレージでのプレゼンスエントリと進行中の操作の両方に関する情報を維持する必要があります。
Consult Section 6.1.1 of [1] for a discussion on the properties of long-lived transaction-identifiers.
長寿命の取引識別子の特性に関する議論については、[1]のセクション6.1.1を参照してください。
Section 4.1 of [1] describes how arbitrary MIME content is exchanged as a BEEP [2] payload. For example, to transmit:
[1]のセクション4.1は、任意のMIMEコンテンツがビープ音[2]ペイロードとしてどのように交換されるかを説明しています。たとえば、送信するには：
<data content='...'>
<originator identity='apex=presence@example.com' />
<recipient identity='fred@example.com' />
</data>
where "..." refers to: <reply code='250' transID='1' />
then the corresponding BEEP message might look like this:
その後、対応するビープメッセージは次のようになるかもしれません：
C: MSG 1 1 . 42 1234
C: Content-Type: multipart/related; boundary="boundary";
C: start="<1@example.com>";
C: type="application/beep+xml"
C:
C: --boundary
C: Content-Type: application/beep+xml
C: Content-ID: <1@example.com>
C:
C: <data content='cid:2@example.com'>
C: <originator identity='fred@example.com' />
C: <recipient identity='apex=presence@example.com' />
C: </data>
C: --boundary
C: Content-Type: application/beep+xml
C: Content-ID: <2@example.com>
C:
C: <reply code='250' transID='1' />
C: --boundary--
C: END
or this:
またはこれ：
C: MSG 1 1 . 42 1234
C: Content-Type: application/beep+xml
C:
C: <data content='#Content'>
C: <originator identity='fred@example.com' />
C: <recipient identity='apex=presence@example.com' />
C: <data-content Name='Content'>
C: <reply code='250' transID='1' />
C: </data-content>
C: </data>
C: END
When an application wants to (periodically) receive the presence information associated with an endpoint, it sends a "subscribe" element to the service.
アプリケーションが（定期的に）エンドポイントに関連付けられた存在情報を（定期的に）受信したい場合、「サブスクライブ」要素をサービスに送信します。
The "subscribe" element has a "publisher" attribute, a "duration" attribute, a "transID" attribute, and no content:
「サブスクライブ」要素には、「パブリッシャー」属性、「持続時間」属性、「TransID」属性、およびコンテンツなしの属性があります。
o the "publisher" attribute specifies the endpoint associated with the presence entry;
o 「Publisher」属性は、プレゼンスエントリに関連付けられたエンドポイントを指定します。
o the "transID" attribute specifies the transaction-identifier associated with this operation; and,
o 「TransID」属性は、この操作に関連付けられたトランザクションIDENTIFIERを指定します。そして、
o the "duration" attribute specifies the maximum number of seconds for which the originator is interested in receiving updated presence information.
o 「持続時間」属性は、オリジネーターが更新された存在情報を受信することに関心がある最大秒数を指定します。
When the service receives a "subscribe" element, we refer to the "publisher" attribute of that element as the "subject", and the service performs these steps:
サービスが「サブスクライブ」要素を受信すると、その要素の「パブリッシャー」属性を「サブジェクト」と呼び、サービスは次の手順を実行します。
1. If the subject is outside of this administrative domain, a "reply" element having code 553 is sent to the originator.
1. 被験者がこの管理ドメインの外側にある場合、コード553を持つ「返信」要素がオリジネーターに送信されます。
2. If the subject does not refer to a valid endpoint, a "reply" element having code 550 is sent to the originator.
2. 被験者が有効なエンドポイントを参照していない場合、コード550を持つ「返信」要素がオリジネーターに送信されます。
3. If the subject's access entry does not contain a "presence:subscribe" token for the originator, a "reply" element having code 537 is sent to the originator.
3. 被験者のアクセスエントリに「存在：サブスクライブ」トークンが作成者に含まれていない場合、コード537を持つ「返信」要素がオリジネーターに送信されます。
4. If the originator already has an in-progress subscribe operation for the subject, then the previous subscribe operation is silently terminated, and processing continues.
4. オリジネーターが既に被験者の進行中の購読操作を既に持っている場合、以前のサブスクライブ操作は静かに終了し、処理が継続されます。
5. If the "transID" attribute refers to an in-progress subscribe or watch operation for the originator, a "reply" element having code 555 is sent to the originator.
5. 「TransID」属性が、発信者の提案または監視操作を指す場合、コード555を持つ「返信」要素がオリジネーターに送信されます。
6. Otherwise:
6. さもないと：
1. A "publish" element, corresponding to the subject's presence entry, is immediately sent to the originator.
1. 被験者の存在エントリに対応する「公開」要素がすぐに発信者に送信されます。
2. For each endpoint currently watching subscribers to the subject's presence information, a "notify" element is immediately as sent (c.f., Step 6.3 of Section 4.6).
2. 現在、被験者の存在情報の加入者を監視している各エンドポイントについて、「通知」要素はすぐに送信されたとおりです（C.F.、セクション4.6のステップ6.3）。
3. For up to the amount of time indicated by the "duration" attribute of the "subscribe" element, if the subject's presence entry changes, an updated "presence" element is sent to the originator using the publish operation (Section 4.4). Finally, when the amount of time indicated by the "duration" attribute expires, a terminate operation (Section 4.5) is sent to the originator.
3. 「サブスクライブ」要素の「持続時間」属性で示される時間まで、被験者の存在エントリが変更された場合、公開操作を使用して更新された「存在」要素がオリジネーターに送信されます（セクション4.4）。最後に、「持続時間」属性で示される時間が期限切れになると、終了操作（セクション4.5）がオリジネーターに送信されます。
Note that if the duration is zero-valued, then the subscribe operation is making a one-time poll of the presence information. Accordingly, Step 6.3 above does not occur.
持続時間がゼロ値の場合、購読操作は存在情報の1回限りの投票を行っていることに注意してください。したがって、上記のステップ6.3は発生しません。
Regardless of whether a "publish" or "reply" element is sent to the originator, the "transID" attribute is identical to the value found in the "subscribe" element sent by the originator.
「パブリッシュ」要素または「返信」要素がオリジネーターに送信されるかどうかに関係なく、「transID」属性は、オリジネーターが送信した「サブスクライブ」要素に見つかった値と同一です。
When an application wants to (periodically) receive notices about endpoints that are subscribed to receive presence entry, it sends a "watch" element to the service.
アプリケーションが（定期的に）プレゼンスエントリを受信するためにサブスクライブされているエンドポイントに関する通知を（定期的に）受信したい場合、「監視」要素をサービスに送信します。
The "watch" element has a "publisher" attribute, a "duration" attribute, a "transID" attribute, and no content:
「ウォッチ」要素には、「パブリッシャー」属性、「持続時間」属性、「transID」属性、およびコンテンツなしの属性があります。
o the "publisher" attribute specifies the endpoint associated with the presence entry;
o 「Publisher」属性は、プレゼンスエントリに関連付けられたエンドポイントを指定します。
o the "transID" attribute specifies the transaction-identifier associated with this operation; and,
o 「TransID」属性は、この操作に関連付けられたトランザクションIDENTIFIERを指定します。そして、
o the "duration" attribute specifies the maximum number of seconds for which the originator is interested in watching subscribers.
o 「持続時間」属性は、オリジネーターが加入者を見ることに関心がある最大秒数を指定します。
When the service receives a "watch" element, we refer to the "publisher" attribute of that element as the "subject", and the service performs these steps:
サービスが「監視」要素を受信すると、その要素の「パブリッシャー」属性を「サブジェクト」と呼び、サービスは次の手順を実行します。
1. If the subject is outside of this administrative domain, a "reply" element having code 553 is sent to the originator.
1. 被験者がこの管理ドメインの外側にある場合、コード553を持つ「返信」要素がオリジネーターに送信されます。
2. If the subject does not refer to a valid endpoint, a "reply" element having code 550 is sent to the originator.
2. 被験者が有効なエンドポイントを参照していない場合、コード550を持つ「返信」要素がオリジネーターに送信されます。
3. If the subject's access entry does not contain a "presence:watch" token for the originator, a "reply" element having code 537 is sent to the originator.
3. 被験者のアクセスエントリに「存在：視聴」トークンが作成者に含まれていない場合、コード537を持つ「返信」要素がオリジネーターに送信されます。
4. If the originator already has an in-progress watch operation for the subject, then the previous watch operation is silently terminated, and processing continues.
4. オリジネーターがすでに被験者の進行中の時計操作を持っている場合、以前の監視操作は静かに終了し、処理が継続されます。
5. If the "transID" attribute refers to an in-progress subscribe or watch operation for the originator, a "reply" element having code 555 is sent to the originator.
5. 「TransID」属性が、発信者の提案または監視操作を指す場合、コード555を持つ「返信」要素がオリジネーターに送信されます。
6. Otherwise:
6. さもないと：
1. A "reply" element having code 250 is sent to the originator.
1. コード250を持つ「返信」要素がオリジネーターに送信されます。
2. For each endpoint currently subscribing to the subject's presence information, a "notify" element is immediately sent to the originator (c.f., Section 4.6).
2. 現在、被験者の存在情報をサブスクライブしている各エンドポイントについて、「通知」要素が直ちにオリジネーターに送信されます（C.F.、セクション4.6）。
3. For up to the amount of time indicated by the "duration" attribute of the "watch" element, whenever a subscribe operation succeeds or a subscription is terminated, a "notify" element is sent to the originator. Finally, when the amount of time indicated by the "duration" attribute expires, a terminate operation (Section 4.5) is sent to the originator.
3. 「監視」要素の「期間」属性で示される時間まで、購読操作が成功した場合、またはサブスクリプションが終了する場合は、「Notify」要素がオリジネーターに送信されます。最後に、「持続時間」属性で示される時間が期限切れになると、終了操作（セクション4.5）がオリジネーターに送信されます。
Note that if the duration is zero-valued, then the watch operation is making a one-time poll of the presence information. Accordingly, Step 6.3 above does not occur.
持続時間がゼロ値の場合、時計操作が存在情報の1回限りの世論調査を行っていることに注意してください。したがって、上記のステップ6.3は発生しません。
Regardless of whether a "notify" or "reply" element is sent to the originator, the "transID" attribute is identical to the value found in the "presence" element sent by the originator.
「Notify」要素または「返信」要素がオリジネーターに送信されるかどうかに関係なく、「TransID」属性は、発信者が送信した「存在」要素に見られる値と同一です。
When an application wants to modify the presence entry associated with an endpoint, it sends a "publish" element to the service. In addition, the service sends a "publish" element to endpoints that have subscribed to see presence information (c.f., Section 4.2).
アプリケーションがエンドポイントに関連付けられた存在エントリを変更したい場合、「公開」要素をサービスに送信します。さらに、このサービスは、存在情報を表示するためにサブスクライブしたエンドポイントに「公開」要素を送信します（C.F.、セクション4.2）。
The "publish" element has a "publisher" attribute, a "transID" attribute, a "timeStamp" attribute, and contains a "presence" element:
「パブリッシュ」要素には、「パブリッシャー」属性、「TransID」属性、「タイムスタンプ」属性があり、「存在」要素が含まれています。
o the "publisher" attribute specifies the endpoint to be associated with the presence entry;
o 「Publisher」属性は、エンドポイントを存在感に関連付けることを指定します。
o the "transID" attribute specifies the transaction-identifier associated with this operation;
o 「TransID」属性は、この操作に関連付けられたトランザクションIDENTIFIERを指定します。
o the "timeStamp" attribute specifies the application's notion of the current date and time; and,
o 「タイムスタンプ」属性は、現在の日付と時刻に関するアプリケーションの概念を指定します。そして、
o the "presence" element contains the desired presence entry for the endpoint.
o 「存在」要素には、エンドポイントの目的の存在エントリが含まれています。
When the service sends a "publish" element, the "transID" attribute specifies the transaction-identifier associated with the subscribe operation that caused this "publish" element to be sent, and the "timeStamp" attribute specifies the service's notion of the current date and time. No reply is sent by the receiving endpoint.
サービスが「公開」要素を送信すると、「transID」属性は、この「公開」要素を送信したサブスクライブ操作に関連付けられたトランザクション識別子を指定し、「タイムスタンプ」属性は現在の日付のサービスの概念を指定しますと時間。受信エンドポイントから返信は送信されません。
When the service receives a "publish" element, we refer to the "publisher" attribute of that element as the "subject", and the service performs these steps:
サービスが「公開」要素を受信すると、その要素の「パブリッシャー」属性を「サブジェクト」と呼び、サービスは次の手順を実行します。
1. If the "publisher" attribute of the "publish" element doesn't match the "publisher" attribute of the "presence" element contained in the "publish" element, a "reply" element having code 503 is sent to the originator.
1. 「Publish」要素の「パブリッシャー」属性が「パブリッシング」要素の「パブリッシャー」属性と一致しない場合、「パブリッシュ」要素に含まれる「存在」要素、コード503を持つ「返信」要素がオリジネーターに送信されます。
2. If the subject is outside of this administrative domain, a "reply" element having code 553 is sent to the originator.
2. 被験者がこの管理ドメインの外側にある場合、コード553を持つ「返信」要素がオリジネーターに送信されます。
3. If the subject does not refer to a valid endpoint, a "reply" element having code 550 is sent to the originator.
3. 被験者が有効なエンドポイントを参照していない場合、コード550を持つ「返信」要素がオリジネーターに送信されます。
4. If the subject's access entry does not contain a "presence:publish" token for the originator, a "reply" element having code 537 is sent to the originator.
4. 被験者のアクセスエントリに発信者の「存在：公開」トークンが含まれていない場合、コード537を持つ「返信」要素がオリジネーターに送信されます。
5. If the "lastUpdate" attribute of the "publish" element is not semantically identical to the "lastUpdate" attribute of the subject's presence entry, a "reply" element having code 555 is sent to the originator. (This allows a simple mechanism for atomic updates.)
5. 「パブリッシュ」要素の「lastUpDate」属性が、被験者の存在エントリの「lastUpDate」属性とセマンティックに同一ではない場合、コード555を持つ「返信」要素がオリジネーターに送信されます。（これにより、アトミックアップデートの簡単なメカニズムが可能になります。）
6. Otherwise:
6. さもないと：
1. The subject's presence entry is updated from the "publish" element.
1. 被験者の存在エントリは、「公開」要素から更新されます。
2. The "lastUpdate" attribute of the presence entry is set to the service's notion of the current date and time.
2. プレゼンスエントリの「LastUpDate」属性は、現在の日付と時刻のサービスの概念に設定されています。
3. A "reply" element having code 250 is sent to the originator.
3. コード250を持つ「返信」要素がオリジネーターに送信されます。
When sending the "reply" element, the "transID" attribute is identical to the value found in the "publish" element sent by the originator.
「返信」要素を送信する場合、「TransID」属性は、オリジネーターが送信した「公開」要素で見つかった値と同一です。
When an application no longer wishes to subscribe to presence information or to watch endpoints that are subscribed to receive presence information, it sends a "terminate" element to the service; similarly, when the service no longer considers an application to be subscribing or watching, a "terminate" element is sent to the application.
アプリケーションが存在情報を購読したり、存在情報を受け取ったりするためにサブスクライブされているエンドポイントを監視したくない場合、サービスに「終了」要素を送信します。同様に、サービスが申請を購読または監視することを考慮しなくなった場合、「終了」要素がアプリケーションに送信されます。
The "terminate" element contains only a "transID" attribute that specifies the transaction-identifier associated an in-progress subscribe or watch operation. Section 9.1 of [1] defines the syntax for the "terminate" element.
「終了」要素には、進行中のサブスクライブまたは監視操作に関連するトランザクション識別子を指定する「TransID」属性のみが含まれます。[1]のセクション9.1は、「終了」要素の構文を定義します。
When the service receives a "terminate" element, it performs these steps:
サービスが「終了」要素を受信すると、これらの手順を実行します。
1. If the transaction-identifier does not refer to a previous subscribe or watch operation for the originator, an "error" element having code 550 is returned.
1. トランザクションIDENTIFIERがオリジネーターの以前の購読または監視操作を参照していない場合、コード550を持つ「エラー」要素が返されます。
2. Otherwise, the previous subscribe or watch operation for the originator is terminated, and a "reply" element having code 250 is sent to the originator.
2. それ以外の場合、オリジネーターの以前の購読または監視操作が終了し、コード250を持つ「返信」要素がオリジネーターに送信されます。
Note that following a terminate operation, the originator may receive further presence or watcher updates. Although the service will send no further updates after processing a terminate operation and sending the reply operation, earlier updates may be in transit.
終了操作に続いて、オリジネーターはさらに存在感またはウォッチャーの更新を受けることができることに注意してください。このサービスは、終了操作を処理して返信操作を送信した後、さらなる更新を送信しませんが、以前の更新は輸送中である可能性があります。
The service sends a "notify" element to endpoints that are watching other endpoints subscribed to presence information (c.f., Section 4.3).
このサービスは、存在情報にサブスクライブされている他のエンドポイントを監視しているエンドポイントに「通知」要素を送信します（C.F.、セクション4.3）。
The "notify" element has a "subscriber" attribute, a "transID" attribute, a "duration" attribute, an "action" attribute, and no content:
「Notify」要素には、「サブスクライバー」属性、「TransID」属性、「持続時間」属性、「アクション」属性、およびコンテンツなしがあります。
o the "subscriber" attribute specifies the endpoint that is subscribed to presence information; and,
o 「サブスクライバー」属性は、存在情報にサブスクライブされるエンドポイントを指定します。そして、
o the "transID" attribute specifies the transaction-identifier associated with the watch operation that caused this "notify" element to be sent;
o 「TransID」属性は、この「Notify」要素を送信した時計操作に関連付けられたトランザクションIDENTIFIERを指定します。
o the "action" attribute specifies whether a subscription or its termination has occurred; and,
o 「アクション」属性は、サブスクリプションまたはその終了が発生したかどうかを指定します。そして、
o if a subscription is being reported, the "duration" attribute specifies the requested duration of the subscription.
o サブスクリプションが報告されている場合、「持続時間」属性は、サブスクリプションの要求された期間を指定します。
No reply is sent by the receiving endpoint.
受信エンドポイントから返信は送信されません。
While processing operations, the service may respond with a "reply" element. Consult Sections 10.2 and 6.1.2 of [1], respectively, for the definition and an exposition of the syntax of the reply element.
操作の処理中、サービスは「返信」要素で応答する場合があります。[1]のセクション10.2および6.1.2をそれぞれ参照してください。応答要素の構文の定義と説明については、それぞれ参照してください。
Well-Known Endpoint: apex=presence
よく知られているエンドポイント：apex =存在
Syntax of Messages Exchanged: c.f., Section 6
交換されたメッセージの構文：C.F。、セクション6
Sequence of Messages Exchanged: c.f., Section 4
交換されたメッセージのシーケンス：C.F。、セクション4
Access Control Tokens: presence:subscribe, presence:watch,
presence:publish
Contact Information: c.f., the "Authors' Addresses" section of this memo
連絡先情報：C.F。、このメモの「著者のアドレス」セクション
<!-- DTD for the APEX presence service, as of 2001-05-08
<！ - 2001-05-08の時点で、Apex PresenceサービスのDTD
Refer to this DTD as:
このDTDを次のように参照してください。
<!ENTITY % APEXPRESENCE PUBLIC "-//IETF//DTD APEX PRESENCE//EN" ""> %APEXPRESENCE; -->
<！entity％apexpresence public " - // ietf // dtd apex presence // en" "">％apexpresence; - >
<!ENTITY % APEXCORE PUBLIC "-//IETF//DTD APEX CORE//EN" "">
%APEXCORE;
<!-- Synopsis of the APEX presence service
<！ - 頂点存在サービスの概要
service WKE: apex=presence
サービスWKE：apex =存在感
message exchanges:
メッセージ交換：
consumer initiates service replies
================== ================
subscribe publish or reply
terminate reply
watch reply
publish reply
service initiates consumer replies
================= ================
terminate (nothing)
publish (nothing)
notify (nothing)
access control:
アクセス制御：
token target
================== ======
presence:subscribe for "publisher" of "subscribe" element
presence:watch for "publisher" of "watch" element
presence:publish for "publisher" of "publish" element
-->
<!ELEMENT subscribe EMPTY>
<!ATTLIST subscribe
publisher %ENDPOINT; #REQUIRED
transID %UNIQID; #REQUIRED
duration %SECONDS; #REQUIRED>
<!ELEMENT watch EMPTY>
<!ATTLIST watch
publisher %ENDPOINT; #REQUIRED
transID %UNIQID; #REQUIRED
duration %SECONDS; #REQUIRED>
<!-- publisher attributes must match in publish and presence -->
<!ELEMENT publish (presence)>
<!ATTLIST publish
publisher %ENDPOINT; #REQUIRED
transID %UNIQID; #REQUIRED
timeStamp %TIMESTAMP; #REQUIRED>
<!ELEMENT notify EMPTY>
<!ATTLIST notify
subscriber %ENDPOINT; #REQUIRED
transID %UNIQID; #REQUIRED
duration %SECONDS; "0"
action (subscribe|terminate)
"subscribe">
<!--
presence entries
-->
<!ELEMENT presence (tuple+)>
<!ATTLIST presence
publisher %ENDPOINT; #REQUIRED
lastUpdate %TIMESTAMP; #REQUIRED
publisherInfo
%URI; "">
<!ELEMENT tuple (capability*)>
<!ATTLIST tuple
destination %URI; #REQUIRED
availableUntil
%TIMESTAMP; #REQUIRED
tupleInfo %URI; "">
<!-- e.g., baseline='urn:ietf:rfc:rfc2533' -->
<!ELEMENT capability (#PCDATA)>
<!ATTLIST capability
baseline %URI #REQUIRED>
Consult [1]'s Section 11 for a discussion of security issues.
セキュリティ問題の議論については、[1]のセクション11に相談してください。
In addition, timestamps issued by the the presence service may disclose location information. If this information is considered sensitive, the special timezone value "-00:00" may be used (after converting the local time accordingly).
さらに、プレゼンスサービスによって発行されたタイムスタンプは、位置情報を開示する場合があります。この情報が敏感であると見なされる場合、特別なタイムゾーン値「-00：00」を使用できます（それに応じて現地時間を変換した後）。
References
参考文献
[1] Rose, M., Klyne, G. and D. Crocker, "The Application Exchange Core", RFC 3340, July 2002.
[1] Rose、M.、Klyne、G。およびD. Crocker、「The Application Exchange Core」、RFC 3340、2002年7月。
[2] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[2] Rose、M。、「ブロック拡張可能な交換プロトコルコア」、RFC 3080、2001年3月。
[3] Rose, M., Klyne, G. and D. Crocker, "The Application Exchange (APEX) Access Service", RFC 3341, July 2002.
[3] Rose、M.、Klyne、G。およびD. Crocker、「The Application Exchange（Apex）Access Service」、RFC 3341、2002年7月。
Acknowledgements
謝辞
The authors gratefully acknowledge the contributions of: Neil Cook, Eric Dixon, Darren New, Scott Pead, and Bob Wyman.
著者は、ニール・クック、エリック・ディクソン、ダレン・ニュー、スコット・ピード、ボブ・ワイマンの貢献に感謝します。
Authors' Addresses
著者のアドレス
Marshall T. Rose Dover Beach Consulting, Inc. POB 255268 Sacramento, CA 95865-5268 US
マーシャルT.ローズドーバービーチコンサルティング、Inc。POB 255268サクラメント、CA 95865-5268 US
Phone: +1 916 483 8878
EMail: mrose@dbc.mtview.ca.us
Graham Klyne Nine by Nine
Graham Klyne Nine by Nine
EMail: gk@ninebynine.org
David H. Crocker Brandenburg InternetWorking 675 Spruce Drive Sunnyvale, CA 94086 US
David H. Crocker Brandenburg InternetWorking 675 Spruce Drive Sunnyvale、CA 94086 US
Phone: +1 408 246 8253
EMail: dcrocker@brandenburg.com
URI: http://www.brandenburg.com/
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。