Geopriv WG James Polk Internet-Draft Jonathan Rosenberg Expires: January 7, 2009 Cisco Systems Intended Status: Standards Track (PS) July 7, 2008 Updates: RFC 4119 (if published as an RFC) An Extension to the Presence Information Data Format - Location Object (PIDF-LO) for the Timezone of a Presentity draft-polk-geopriv-pidf-lo-timezone-element-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 7, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract The Presence Information Data Format - Location Object (PIDF-LO) lacks an indication for the timezone offset of a particular presentity is in. This document extends the PIDF-LO for including such an XML element. Polk & Rosenberg Expires January 7, 2008 [Page 1] Internet-Draft PIDF-LO Timezone Element July 2008 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 [RFC2119]. 1. Introduction Presence is defined as the ability, willingness and desire to communication across differing devices, media types and services. Presence documents contain information about the presentity that allows a watcher to make a determination about how, if and when to communicate with it. One valuable piece of information that watchers can use to make a communications decision is the local time of a presentity. The local time is invaluable for giving the watcher a hint about whether the presentity is sleeping, working, commuting, or doing some other activity that typically takes place at a particular time in the local time of the presentity. For example, user Joe is watching user Alice, and Joe is in San Francisco. Alice is typically in San Francisco also, but is visiting Europe this week. In the middle of his work day, Joe wants to contact Alice. He sees that her local time is 2am. This gives Joe a strong hint that Alice is probably sleeping, and he probably should not ring her cell phone (which is likely to wake her up). The local time for a presentity is directly a function of their timezone. Timezones are themselves intertwined with geolocation, since a timezone is nothing more than a complex polygon overlaid on top of the globe which defines a region in which the local time is invariant. One solution is for the watcher to determine, on their own, the local time as a function of the geolocation of the presentity. In our example above, Joe can know, using [RFC4119], that Alice is in "London, England". Joe, as a user, knows that London is 9 hours ahead of California, and so he knows not to place the call. In this solution, there is no need to separately convey the timezone of Alice. The problem with that approach is that it relies on a human translation operation that takes the geolocation of a presentity, and determines the timezone offset of that location from the location of the watcher. For savvy users with a good grasp of world geography, users can do this translation function with coarse accuracy (plus or minus a few hours) for major world cities. However, users will not know the timezone for many, many cities in the world. Furthermore, they are unlikely to know it accurately. For example, what would Joe do if Alice's location was "Andorra la Vella, Andorra"? Odds are good that Joe has no idea that Andorra is in Europe and is UTC+1. Polk & Rosenberg Expires January 7, 2008 [Page 2] Internet-Draft PIDF-LO Timezone Element July 2008 Rather than make users manually figure out local time from civic or geodesic coordinates, it would be valuable for presence documents to contain the timezone of the presentity. This would allow a watcher to compare the timezone of the presentity with their own timezone and local time, and then easily render the exact local time of the presentity. Since timezone is effectively another form of geolocation, independent of either coordinate or civic location formats, this document proposes a new top-level field in PIDF-LO which contains the timezone, as an offset from GMT. This new format can be carried in the same message as either (or both) existing location formats. 2. Timestamp verses Timezone Elements in PIDF-LO Greenwich Mean Time (or GMT or Zulu time), which the existing element is defined as, lacks a timezone offset Indication [wiki-time]. The above scenarios cannot be addressed using GMT alone. 3. The PIDF-LO Timezone Location Format (Element) RFC 4119 extended the PIDF [RFC3863] element with a complex element called . PIDF-LO also created two major subselements which are encapsulated within : one for location information and one for usage rules. This document does not affect the usage rules subelement. The element MUST contain one or more directives indicating the XML schema(s) that are used for geographic location formats, according to RFC 4119. This document creates a new, single child element under the element that is considered its own location format, effectively lateral to geo-coordinate location and civic location already established within RFC 4119. This extension to PIDF-LO creates the element. This is a simple individual element to solve the problem of understanding which timezone a presentity is in. It is merely the offset from GMT time, of where the presentity is currently. Here is the format of the element: +5 The tzOffSet element indicates the reference time standard used by including the ' reference="" ' identifier. Here we mandate 'Greenwich Mean Time', or "GMT", MUST be understood by all entities who support his specification. Other references MAY be defined in future standards efforts. The first character within the element value is a '+' (plus sign) or a '-' (minus sign) to indicate the timezone offset in relation to Polk & Rosenberg Expires January 7, 2008 [Page 3] Internet-Draft PIDF-LO Timezone Element July 2008 Greenwich, England. The offset MUST be positive for those timezones east of Greenwich, England, and negative to those west of Greenwich. The next character(s) are the integer of offset. For example, if GMT is currently 22:07:13 (Greenwich, England time) Those on the East Coast of the US 18:07:13 (or 6:07pm EDT) which is GMT-4. Those in the Central Europe Timezone are GMT+1, meaning it is 23:07:13 there (in this same example). Once the presentity determines it has changed timezones, it MUST refresh its state information with the presence server. A full understanding of time on planet earth is a good idea if you want to understand timezones other than in typical hourly increments. Some timezones have 30 minute increments, while other timezones have 15 minute increments to timezones. This document gives no history or guidance into this. 4. Security considerations This document creates no new security considerations beyond what is already in RFC 4119. 5. IANA considerations TBD 6. Acknowledgments We would like to thank Marc Linsner for help comments made during the formation of this document. 7. References 7.1. Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997 Polk & Rosenberg Expires January 7, 2008 [Page 4] Internet-Draft PIDF-LO Timezone Element July 2008 [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005 [RFC3863] H. Sugano, S. Fujimoto, G. Klyne, A. Bateman, W. Carr, J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004 [wiki-time] http://en.wikipedia.org/wiki/Greenwich_Mean_Time 7.2. Informative References [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, "Geopriv Requirements", RFC 3693, February 2004 Authors' Addresses James Polk Cisco Systems 3913 Treemont Circle Colleyville, Texas, USA +1.817.271.3552 mailto: jmpolk@cisco.com Jonathan Rosenberg Cisco Systems, Inc. Edison, NJ USA Email: jdrosen@cisco.com URI: http://www.jdrosen.net Full Copyright Statement Copyright (C) The IETF Trust (2008). 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 Polk & Rosenberg Expires January 7, 2008 [Page 5] Internet-Draft PIDF-LO Timezone Element July 2008 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 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 provided by the IETF Administrative Support Activity (IASA). Polk & Rosenberg Expires January 7, 2008 [Page 6]