Internet Draft A. Roychowdhury Expires: Nov 2007 Hughes Systique Corp. June 1, 2007 Motivation for RSS Feed for Presence State draft-roy-presencerss-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 December 1, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract RSS Feeds have always played an important role in providing users content related updates typically of Websites without having to visit those websites manually. Typical examples of RSS usage include users 'subscribing' to the RSS feed of a website, say, CNN.com and thereby automatically receiving 'news headlines' when the content changes. Roychowdhury Expires Nov 2007 [Page 1] Internet-Draft Motivation for RSS Feed for Presence State Recently, there have been significant innovations (such as Yahoo Pipes and Google Mash-up Editor) where RSS feeds from different sources have been combined to produce new services in a 'Web Based Service Creation Environment' model allowing users to create interesting services building on top of 'primitives' that can be represented on the Web. This document describes the motivation for an RSS feed for Presence information, which the authors believe would be useful to create new services using a similar environment described above. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. Roychowdhury Expires December 1, 2007 [Page 2] Internet-Draft Motivation for RSS Feed for Presence State Table of Contents 1. Introduction to Web based Mash-ups and RSS.....................4 2. Use Cases for Presence State represented as RSS................7 3. Security Considerations........................................8 4. IANA Considerations............................................8 5. Conclusions & Further work.....................................9 6. Acknowledgments................................................9 7. References....................................................10 7.1. Normative................................................10 7.2. Informative..............................................10 Author's Addresses...............................................11 Intellectual Property Statement..................................11 Disclaimer of Validity...........................................11 Roychowdhury Expires December 1, 2007 [Page 3] Internet-Draft Motivation for RSS Feed for Presence State 1. Introduction to Web based Mash-ups and RSS This section may be useful to readers not familiar with Web base Mash-ups in general. Readers well versed with this may directly skip to the next section. Clarification: For the scope of this document the term 'Web' refers to an environment where the 'User Agent' is typically a Browser (such as Firefox, Opera, IE) and the 'Server' is any entity that is accessible on the Internet that can communicate with the User Agent using standards such as URIs, HTTP, HTML, XML and similar. The fundamental concept behind a 'Mash-up' is to be able to create a set of primitives and make it available on the Web in a way that those primitives could be used by any third party developer to extend and build upon the provided functionality. In concept, this is similar to creating a set of 'C (or any other programming language)- based libraries' and offering APIs on top of those libraries to others to create new functionality, but has significant differences: o A 'Web' based Mash-up re-uses well known protocols for accessing sources (example HTTP, REST) o A 'Web' based Mash-up re-uses well known formats for accessing data contained within sources (example JSON [8], XML [6], RSS [7]) o A 'Web' based Mash-up may have multiple hosting environments. In other words, if provider 'B' were build a new application on top of a service provided by 'A', B would only access content from A using well known Web Standards and would not need to host A's content in its own domain. Similarly, A does not need to access any more data in B's domain beyond what is needed to make the service work. o A 'Web' based Mash-up leverages the vast content that is already accessible across the Internet in a well defined manner and does not require duplication or local availability of data in different domains o As a derivative difference, a 'Web' bashed Mash-up is therefore accessible by any common browser and does not need special libraries or downloads beyond what the browser already supports. As an example of how services can be created rapidly using the Web Model: Roychowdhury Expires December 1, 2007 [Page 4] Internet-Draft Motivation for RSS Feed for Presence State o Consider an example, where a subscriber using a 'triple play' Service Provider (one that offers Voice, TV and Data over a single IP pipe, such as Verizon FiOS and others) is listening to a radio stream of 'Comfortably Numb' by 'Pink Floyd'. The provider wants to be able to tap into this by showing a list of locations where Pink Floyd may be performing in the coming months as well as show a preview video of the song he is listening to (in the hope that the subscriber might purchase one of these offerings). Such as combined solution can be easily provided leveraging the Web and the Internet: o Let us assume the radio service itself publishes the currently playing information (such as Artist, Title, etc.) o The provider can fetch the name artist and provide it as an input to common ticketing sites (like TicketMaster) which in turn returns the list of locations where this group is performing o At the same time, the provider can fetch the name of the radio song & title and feed it to a video service, like YouTube which generates a response feed with the URI of the preview video which is then displayed as a small window on the subscriber's display o The provider also taps into e-commerce sites like Amazon (or another partner site) with the same input parameters and receives a feed response on links to 'Buy it now' for the subscriber to place an order for this album The above example describes rapid creation of a combined service where the provider is re-using already existing data sources & technologies in a standard way to create this value addition. Creating such services is not just theory today. Consider for example, solutions like Yahoo Pipes [9]and Google Mash-up Editor [10] that provide such environments for regular users to create such combinations. As another example, consider an existing service, like HousingMaps.com which is a 'Mash-up' reusing Google Maps APIs to provide real-estate pricing based on location to users. Roychowdhury Expires December 1, 2007 [Page 5] Internet-Draft Motivation for RSS Feed for Presence State Note that the above is possible only if the output of each component is understood by other components. RSS or "Really Simple Syndication" [7] is a dialect of XML and is a popularly supported content syndication format and is therefore a common 'data format' that is often used to exchange information between different modules hosted by different providers. RSS provides easy to understand "tags" under which information is classified and can be extracted by standard XML parsers (which are a part of all Browsers). In addition, RSS allows for easy implementation of 'Filters' as services are combined (For example, 'Show me all movies from Youtube that do not have rating=Mature' may translate to parsing the RSS feed and deleting feed entries that have a tag of Mature) In each of these examples, the following important characteristics emerge: o Adopting a 'Web based' approach to create incremental services (referred to as 'Mash-Ups') significantly reduces service creation time (since the interfaces are well known and do not require a steep learning curve) o Adopting a 'Web based Mash-up' approach significantly reduces the infrastructure and technology requirement from a single provider (example, HousingMaps does not need to replicate the mapping technology which it sources from Google, Google does not need to replicate detailed map information which it sources from TeleAtlas) However, the important limiting characteristic to this model are: o The effectiveness of what can be achieved is directly related to the nature of data and access each domain is willing to expose to build upon. o The RSS based model of constructing combined services is a simple chain of output of one module serving as an input to another and does not provide complex flow control logic This therefore leads us to why we believe exposing certain SIP related data in such a standard format would benefit more value added service creation. Roychowdhury Expires December 1, 2007 [Page 6] Internet-Draft Motivation for RSS Feed for Presence State 2. Use Cases for Presence State represented as RSS. In all the use-cases below, publishing the information in RSS format enable third party developers to create new combined services without requiring any other specialized tools or protocols beyond free Mash- up editors that already exist today (example: Yahoo-Pipes, Google Mash-up Editor) o Use-Case-1: Consider a user Bob, who subscribes to an ad-supported live traffic service that provides him with up to date traffic information for one of his selected highway routes on I-270N. This is provided to him in return as an RSS feed for him to see a live traffic map update. However, it would be useful if the traffic service could ask for Bob's current Presence state and provide information accordingly. For example, if Bob's element shows a value of 'in-transit', then the provider can choose to filter out or reduce the sidebar ads so that it is simpler for Bob to convert the RSS Feed to speech using free tools available such as [11] o Use-Case-2: Consider another example where user Alice is in a community chat room, and has her mood (via the element) set to with a child element set to "would love a burger". The Chat provider can create a sidebar customized service by putting the following elements together: o Get the Presence feed from Alice's UA and parse the hungry element o Assuming Alice's presence feed also publishes location, retrieve current location o Pass on the note text and the location to Yahoo Local Maps and obtain a list of burger places and display that feed on the sidebar o (One could continue to combine more attributes to make this more specific) Roychowdhury Expires December 1, 2007 [Page 7] Internet-Draft Motivation for RSS Feed for Presence State o Use-Case-3: 'Trackit' is a presence publishing system that allows different Presentities to update their presence state periodically. Presentities that publish their state also specify access rules which govern who can read this presence data (example "all", "none", or explicit list of identities, domains etc.). Bob is a paid subscriber to 'Trackit' and decides to offer a 'Map & Track' service on top of Trackit and GoogleMaps like so: o users, who publish their state in Trackit create ad-hoc groups of friends, co-workers and publish an additional attribute in their presence information, such as Stanford2006AlumniMeet o Members of the group called Standford2006AlumniMeet can now log into a specific webpage provided by Bob which provides a movable map with 'presence dots' of where each user currently is and what they are doing (subject to what each presentity agrees to publish). o Bob creates the above page by accessing the RSS feed provided by Trackit for the group members, extracts the location and activities elements, passes the location information to googlemaps and then overlays the map with placepoint information showing their presence status. o Now, if the users are all supposed to meet at 6PM for the alumni meeting at Palo Alto, the co-ordinator knows where everyone is, how long they would take to arrive and other information. 3. Security Considerations Security conditions that apply to publishing of Presence Information as specified in [2][3][4] also apply here. In addition, a Web based Mash-up model involves interaction of data from multiple, disconnected domains. By only enabling HTTP GET to retrieve an RSS feed across domains reduces the potential attacks, but it is critical for the domains participating in a mash-up service to secure their data appropriately. 4. IANA Considerations None identified Roychowdhury Expires December 1, 2007 [Page 8] Internet-Draft Motivation for RSS Feed for Presence State 5. Conclusions & Future work This draft describes the motivation for providing Presence related data as an RSS feed. The primary advantage that has been described is that this allows third party developers to rapidly & incrementally create new services using standard web-tools. As further work, it may be possible that non-presence related SIP data is also identified as potentially useful in created services chained by RSS feeds. A possible next step is to work on a specification that describes an RSS format for Presence tags that could be adhered to by Presentities wanting to publish such attributes. 6. Acknowledgments Roychowdhury Expires December 1, 2007 [Page 9] Internet-Draft Motivation for RSS Feed for Presence State 7. References 7.1. Normative [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006 [3] Schulzrinne, H., "CIPID:Contact information for the Presence Information Data Format", RFC 4482, July 2006 [4] Schulzrinne,H., Gurbani,V., Kyzviat,P., Rosenberg,J. "RPID:Rich Presence Extensions to the Presence Information Data Format (PIDF)", RFC 4480, July 2006 [5] Fielding,R., Taylor,R. "Principled design of the modern Web architecture", ACM Transactions on Internet Technology (TOIT), Volume 2, Issue 2 (May 2002), ACM Press, ISSN:1533-5399 [6] Bray,T., Paoli,J., Sperberg-McQueen,C.M., Maler,E., Yergeau,F., "Extensible Markup Language (XML) 1.0 (Fourth Edition)", September 2006 7.2. Informative [7] RSS Advisory Board, "RSS 2.0 Specification", http://www.rssboard.org/rss-specification [8] Javascript Object Notation (JSON), http://www.json.org/ [9] Yahoo Pipes, http://pipes.yahoo.com [10] Google Mash-up Editor, http://code.google.com/gme/index.html [11] RSS to Speech Gadget, http://desktop.google.com/plugins/i/rsstospeech.html Roychowdhury Expires December 1, 2007 [Page 10] Internet-Draft Motivation for RSS Feed for Presence State Author's Addresses Arjun Roychowdhury Hughes Systique Corp. 15245 Shady Grove Rd, Suite 330 Rockville MD 20850 USA Email: arjun@hsc.com 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, 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. Roychowdhury Expires December 1, 2007 [Page 11] Internet-Draft Motivation for RSS Feed for Presence State 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Roychowdhury Expires December 1, 2007 [Page 12]