?? rfc 3343 the application exchange (apex) presence service.htm
字號:
| | -- 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 />
</PRE>
<P>or <PRE> +-------+ +-------+
| | <------- 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 />
</PRE>
<P></P>
<DT>
<HR>
<EM><A name=page-7>Page 7</A></EM>
<DD>
<P></P>
<DT><STRONG><A name=sec-2.3>2.3</A> Distribution of Watcher
Information</STRONG>
<DD>
<P>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.,
<P><PRE> +-------+ +-------+
| | -- 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 />
</PRE>
<P>The service immediately responds with a reply operation containing the same
transaction-identifier, e.g.,
<P><PRE> +-------+ +-------+
| | <------- 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 />
</PRE>
<P></P>
<DT>
<HR>
<EM><A name=page-8>Page 8</A></EM>
<DD>
<P>For each current subscriber, the service immediately sends a notify
operation containing the same transaction-identifier, e.g.,
<P><PRE> +-------+ +-------+
| | <------- 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 />
</PRE>
<P>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.
<P></P>
<DT>
<HR>
<EM><A name=page-9>Page 9</A></EM>
<DD>
<P>Either the watcher or the service may cancel the request by sending a
terminate operation, e.g.,
<P><PRE> +-------+ +-------+
| | -- 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 />
</PRE>
<P>or <PRE> +-------+ +-------+
| | <------- 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 />
</PRE>
<P></P>
<DT>
<HR>
<EM><A name=page-10>Page 10</A></EM>
<DD>
<P></P>
<DT><STRONG><A name=sec-3>3</A> Format of Presence Entries</STRONG>
<DD>
<P>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).
<P><A href="http://www.apps.ietf.org/rfc/rfc3343.html#sec-6">Section 6</A>
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:
<P>
<UL>
<LI>the "publisher" attribute specifies the endpoint associated with the
presence entry;
<P></P>
<LI>the "lastUpdate" attribute specifies the date and time that the service
last updated the presence entry;
<P></P>
<LI>the "publisherInfo" attribute specifies arbitrary information about the
publisher (using a URI); and,
<P></P>
<LI>each "tuple" element specifies information about an entity associated
with the endpoint. </LI></UL>
<P>Each "tuple" element has a "destination" attribute, an <BR>"availableUntil"
attribute, a "tupleInfo" attribute, and contains zero or more "capability"
elements:
<P>
<UL>
<LI>the "destination" attribute identifies the entity as a URI (e.g.,
"apex:fred/appl=im@example.com" or "mailto:fred@flintstone.com");
<P></P>
<LI>the "availableUntil" attribute specifies the latest date and time that
the entity is capable of receiving messages;
<P></P>
<LI>the "tupleInfo" attribute specifies arbitrary information about the
entity (using a URI); and,
<P></P>
<LI>each "capability" element contains a specification as to the kinds of
content the entity is capable of receiving. </LI></UL>
<P>Each "capability" element contains arbitrary character data formatted
according to the standard indicated in the element's "baseline" attribute.
<P></P>
<DT>
<HR>
<EM><A name=page-11>Page 11</A></EM>
<DD>
<P></P>
<DT><STRONG><A name=sec-4>4</A> The Presence Service</STRONG>
<DD>
<P><A href="http://www.apps.ietf.org/rfc/rfc3343.html#sec-5">Section 5</A>
contains the APEX service registration for the presence service:
<P>
<UL>
<LI>Within an administrative domain, the service is addressed using the
well-known endpoint of "apex=presence".
<P></P>
<LI><A href="http://www.apps.ietf.org/rfc/rfc3343.html#sec-6">Section 6</A>
defines the syntax of the operations exchanged with the service.
<P></P>
<LI>A consumer of the service initiates communications by sending data
containing the subscribe, watch, or publish operation.
<P></P>
<LI>In addition to replying to these operations, the service may also
initiate communications by sending data containing the terminate, publish,
or notify operations. </LI></UL>
<P>An implementation of the service must maintain information about both
presence entries and in-progress operations in persistent storage.
<P>Consult Section 6.1.1 of [1] for a discussion on the properties of
long-lived transaction-identifiers.
<P></P>
<DT>
<HR>
<EM><A name=page-12>Page 12</A></EM>
<DD>
<P></P>
<DT><STRONG><A name=sec-4.1>4.1</A> Use of XML and MIME</STRONG>
<DD>
<P>Section 4.1 of [1] describes how arbitrary MIME content is exchanged as a
BEEP [2] payload. For example, to transmit:
<P><PRE> <data content='...'>
<originator identity='apex=presence@example.com' />
<recipient identity='fred@example.com' />
</data>
</PRE>
<P>where "..." refers to: <reply code='250' transID='1' />
<P>then the corresponding BEEP message might look like this:
<P><PRE> 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
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -