RFC3343 日本語訳
3343 The Application Exchange (APEX) Presence Service. M. Rose, G.Klyne, D. Crocker. April 2003. (Format: TXT=42043 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
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
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
The Application Exchange (APEX) Presence Service
Status of this Memo
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.
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 Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
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.
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.
Table of Contents
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
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
Rose, et al. Experimental [Page 1] RFC 3343 The Application Exchange (APEX) Presence April 2003
Rose, et al. Experimental [Page 1] RFC 3343 The Application Exchange (APEX) Presence April 2003
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 23
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 23
1. Introduction
1. Introduction
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.
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.
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, 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 | | |
| access | | presence | | report | | ... |
| service | | service | | service | | |
+----------+ +----------+ +----------+ +---------+
| | | |
| | | |
+----------------------------------------------------------------+
| |
| APEX core |
| |
+----------------------------------------------------------------+
+----------+ +----------+ +----------+ +---------+ | 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).
That is, applications communicate with an APEX service by exchanging data with a "well-known endpoint" (WKE).
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 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.
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.
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.
Rose, et al. Experimental [Page 2] RFC 3343 The Application Exchange (APEX) Presence April 2003
Rose, et al. Experimental [Page 2] RFC 3343 The Application Exchange (APEX) Presence April 2003
2. Use and Management of Presence Information
2. Use and Management of Presence Information
Management of presence information falls into three categories:
Management of presence information falls into three categories:
o applications may update the presence information associated with
an endpoint;
o applications may update the presence information associated with an endpoint;
o applications may subscribe to receive presence information
associated with an endpoint; and,
o applications may subscribe to receive presence information associated with an endpoint; and,
o applications may find out who is subscribed to receive presence
information.
o applications may find out who is subscribed to receive presence information.
Each is now described in turn.
Each is now described in turn.
2.1 Update of Presence Information
2.1 Update of Presence Information
When an application wants to modify the presence information associated with an endpoint, it sends a publish operation to the service, e.g.,
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 -- | |
+-------+ +-------+
+-------+ +-------+ | | -- 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 />
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 />
Rose, et al. Experimental [Page 3] RFC 3343 The Application Exchange (APEX) Presence April 2003
Rose, et al. Experimental [Page 3] RFC 3343 The Application Exchange (APEX) Presence April 2003
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").
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").
The service immediately responds with a reply operation containing the same transaction-identifier, e.g.,
The service immediately responds with a reply operation containing the same transaction-identifier, e.g.,
+-------+ +-------+
| | <------- data -- | |
| relay | | pres. |
| | -- ok ---------> | svc. |
+-------+ +-------+
+-------+ +-------+ | | <------- 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 />
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 />
2.2 Distribution of Presence Information
2.2 Distribution of Presence Information
When an application wants to (periodically) receive the presence information associated with an endpoint, it sends a subscribe operation to the service, e.g.,
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 -- | |
+-------+ +-------+
+-------+ +-------+ | | -- 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 />
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 />
Rose, et al. Experimental [Page 4] RFC 3343 The Application Exchange (APEX) Presence April 2003
Rose, et al. Experimental [Page 4] RFC 3343 The Application Exchange (APEX) Presence April 2003
The service immediately responds with a publish operation containing the same transaction-identifier, e.g.,
The service immediately responds with a publish operation containing the same transaction-identifier, e.g.,
+-------+ +-------+
| | <------- data -- | |
| relay | | pres. |
| | -- ok ---------> | svc. |
+-------+ +-------+
+-------+ +-------+ | | <------- 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 />
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.
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.
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.)
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.)
Rose, et al. Experimental [Page 5] RFC 3343 The Application Exchange (APEX) Presence April 2003
Rose, et al. Experimental [Page 5] RFC 3343 The Application Exchange (APEX) Presence April 2003
Either the subscriber or the service may cancel a subscription by sending a terminate operation, e.g.,
Either the subscriber or the service may cancel a subscription by sending a terminate operation, e.g.,
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| | <--------- ok -- | |
+-------+ +-------+
+-------+ +-------+ | | -- 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 />
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. |
+-------+ +-------+
+-------+ +-------+ | | <------- 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 />
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. |
+-------+ +-------+
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 />
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 />
Rose, et al. Experimental [Page 6] RFC 3343 The Application Exchange (APEX) Presence April 2003
Rose, et al. Experimental [Page 6] RFC 3343 The Application Exchange (APEX) Presence April 2003
2.3 Distribution of Watcher Information
2.3 Distribution of Watcher Information
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.,
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 -- | |
+-------+ +-------+
+-------+ +-------+ | | -- 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 />
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.,
The service immediately responds with a reply operation containing the same transaction-identifier, e.g.,
+-------+ +-------+
| | <------- data -- | |
| relay | | pres. |
| | -- ok ---------> | svc. |
+-------+ +-------+
+-------+ +-------+ | | <------- 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 />
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 />
Rose, et al. Experimental [Page 7] RFC 3343 The Application Exchange (APEX) Presence April 2003
Rose, et al. Experimental [Page 7] RFC 3343 The Application Exchange (APEX) Presence April 2003
For each current subscriber, the service immediately sends a notify operation containing the same transaction-identifier, e.g.,
For each current subscriber, the service immediately sends a notify operation containing the same transaction-identifier, e.g.,
+-------+ +-------+
| | <------- data -- | |
| relay | | pres. |
| | -- ok ---------> | svc. |
+-------+ +-------+
+-------+ +-------+ | | <------- 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 />
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.
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.
Rose, et al. Experimental [Page 8] RFC 3343 The Application Exchange (APEX) Presence April 2003
Rose, et al. Experimental [Page 8] RFC 3343 The Application Exchange (APEX) Presence April 2003
Either the watcher or the service may cancel the request by sending a terminate operation, e.g.,
Either the watcher or the service may cancel the request by sending a terminate operation, e.g.,
+-------+ +-------+
| | -- data -------> | |
| appl. | | relay |
| | <--------- ok -- | |
+-------+ +-------+
+-------+ +-------+ | | -- 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 />
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. |
+-------+ +-------+
+-------+ +-------+ | | <------- 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 />
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. |
+-------+ +-------+
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 />
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 />
Rose, et al. Experimental [Page 9] RFC 3343 The Application Exchange (APEX) Presence April 2003
Rose, et al. Experimental [Page 9] RFC 3343 The Application Exchange (APEX) Presence April 2003
3. Format of Presence Entries
3. Format of Presence Entries
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).
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:
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:
o the "publisher" attribute specifies the endpoint associated with
the presence entry;
o the "publisher" attribute specifies the endpoint associated with the presence entry;
o the "lastUpdate" attribute specifies the date and time that the
service last updated the presence entry;
o the "lastUpdate" attribute specifies the date and time that the service last updated the presence entry;
o the "publisherInfo" attribute specifies arbitrary information
about the publisher (using a URI); and,
o the "publisherInfo" attribute specifies arbitrary information about the publisher (using a URI); and,
o each "tuple" element specifies information about an entity
associated with the endpoint.
o each "tuple" element specifies information about an entity associated with the endpoint.
Each "tuple" element has a "destination" attribute, an "availableUntil" attribute, a "tupleInfo" attribute, and contains zero or more "capability" elements:
Each "tuple" element has a "destination" attribute, an "availableUntil" attribute, a "tupleInfo" attribute, and contains zero or more "capability" elements:
o the "destination" attribute identifies the entity as a URI (e.g.,
"apex:fred/appl=im@example.com" or "mailto:fred@flintstone.com");
o the "destination" attribute identifies the entity as a URI (e.g., "apex:fred/appl=im@example.com" or "mailto:fred@flintstone.com");
o the "availableUntil" attribute specifies the latest date and time
that the entity is capable of receiving messages;
o the "availableUntil" attribute specifies the latest date and time that the entity is capable of receiving messages;
o the "tupleInfo" attribute specifies arbitrary information about
the entity (using a URI); and,
o the "tupleInfo" attribute specifies arbitrary information about the entity (using a URI); and,
o each "capability" element contains a specification as to the kinds
of content the entity is capable of receiving.
o each "capability" element contains a specification as to the kinds of content the entity is capable of receiving.
Each "capability" element contains arbitrary character data formatted according to the standard indicated in the element's "baseline" attribute.
Each "capability" element contains arbitrary character data formatted according to the standard indicated in the element's "baseline" attribute.
Rose, et al. Experimental [Page 10] RFC 3343 The Application Exchange (APEX) Presence April 2003
Rose, et al. Experimental [Page 10] RFC 3343 The Application Exchange (APEX) Presence April 2003
4. The Presence Service
4. The Presence Service
Section 5 contains the APEX service registration for the presence service:
Section 5 contains the APEX service registration for the presence service:
o Within an administrative domain, the service is addressed using
the well-known endpoint of "apex=presence".
o Within an administrative domain, the service is addressed using the well-known endpoint of "apex=presence".
o Section 6 defines the syntax of the operations exchanged with the
service.
o Section 6 defines the syntax of the operations exchanged with the service.
o A consumer of the service initiates communications by sending data
containing the subscribe, watch, or publish operation.
o A consumer of the service initiates communications by sending data containing the subscribe, watch, or publish operation.
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 In addition to replying to these operations, the service may also initiate communications by sending data containing the terminate, publish, or notify operations.
An implementation of the service must maintain information about both presence entries and in-progress operations in persistent storage.
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.
Consult Section 6.1.1 of [1] for a discussion on the properties of long-lived transaction-identifiers.
Rose, et al. Experimental [Page 11] RFC 3343 The Application Exchange (APEX) Presence April 2003
Rose, et al. Experimental [Page 11] RFC 3343 The Application Exchange (APEX) Presence April 2003
4.1 Use of XML and MIME
4.1 Use of XML and MIME
Section 4.1 of [1] describes how arbitrary MIME content is exchanged as a BEEP [2] payload. For example, to transmit:
Section 4.1 of [1] describes how arbitrary MIME content is exchanged as a BEEP [2] payload. For example, to transmit:
<data content='...'>
<originator identity='apex=presence@example.com' />
<recipient identity='fred@example.com' />
</data>
<data content='...'> <originator identity='apex=presence@example.com' /> <recipient identity='fred@example.com' /> </data>
where "..." refers to: <reply code='250' transID='1' />
where "..." refers to: <reply code='250' transID='1' />
then the corresponding BEEP message might look like this:
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
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:
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
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
Rose, et al. Experimental [Page 12] RFC 3343 The Application Exchange (APEX) Presence April 2003
Rose, et al. Experimental [Page 12] RFC 3343 The Application Exchange (APEX) Presence April 2003
4.2 The Subscribe Operation
4.2 The Subscribe Operation
When an application wants to (periodically) receive the presence information associated with an endpoint, it sends a "subscribe" element to the service.
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 「出版社」属性は存在エントリーに関連している終点を指定します。
o the "transID" attribute specifies the transaction-identifier
associated with this operation; and,
o "transID"属性はこの操作に関連しているトランザクション識別子を指定します。 そして
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. すぐに、「発行してください」という対象の存在エントリーに対応する要素を創始者に送ります。
Rose, et al. Experimental [Page 13] RFC 3343 The Application Exchange (APEX) Presence April 2003
ローズ、他 実験的な[13ページ]RFC3343アプリケーション交換(頂点)存在2003年4月
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のStep6.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)を発行してください。 示されて、「持続時間」属性が期限が切れて、aが終わる時間に最終的に、操作(セクション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回の投票をしています。 それに従って、上のStep6.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"属性は「申し込んでください」という創始者によって送られた要素で見つけられた値と同じです。
4.3 The Watch Operation
4.3 腕時計操作
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 「出版社」属性は存在エントリーに関連している終点を指定します。
o the "transID" attribute specifies the transaction-identifier
associated with this operation; and,
o "transID"属性はこの操作に関連しているトランザクション識別子を指定します。 そして
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を持っている「回答」要素を創始者に送ります。
Rose, et al. Experimental [Page 14] RFC 3343 The Application Exchange (APEX) Presence April 2003
ローズ、他 実験的な[14ページ]RFC3343アプリケーション交換(頂点)存在2003年4月
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. 購読が終えられる、aが申し込まれるときはいつも、「腕時計」要素の「持続時間」属性によって示された時間まで、操作は成功するか、または「通知してください」という要素を創始者に送ります。 示されて、「持続時間」属性が期限が切れて、aが終わる時間に最終的に、操作(セクション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回の投票をしていることに注意してください。 それに従って、上のStep6.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.
「通知してください」か「回答」要素を創始者に送るかどうかにかかわらず、"transID"属性は創始者によって送られた「存在」要素で見つけられた値と同じです。
4.4 The Publish Operation
4.4、操作を発行してください。
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 「出版社」属性は存在エントリーに関連しているように終点を指定します。
Rose, et al. Experimental [Page 15] RFC 3343 The Application Exchange (APEX) Presence April 2003
ローズ、他 実験的な[15ページ]RFC3343アプリケーション交換(頂点)存在2003年4月
o the "transID" attribute specifies the transaction-identifier
associated with this operation;
o "transID"属性はこの操作に関連しているトランザクション識別子を指定します。
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. 「発行してください」という要素の「出版社」属性が「発行してください」という要素に含まれた「存在」要素の「出版社」属性に合っていないなら、コード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"属性はサービスの現在の日時の概念に設定されます。
Rose, et al. Experimental [Page 16] RFC 3343 The Application Exchange (APEX) Presence April 2003
ローズ、他 実験的な[16ページ]RFC3343アプリケーション交換(頂点)存在2003年4月
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"属性は「発行してください」という創始者によって送られた要素で見つけられた値と同じです。
4.5 The Terminate Operation
4.5、操作を終えてください。
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. トランザクション識別子が前であることの状態でaについて言及しないなら、創始者(コード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.
次のaが操作を終えることに注意してください、そして、創始者はさらなる存在かウォッチャーアップデートを受けてもよいです。 サービスは操作を終えて、回答操作を送る以前のアップデートはそうする処理の後にこれ以上アップデートを送らないでしょうが、トランジットには、いてください。
4.6 The Notify Operation
4.6、操作に通知してください。
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:
「通知してください」という要素には、「動作」属性を持っていますが、「加入者」属性、"transID"属性、「持続時間」属性、どんな内容もありません:
o the "subscriber" attribute specifies the endpoint that is
subscribed to presence information; and,
o 「加入者」属性は存在情報に申し込まれる終点を指定します。 そして
Rose, et al. Experimental [Page 17] RFC 3343 The Application Exchange (APEX) Presence April 2003
ローズ、他 実験的な[17ページ]RFC3343アプリケーション交換(頂点)存在2003年4月
o the "transID" attribute specifies the transaction-identifier
associated with the watch operation that caused this "notify"
element to be sent;
o "transID"属性は「通知してください」というこの要素を送った腕時計操作に関連しているトランザクション識別子を指定します。
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.
受信終点は回答を全く送りません。
4.7 The Reply Operation
4.7 回答操作
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に相談してください。
5. Registration: The Presence Service
5. 登録: 存在サービス
Well-Known Endpoint: apex=presence
よく知られる終点: 頂点=存在
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.、このメモの「作者のアドレス」セクション
6. The Presence Service DTD
6. 存在サービスDTD
<!--
DTD for the APEX presence service, as of 2001-05-08
<!--2001年5月8日付けでAPEX存在サービスのためのDTD
Refer to this DTD as:
このDTDを以下を参照してください。
<!ENTITY % APEXPRESENCE PUBLIC "-//IETF//DTD APEX PRESENCE//EN"
"">
%APEXPRESENCE;
-->
<!実体%APEXPRESENCE公共の「-//IETF//DTD頂点存在//アン」、「「>%APEXPRESENCE」 -->。
<!ENTITY % APEXCORE PUBLIC "-//IETF//DTD APEX CORE//EN" ""> %APEXCORE;
<!実体%APEXCORE公共の「-//IETF//DTD頂点コア//アン」、「「>%APEXCORE」
Rose, et al. Experimental [Page 18] RFC 3343 The Application Exchange (APEX) Presence April 2003
ローズ、他 実験的な[18ページ]RFC3343アプリケーション交換(頂点)存在2003年4月
<!--
Synopsis of the APEX presence service
<!--APEX存在サービスの構文
service WKE: apex=presence
WKEを調整してください: 頂点=存在
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はEMPTY><を申し込みます!ATTLISTは出版社%ENDPOINTを申し込みます。 #transID%UNIQIDが必要でした。 #REQUIRED持続時間%SECONDS。 #必要な>。
<!ELEMENT watch EMPTY>
<!ATTLIST watch
publisher %ENDPOINT; #REQUIRED
transID %UNIQID; #REQUIRED
duration %SECONDS; #REQUIRED>
<!ELEMENTはEMPTY><を見ます!ATTLISTは出版社%ENDPOINTを見ます。 #transID%UNIQIDが必要でした。 #REQUIRED持続時間%SECONDS。 #必要な>。
<!-- publisher attributes must match in publish and presence -->
<!ELEMENT publish (presence)>
<!ATTLIST publish
publisher %ENDPOINT; #REQUIRED
transID %UNIQID; #REQUIRED
timeStamp %TIMESTAMP; #REQUIRED>
><!ELEMENTは(存在)><を発行します!<!--出版社属性、マッチが中で発行する必須と存在--ATTLISTは出版社%ENDPOINTを発行します。 #transID%UNIQIDが必要でした。 #必要なタイムスタンプ%タイムスタンプ。 #必要な>。
Rose, et al. Experimental [Page 19] RFC 3343 The Application Exchange (APEX) Presence April 2003
ローズ、他 実験的な[19ページ]RFC3343アプリケーション交換(頂点)存在2003年4月
<!ELEMENT notify EMPTY>
<!ATTLIST notify
subscriber %ENDPOINT; #REQUIRED
transID %UNIQID; #REQUIRED
duration %SECONDS; "0"
action (subscribe|terminate)
"subscribe">
<!--
presence entries
-->
<!ELEMENTはEMPTY><に通知します!ATTLISTは加入者%ENDPOINTに通知します。 #transID%UNIQIDが必要でした。 #REQUIRED持続時間%SECONDS。 「0インチの動作(申し込んでください| 終わる)、「「><!--存在エントリー-->」を申し込んでください。
<!ELEMENT presence (tuple+)>
<!ATTLIST presence
publisher %ENDPOINT; #REQUIRED
lastUpdate %TIMESTAMP; #REQUIRED
publisherInfo
%URI; "">
<!ELEMENT存在(tuple+)><!ATTLIST存在出版社%ENDPOINT。 #必要なlastUpdate%タイムスタンプ。 #必要なpublisherInfo%URI。 「">"
<!ELEMENT tuple (capability*)>
<!ATTLIST tuple
destination %URI; #REQUIRED
availableUntil
%TIMESTAMP; #REQUIRED
tupleInfo %URI; "">
<!ELEMENT tuple(能力*)><!ATTLIST tuple目的地%URI。 #必要なavailableUntil%タイムスタンプ。 #必要なtupleInfo%URI。 「">"
<!-- e.g., baseline='urn:ietf:rfc:rfc2533' -->
<!ELEMENT capability (#PCDATA)>
<!ATTLIST capability
baseline %URI #REQUIRED>
<!--例えば、基線='つぼ:ietf:rfc: rfc2533'--><!ELEMENT能力(#PCDATA)><!ATTLIST能力基線%URI#REQUIRED>。
Rose, et al. Experimental [Page 20] RFC 3343 The Application Exchange (APEX) Presence April 2003
ローズ、他 実験的な[20ページ]RFC3343アプリケーション交換(頂点)存在2003年4月
7. Security Considerations
7. セキュリティ問題
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: 0インチは使用(それに従って、現地時間を変換した後に)にされるかもしれない」。
References
参照
[1] Rose, M., Klyne, G. and D. Crocker, "The Application Exchange
Core", RFC 3340, July 2002.
[1] ローズとM.とKlyneとG.とD.クロッカー、「アプリケーション交換コア」、RFC3340、2002年7月。
[2] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC
3080, March 2001.
[2] ローズ、M.、「ブロックの広げることができる交換プロトコルコア」、RFC3080、2001年3月。
[3] Rose, M., Klyne, G. and D. Crocker, "The Application Exchange
(APEX) Access Service", RFC 3341, July 2002.
[3] ローズとM.とKlyneとG.とD.クロッカー、「アプリケーション交換(頂点)アクセス・サービス」、RFC3341、2002年7月。
Rose, et al. Experimental [Page 21] RFC 3343 The Application Exchange (APEX) Presence April 2003
ローズ、他 実験的な[21ページ]RFC3343アプリケーション交換(頂点)存在2003年4月
Acknowledgements
承認
The authors gratefully acknowledge the contributions of: Neil Cook, Eric Dixon, Darren New, Scott Pead, and Bob Wyman.
作者は感謝して以下の貢献を承諾します。 ニール・クック、エリック・ディクソン、ダーレンNewのスコットPead、およびボブ・ワイマン。
Authors' Addresses
作者のアドレス
Marshall T. Rose Dover Beach Consulting, Inc. POB 255268 Sacramento, CA 95865-5268 US
Inc.POB255268サクラメント、カリフォルニア95865-5268米国に相談するマーシャル・T.バラドーヴァービーチ
Phone: +1 916 483 8878 EMail: mrose@dbc.mtview.ca.us
以下に電話をしてください。 +1 8878年の916 483メール: mrose@dbc.mtview.ca.us
Graham Klyne Nine by Nine
グラハムKlyne9時9分前
EMail: gk@ninebynine.org
メール: gk@ninebynine.org
David H. Crocker Brandenburg InternetWorking 675 Spruce Drive Sunnyvale, CA 94086 US
デヴィッドH.医者ブランデンブルクインターネットワーキング675は米国でDriveサニーベル、カリフォルニア 94086を小綺麗にします。
Phone: +1 408 246 8253 EMail: dcrocker@brandenburg.com URI: http://www.brandenburg.com/
以下に電話をしてください。 +1 8253年の408 246メール: dcrocker@brandenburg.com ユリ: http://www.brandenburg.com/
Rose, et al. Experimental [Page 22] RFC 3343 The Application Exchange (APEX) Presence April 2003
ローズ、他 実験的な[22ページ]RFC3343アプリケーション交換(頂点)存在2003年4月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Rose, et al. Experimental [Page 23]
ローズ、他 実験的[23ページ]
一覧
スポンサーリンク
