⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 rfc 3343 the application exchange (apex) presence service.htm

📁 有关IMS SIP及Presence应用的RFC文档包
💻 HTM
📖 第 1 页 / 共 4 页
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3c.org/TR/1999/REC-html401-19991224/loose.dtd">
<!-- saved from url=(0041)http://www.apps.ietf.org/rfc/rfc3343.html -->
<HTML><HEAD><TITLE>RFC 3343</TITLE>
<META http-equiv=Content-Type content="text/html; charset=gb2312">
<META content="MSHTML 6.00.2900.3059" name=GENERATOR></HEAD>
<BODY>
<TABLE width="100%">
  <TBODY>
  <TR>
    <TD vAlign=top align=left>Network Working Group<BR>Request for Comments: 
      3343<BR>Category: Experimental<BR>
    <TD vAlign=top align=right>M. Rose<BR>Dover Beach Consulting, Inc.<BR>G. 
      Klyne<BR>Nine by Nine<BR>D. Crocker<BR>Brandenburg 
      InternetWorking<BR>April 2003<BR></TD></TR></TBODY></TABLE><EM><A 
name=page-1>Page 1</A></EM>
<P>
<H3 align=center>The Application Exchange (APEX) Presence Service</H3>
<P>
<DL>
  <DT>Status of this Memo
  <DD>
  <P>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. 
  <P></P>
  <DT>Copyright Notice
  <DD>
  <P>Copyright &copy; The Internet Society (2003). All Rights Reserved. 
  <P></P>
  <DT>Abstract
  <DD>
  <P>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. 
  <P></P>
  <DT>Table of Contents
  <DD>
  <P><A href="http://www.apps.ietf.org/rfc/rfc3343.html#sec-1">1. Introduction 
  </A><BR><A href="http://www.apps.ietf.org/rfc/rfc3343.html#sec-2">2. Use and 
  Management of Presence Information </A><BR><A 
  href="http://www.apps.ietf.org/rfc/rfc3343.html#sec-2.1">2.1 Update of 
  Presence Information </A><BR><A 
  href="http://www.apps.ietf.org/rfc/rfc3343.html#sec-2.2">2.2 Distribution of 
  Presence Information </A><BR><A 
  href="http://www.apps.ietf.org/rfc/rfc3343.html#sec-2.3">2.3 Distribution of 
  Watcher Information </A><BR><A 
  href="http://www.apps.ietf.org/rfc/rfc3343.html#sec-3">3. Format of Presence 
  Entries </A><BR><A href="http://www.apps.ietf.org/rfc/rfc3343.html#sec-4">4. 
  The Presence Service </A><BR><A 
  href="http://www.apps.ietf.org/rfc/rfc3343.html#sec-4.1">4.1 Use of XML and 
  MIME </A><BR><A href="http://www.apps.ietf.org/rfc/rfc3343.html#sec-4.2">4.2 
  The Subscribe Operation </A><BR><A 
  href="http://www.apps.ietf.org/rfc/rfc3343.html#sec-4.3">4.3 The Watch 
  Operation </A><BR><A 
  href="http://www.apps.ietf.org/rfc/rfc3343.html#sec-4.4">4.4 The Publish 
  Operation </A><BR><A 
  href="http://www.apps.ietf.org/rfc/rfc3343.html#sec-4.5">4.5 The Terminate 
  Operation </A><BR><A 
  href="http://www.apps.ietf.org/rfc/rfc3343.html#sec-4.6">4.6 The Notify 
  Operation </A><BR><A 
  href="http://www.apps.ietf.org/rfc/rfc3343.html#sec-4.7">4.7 The Reply 
  Operation </A><BR><A href="http://www.apps.ietf.org/rfc/rfc3343.html#sec-5">5. 
  Registration: The Presence Service </A><BR><A 
  href="http://www.apps.ietf.org/rfc/rfc3343.html#sec-6">6. The Presence Service 
  DTD </A><BR><A href="http://www.apps.ietf.org/rfc/rfc3343.html#sec-7">7. 
  Security Considerations </A><BR><A 
  href="http://www.apps.ietf.org/rfc/rfc3343.html#page-21">References </A>
  <P></P>
  <DT>
  <HR>
  <EM><A name=page-2>Page 2</A></EM>
  <DD>
  <P><A 
  href="http://www.apps.ietf.org/rfc/rfc3343.html#page-22">Acknowledgements 
  </A><BR><A href="http://www.apps.ietf.org/rfc/rfc3343.html#page-22">Authors' 
  Addresses </A><BR><A 
  href="http://www.apps.ietf.org/rfc/rfc3343.html#page-23">Full Copyright 
  Statement </A><BR></P>
  <DT><STRONG><A name=sec-1>1</A> Introduction</STRONG>
  <DD>
  <P>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. 
  <P>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., 
  <P><PRE>      +----------+     +----------+    +----------+    +---------+
      |   APEX   |     |   APEX   |    |   APEX   |    |         |
      |  access  |     | presence |    |  report  |    |   ...   |
      | service  |     |  service |    | service  |    |         |
      +----------+     +----------+    +----------+    +---------+
           |                |               |               |
           |                |               |               |
   +----------------------------------------------------------------+
   |                                                                |
   |                            APEX core                           |
   |                                                                |
   +----------------------------------------------------------------+
