SIMPLE J. Ala-Kurikka Internet-Draft M. Ylianttila Expires: January 6, 2006 E. Harjula Univ. of Oulu July 5, 2005 Mapping non-URIs to contact element in Presence Information Data Format draft-ala-kurikka-simple-map2pidf-00 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 January 6, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract The Presence Information Data Format (PIDF) defines a basic XML format for presence information. The contact element in PIDF is understood as a URI. However, some existing Internet services do not identify users (presentities) natively with a URI. Mapping non-URIs to contact element in Presence Information Data Format (Map2PIDF) specifies the mapping of addresses to a URI in the case of such currently existing services. Ala-Kurikka, et al. Expires January 6, 2006 [Page 1] Internet-Draft Map2PIDF July 2005 1. Introduction The Presence Information Data Format (PIDF) [1] defines a basic XML format for presenting presence information of a presentity. Presence tuples [2] have an optional element. The contents of the element are understood to refer to a URI [3]. There are, however, services and applications in the Internet that do not natively use URIs to identify users, and/or the mapping of users to URIs is more or less cumbersome. Examples include Instant Messaging, VoIP and peer-to-peer for file sharing. While PIDF seems flexible enough to handle also such communication addresses, it would be helpful if users' capability of communicating with such services that do not share a common naming convention could also be announced with PIDF. This document specifies how to map user names from a such services to a presentity's element. One goal of this specification is to be backwards compatible with PIDF. This would ensure that existing non-Map2PIDF watchers and gateways will continue to work properly, without access to the functionality specified here. Old User Agents (later UAs) would not know how to act with URIs with these new schemes. However, if the contents of elements were to be shown in plain text form to a user acting as a watcher, he/she could possibly understand the form and follow the link manually (e.g. by opening a file sharing client program and connecting to a hub that the presentity is connected to). At this phase, no action has been taken to filter URIs with formerly undefined schemes defined in this document from presence information for watchers or gateways that do not conform to this specification. It is assumed that URIs with these new schemes in the presence information do not hinder UAs or gateways from reading the tuples that have well-known schemes according to "Handling of Unrecognized Element Names" in PIDF. 1.1 Motivation The PIDF specification does not rule out the set of supported communication means. The only requirement set is that the communication address has to be expressed with a URI. However, some application level protocols - of which some are proprietary - use naming conventions other than URIs to define individual presentities. While these are normally ruled out so that their addresses would never be added to a presentity tuple, this is an excellent opportunity for adding connectivity awareness for PIDF. Providing listing of the ways that a presentity can communicate with would be a major advantage for SIP [4] leveraging SIP's status as a necessity for all interconnected IP devices, being the unifying factor. Ala-Kurikka, et al. Expires January 6, 2006 [Page 2] Internet-Draft Map2PIDF July 2005 Of course, details on supported application level protocols could also be queried from remote UAs after establishing a session with them. Having that information without a session initiation with the remote UA could, however, prove an important feature. Queries such as "who of my friends are using Skype" would probably be more efficient with a centrally managed presence information service than with having to establish sessions to all friends first. Mapping the "non-URIs" to a URI without a standard way could also be used. But this would limit the usefulness of the presence tuple to what the user can do, and even this only if the mapped URI would be shown to the user in plain text form. There are many useful scenarios where an automata would benefit from being able to understand all the different ways of interaction (i.e. communication addresses) of a presentity, say, a user's friend. The UA could then provide e.g. a list of different possible operations with the friend to the user. Or it could suggest using less costly Skype URI to establish a telephone call instead of using a more expensive tel URI, if the friend had one in one of his presence tuples. Such feature would probably prove especially useful in mobile devices because of their limited resources, including processing capabilities, memory and screen. Also user friendliness could be substantially better with one UI to control actions in several protocols instead of multiple separate applications, one for each protocol. The need for such multiprotocol communication will be even bigger in the future, as there seems to be no consensus on which protocol to use for e.g. file sharing. This leads often to loss of interoperability. A certain type of interoperability would be made possible, though, with the proposed specification. 1.2 Terminology and Conventions This memo makes use of the vocabulary defined in the IMPP Model document [2]. Terms such as COMMUNICATION ADDRESS, COMMUNICATION MEANS, CONTACT ADDRESS, and PRESENTITY in the memo are used in the same meaning as defined therein. The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14, RFC 2119 [5]. Ala-Kurikka, et al. Expires January 6, 2006 [Page 3] Internet-Draft Map2PIDF July 2005 2. Mapping Every protocol being mapped to a URI MUST have a well-defined, individual URI scheme. Schemes do not exist for the protocols specified in this document. Schemes for non-existing protocols MUST be formulated through the following process (conforms with [5]): The official name of the protocol is converted to lowercase, removed of any special characters (including white space) other than digits, plus ("+"), period (".") or hyphen ("-"). If the name's first character is a digit, replace the digit with the first character of the written English form in lowercase (e.g. 1->one->o) Ala-Kurikka, et al. Expires January 6, 2006 [Page 4] Internet-Draft Map2PIDF July 2005 3. Example Using a default XML namespace: open skype:joe This would indicate to a WATCHER that the PRESENTITY Joe@example.com is registered to Skype with a user name of "joe" and that his Skype client is online, so Joe is able to receive VoIP calls. Ala-Kurikka, et al. Expires January 6, 2006 [Page 5] Internet-Draft Map2PIDF July 2005 4. Implementing Map2PIDF Our specification would benefit from some way of exchanging presence information between SIP UAs [4] providing PRESENCE INFORMATION and other applications (possibly UAs) communicating with other protocols. One way of doing this would be to enable the SIP UA itself to be able to communicate with various other protocols as well as SIP. Another possibility would be to have interfaces between applications (or UAs) through which presence information for different protocols could be exchanged. If no such intercommunication of applications can be achieved, presence information provided to other protocols might be harder to obtain by the SIP UA. This would, on the other hand, restrict functionality. The SIP UA would not know if the device was online with other protocols, therefore suggestions of using other protocols might lead to useless attempts. Operating system level application search and start capabilities could still be used to e.g. invoke an external application to establish a VoIP session. Ala-Kurikka, et al. Expires January 6, 2006 [Page 6] Internet-Draft Map2PIDF July 2005 5. Security Considerations Exposing PIDF information to others requires security mechanisms itself. However, they are already specified in the PIDF specification. Map2PIDF reveals some more information, such as 3rd party applications installed and/or running on a PRESENTITY's device. Care has to be taken, and the developer should pay special attention to all notes in the PIDF security considerations. The 3rd party applications might have security vulnerabilities themselves, however, addressing them is out of scope of this document. If a password to a certain server (or similar) was to be included in a PRESENTITY's PRESENCE INFORMATION to enable certain (perhaps selected) set of WATCHERs to gain access to the server, S/MIME [6] MUST be used for staging security at least for that PRESENCE TUPLE. Otherwise the password is exposed almost certainly allowing eavesdroppers to also gain access to the server using the WATCHER's privileges. 6. References [1] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004. [2] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. [3] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [4] 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. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [6] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004. Ala-Kurikka, et al. Expires January 6, 2006 [Page 7] Internet-Draft Map2PIDF July 2005 Authors' Addresses Jussi Ala-Kurikka MediaTeam / University of Oulu Department of Electrical and Information Engineering Information Processing Laboratory P.O.BOX 4500 University of Oulu 90014 FI Phone: +358 44 304 0098 Email: jussi.ala-kurikka@oulu.fi URI: http://www.mediateam.oulu.fi Mika Ylianttila MediaTeam / University of Oulu Department of Electrical and Information Engineering Information Processing Laboratory P.O.BOX 4500 University of Oulu 90014 FI Phone: +358 40 535 0505 Email: mika.ylianttila@oulu.fi URI: http://www.ee.oulu.fi/~over Erkki Harjula MediaTeam / University of Oulu Department of Electrical and Information Engineering Information Processing Laboratory P.O.BOX 4500 University of Oulu 90014 FI Phone: +358 50 303 0478 Email: erkki.harjula@oulu.fi URI: http://www.mediateam.oulu.fi Ala-Kurikka, et al. Expires January 6, 2006 [Page 8] Internet-Draft Map2PIDF July 2005 Appendix A. Acknowledgments The authors would like to thank the Application Supernetworking (All-IP) project partners: the National Technology Agency (TEKES), Nokia, TeliaSonera Finland, Elektrobit Group, IBM and Serv-It for their financial support and Henning Schulzrinne for his comments during the early phases of sketching the idea. Ala-Kurikka, et al. Expires January 6, 2006 [Page 9] Internet-Draft Map2PIDF July 2005 Intellectual Property Statement 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 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Ala-Kurikka, et al. Expires January 6, 2006 [Page 10]