Simple Working Group Hao Wang Internet-Draft Qian Sun Intended status: Informational Huawei Technologies Expires: December 25, 2007 June 27, 2007 A Clarification for Offline Status Assigned by Presence Application draft-howard-simple-offline-status-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 25, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract 'Offline' status assigned by presence application usually mean that the presence application will expect his watcher thinks he is not online, though he may actually be online. According current specifications of presence service, the watcher may have a way to find out some clues to identify the truth. Such leak of specifications will make confusion in implementation. Here try to state a clarification for thus issue. 1. Introduction Session Initiation Protocol (SIP) Extension for Event State Publication [RFC3903] allows Presence User Agents ('PUA') to publish presence information of a user ('presentity'). The Howard Expires December 27, 2007 [Page 1] Internet-Draft offline in Presence June 2007 Presence Agent ('PA') collects publication information from one or several PUA, generates the composite event state of the presentity; and allow other user ('watcher') to subscribe to the presentity in order to learn his presence information. The presentity can use a mean, named as Notifier, to delivery his own presence information to other watchers who had subscribed. On other hand the presentity can also use a mean, named as Fetcher, to get presence information of his watcher, whom had subscribed already. Presence publication by default uses the PIDF document format, and each publication contains full state regardless of how much of the presence information has actually changed since the previous update. In fact while a presentity want to hide him invisible as 'off line' status though he is actually online, he can assign with 'offline' status to stop his Notifier to delivery off 'online' information to those watchers who had subscribed, then his user name will not appear in his watchers' 'online' page. However, his Fetcher may still fetch the presence information of his watchers, usually symmetrical presentity is also a subscriber of presence information of his watcher. In such situation, the watcher can identify that the presentity is still online instead of his appearance 'offline'. It is indeterminacy in presence service specifications and will cause leak in implementation. Although this document is an analysis document and not a BCP document, a possible optimizations is listed in addition to an initial set of requirements for what should be the characteristic of the solution to the problem stated in the document This document is intended to be used by the SIMPLE WG in order to work on possible solutions that will make the deployment of a presence server more reasonable task. Note that the document does not try to compare the SIP based presence server to other types of presence servers but only analyses the SIP based presence server. This memo tries to clarify this leak and is structured in such a way: Section 3 gives an overview of the indeterminacy on 'off-line' for presence implements; Section 4 includes proposed detailed solution; Section 5 includes discussion of security considerations; and Section 6 includes examples of publication for assign 'off-line'. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119, and indicate requirement levels for compliant implementations. Howard Expires December 27, 2007 [Page 2] Internet-Draft offline in Presence June 2007 This document makes use of the vocabulary defined in the Model for Presence and Instant Messaging [RFC2778], and the Event State Publication Extension to SIP [RFC3903]. 3. Overview of the indeterminacy on 'off-line' status Although current specifications had defined some rules to composite with tuples in the document of presence service, it still omit the clues for 'offline' status. Further regard to thus 'offline' status, it may cause consequence arising in IOP & relevant for IMS; and make special meaning when the presentity try to subscribe status of himself. 3.1 Clarification for 'offline' vs. 'unknown' Presentity can usually be in such a status 'unknown' or 'offline' beyond in 'online' status, but 'offline' status is not as same as 'unknown' status. The status 'unknown' would apply if a Notifier or a Watcher is not able to gather consistent presence information about the presentity. It usually happen when the presentity lost communication between his PUA and PA, then the PA does not have any consistent published information from PUA to composite a valid event state of the presentity. The status 'offline' would apply when the Notifier got information that the Presentity is actually 'offline' or unavailable ( closed in PIDF terms). Among 'offline' status of a presentity, the appearance, shown as 'offline' but the presentity is actually reachable, can be achieved by publishing presence information with status tuples marked as 'closed', while the actual communication with the service is not dropped down. 3.2 Communication approach The fact, a PA publishes its PUA availability as 'closed' status, may not necessarily mean that the presentity is actually unreachable for that application. The dialog maintained between a presence source and Presence Server ('PS') is independent from the communications that are actually maintained between any other SIP applications residing in a client device and the corresponding application server that hosts that application. Additionally, the communication that a Presence Source establishes with a PS is independent of the SIP subscription that a Watcher (possibly co-located with the Presence Source) establishes to receive Presence information about other contacts (i.e.: nothing would prevent publishing one s status as 'offline', while still Howard Expires December 27, 2007 [Page 3] Internet-Draft Offline in Presence June 2007 receiving Presence information about his contacts). 3.3. Behavior of presentity under 'offline' status While presentity has published as 'offline' status, its Notifier will stop in general to deliver presence information to his watchers, who had subscribed, since last time the presentity published for 'offline' status. The watcher will keep up the status of the presentity as 'offline' status published in last time till updated by the presentity in next time. But because the presentity is still keep communication alive in fact, his Fetcher can take behaviors in different way to request or not for presence information of his watchers. It depended on the implementation in detail and there is none relevant clarifications in current request specifications. It will cause ambiguity for users communicating from different implementations of presence service. 3.3.1 Implementation 1 --- Fetcher stop After the PUA generated a complete 'offline' PIDF file of presence information of a presentity and PUBLISH the file to presence service as his presence scheme, his Fetcher can stop request of collecting other watcher's presence information. Then the watcher or its PA will not receive request from PA of the presentity and need not responds with such requests, just like the presentity has dropped down communication from presence service. The watcher can deduct out only one conclusion that the presentity is real offline? 3.3.2 Implementation 2 --- Fetcher alive After the PUA of presentity PUBLISH to presence service as 'offline' status, his Fetcher may keep on requesting to collect other watcher's presence information; especially some pollers sent such request on a regular basis. Then the watcher or its PA will receive such request from PA of the presentity and has to responds with watcher's presence information, just like the presentity has not published for 'offline' status. Then the watcher may have two deductions on status of the presentity depend on different implementations: 1) The watcher does responds for any requests about its presence information and not care whom the request come from. Thus the watcher knows about the status just as 'offline' status as published by the original presentity. 2) The watcher check about published status of a presentity, who is Howard Expires December 27, 2007 [Page 4] Internet-Draft offline in Presence June 2007 requesting for presence information, and found originally published status as 'offline' status, then watcher will realize that this presentity is only appeared as 'offline' status and reachable in fact. For showing in easiest way, here gives an extremely case for above issue --- one presentity has subscribed own presence status and try to assign as 'offline' status, he will meet such a puzzle --- he can always find he is active in 'online' status, although he has assigned himself as 'offline' already. It is out of scope of this document what consequence will happen when the watcher found the truth. But it definitely is opposite to the assumption of original presentity. 3.3.3 Rely on 'note' In some case, it can use the 'note' element to mark functionally update of presence status in presence document. Relying on the 'note' element is not a proper way to ensure that implementations will interoperate smoothly. is supposed to be understood by humans, so Notifier is not supposed to process it. In fact, RFC 2778 discourages its usage to substitute the status of its parent element. 3.4 Issue arise in IOP According above 3.3.2, there should be some confusion for presentity of presence service that use implementations with different presence principle. Then it should bring up an IOP issue in presence service. 3.5 IMS relevant Above discussion is in scope of presence specifications in SIMPLE group, it may be different in IMS relevant, which may be wise / feasible to overrule the IMS registration status in 3GPP SIP deployments (i.e.: it seems difficult to publish an "IMS unregistered" status, and still try to be registered to the IMS). 4. Proposed solution Here try to propose a simple way as solution for this issue, though it may not be a full complete solution. If the PA of presentity does Fetcher to a watcher, usually implement by 'SUBSCRIBE', with a 'filter' condition to indicate PS update the watcher exclude the fact --- which the Fetcher is inquiring about presence status of the watchers. And PS will follow the indication not to notice the watcher about the inquiry, although PS will notice Howard Expires December 27, 2007 [Page 5] Internet-Draft offline in Presence June 2007 the watcher by default in general. Then above ambiguities issue will become a single case of presence status. Fetcher PA PS Watcher PA | F1 SUBSCRIBE | | |------------------>| | | F2 200 OK | | |<------------------| | | | Update presence | | |------------------------>| | | exclude the 'subscribe' | Message Details F1 SUBSCRIBE Fetcher PA->example.com server SUBSCRIBE sip:resource@example.com SIP/2.0 Via: SIP/2.0/TCP fetcherhost.example.com;branch=z9hG4bKnashds7 To: From: ;tag=xfg9 Call-ID: 2010@fetcherhost.example.com CSeq: 17766 SUBSCRIBE Max-Forwards: 70 Event: presence Accept: application/pidf+xml Contact: Expires: 600 Content-Length: 0 F2 200 OK example.com server->Fetcher PA SIP/2.0 200 OK Via: SIP/2.0/TCP fetcherhost.example.com;branch=z9hG4bKnashds7 ;received=192.0.2.1 To: ;tag=ffd2 From: ;tag=xfg9 Call-ID: 2010@fetcherhost.example.com CSeq: 17766 SUBSCRIBE Contact: sip:server.example.com Expires: 600 Content-Length: 0 5. Security considerations Whatever this solution could be considered as BCP, it would be seen as a potential way of accomplishing the requested goal. Usually the presentity subscribes also symmetrically to his watcher, any his inquiries is with authority by the watcher, then it won't override Howard Expires December 27, 2007 [Page 6] Internet-Draft offline in Presence June 2007 the rule of PS whether the Fetcher indicates PS not update with watcher. 6. Appendix A. Acknowledgments This document is based on discussions within the IETF SIMPLE working group. Krisztian Kiss, Peili Xu provided helpful input. 7. References 7.1. Normative references [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004. [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. 7.2. Informative references [RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006. [RFC4480] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg, "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)", RFC 4480, July 2006. [RFC4481] Schulzrinne, H., "Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals", RFC 4481, July 2006. [RFC4482] Schulzrinne, H., "CIPID: Contact Information for the Presence Information Data Format", RFC 4482, July 2006. Howard Expires December 27, 2007 [Page 7] Internet-Draft offline in Presence June 2007 8. IANA Considerations This document does not request any IANA actions. 9. Author's Addresses Hao Wang Huawei Technologies Co.,Ltd. Huawei Base, Bantian Shenzhen, P.R. of China, 518129 Phone: +86 755 2878 0808 Email: howard.wang@huawei.com Qian Sun Huawei Technologies Co., Ltd. Huawei Base, Bantian Shenzhen, P.R China, 518129 Phone: +86 755 28780808 Email: sunqian@huawei.com Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the Howard Expires December 27, 2007 [Page 8] Internet-Draft offline in Presence June 2007 use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.