</PRE>
  <P>That is, applications communicate with an APEX service by exchanging data 
  with a "well-known endpoint" (WKE). 
  <P>APEX applications communicate with the presence service by exchanging data 
  with the well-known endpoint "apex=presence" in the <BR>corresponding 
  administrative domain, e.g., <BR>"apex=presence@example.com" is the endpoint 
  associated with the presence service in the "example.com" administrative 
  domain. 
  <P>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. 
  <P></P>
  <DT>
  <HR>
  <EM><A name=page-3>Page 3</A></EM>
  <DD>
  <P></P>
  <DT><STRONG><A name=sec-2>2</A> Use and Management of Presence 
  Information</STRONG>
  <DD>
  <P>Management of presence information falls into three categories: 
  <P>
  <UL>
    <LI>applications may update the presence information associated with an 
    endpoint; 
    <P></P>
    <LI>applications may subscribe to receive presence information associated 
    with an endpoint; and, 
    <P></P>
    <LI>applications may find out who is subscribed to receive presence 
    information. </LI></UL>
  <P>Each is now described in turn. 
  <P></P>
  <DT><STRONG><A name=sec-2.1>2.1</A> Update of Presence Information</STRONG>
  <DD>
  <P>When an application wants to modify the presence information associated 
  with an endpoint, it sends a publish operation to the service, e.g., 
  <P><PRE>       +-------+                  +-------+
       |       | -- data -------&gt; |       |
       | appl. |                  | relay |
       |       | &lt;--------- ok -- |       |
       +-------+                  +-------+

     C: &lt;data content='#Content'&gt;
            &lt;originator identity='fred@example.com' /&gt;
            &lt;recipient identity='apex=presence@example.com' /&gt;
            &lt;data-content Name='Content'&gt;
                &lt;publish publisher='fred@example.com' transID='1'
                         timeStamp='2000-05-14T13:30:00-08:00'&gt;
                    &lt;presence publisher='fred@example.com'
                           lastUpdate='2000-05-14T13:02:00-08:00'
                           publisherInfo='<A href="http://www.example.com/fred/'">http://www.example.com/fred/'</A>&gt;
                        &lt;tuple
                          destination='apex:fred/appl=im@example.com'
                          availableUntil='2000-05-14T14:02:00-08:00' /&gt;
                        &lt;tuple destination='mailto:fred@flintstone.com'
                          availableUntil='2525-12-31T23:59:59-08:00' /&gt;
                    &lt;/presence&gt;
                &lt;/publish&gt;
            &lt;/data-content&gt;
        &lt;/data&gt;
     S: &lt;ok /&gt;
