One document matched: draft-polk-geopriv-pidf-lo-timezone-element-00.txt
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
<timestamp> 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] <status> element with a complex
element called <geopriv>. PIDF-LO also created two major
subselements which are encapsulated within <geopriv>: one for
location information and one for usage rules. This document does
not affect the usage rules subelement. The <location-info> 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
<location-info> 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 <gp:tzOffSet reference="GMT">
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:
<gp:tzOffset reference="GMT">+5</gp:tzOffset>
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]
| PAFTECH AB 2003-2026 | 2026-04-23 05:34:24 |