</PRE>
  <P></P>
  <DT>
  <HR>
  <EM><A name=page-4>Page 4</A></EM>
  <DD>
  <P>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., <BR>"im:fred@example.com"). 
  <P>The service immediately responds with a reply operation containing the same 
  transaction-identifier, e.g., 
  <P><PRE>                                  +-------+                  +-------+
                                  |       | &lt;------- data -- |       |
                                  | relay |                  | pres. |
                                  |       | -- ok ---------&gt; |  svc. |
                                  +-------+                  +-------+

     C: &lt;data content='#Content'&gt;
            &lt;originator identity='apex=presence@example.com' /&gt;
            &lt;recipient identity='fred@example.com' /&gt;
            &lt;data-content Name='Content'&gt;
                &lt;reply code='250' transID='1' /&gt;
            &lt;/data-content&gt;
        &lt;/data&gt;
     S: &lt;ok /&gt;
</PRE>
  <P></P>
  <DT><STRONG><A name=sec-2.2>2.2</A> Distribution of Presence 
  Information</STRONG>
  <DD>
  <P>When an application wants to (periodically) receive the presence 
  information associated with an endpoint, it sends a subscribe operation to the 
  service, e.g., 
  <P><PRE>       +-------+                  +-------+
       |       | -- data -------&gt; |       |
       | appl. |                  | relay |
       |       | &lt;--------- ok -- |       |
       +-------+                  +-------+

     C: &lt;data content='#Content'&gt;
            &lt;originator identity='wilma@example.com' /&gt;
            &lt;recipient identity='apex=presence@example.com' /&gt;
            &lt;data-content Name='Content'&gt;
                &lt;subscribe publisher='fred@example.com' duration='86400'
                           transID='100' /&gt;
            &lt;/data-content&gt;
        &lt;/data&gt;
     S: &lt;ok /&gt;
</PRE>
  <P></P>
  <DT>
  <HR>
  <EM><A name=page-5>Page 5</A></EM>
  <DD>
  <P>The service immediately responds with a publish operation containing the 
  same transaction-identifier, e.g., 
  <P><PRE>                                  +-------+                  +-------+
                                  |       | &lt;------- data -- |       |
                                  | relay |                  | pres. |
                                  |       | -- ok ---------&gt; |  svc. |
                                  +-------+                  +-------+

     C: &lt;data content='#Content'&gt;
            &lt;originator identity='apex=presence@example.com' /&gt;
            &lt;recipient identity='wilma@example.com' /&gt;
            &lt;data-content Name='Content'&gt;
                &lt;publish publisher='fred@example.com' transID='100'
                         timeStamp='2000-05-14T13:30:00-08:00'&gt;
                    &lt;presence publisher='fred@example.com'
                           lastUpdate='2000-05-14T13:02:00-08:00'
                           publisherInfo='<A href="http://www.example.com/fred/'">http://www.example.com/fred/'</A>&gt;
                        &lt;tuple
                          destination='apex:fred/appl=im@example.com'
                          availableUntil='2000-05-14T14:02:00-08:00' /&gt;
                    &lt;/presence&gt;
                &lt;/publish&gt;
            &lt;/data-content&gt;
        &lt;/data&gt;
     S: &lt;ok /&gt;
</PRE>
  <P>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. 
  <P>Note that Step 5 of <A 
  href="http://www.apps.ietf.org/rfc/rfc3343.html#sec-4.4">Section 4.4</A> 
  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. 
  <BR>(Regardless, administrators should ensure that applications authorized to 
  update a presence entry are also authorized to retrieve that entry.) 
  <P></P>
  <DT>
  <HR>
  <EM><A name=page-6>Page 6</A></EM>
  <DD>
  <P>Either the subscriber or the service may cancel a subscription by sending a 
  terminate operation, e.g., 
  <P><PRE>       +-------+                  +-------+

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -