< draft-ietf-simple-future-04.txt		draft-ietf-simple-future-05.txt >
	SIMPLE H. Schulzrinne		SIMPLE H. Schulzrinne
	Internet-Draft Columbia U.		Internet-Draft Columbia U.
	Expires: December 28, 2005 June 26, 2005		Expires: June 23, 2006 December 20, 2005
	Timed Presence Extensions to the Presence Information Data Format (PIDF)		Timed Presence Extensions to the Presence Information Data Format (PIDF)
	to Indicate Status Information for Past and Future Time Intervals		to Indicate Status Information for Past and Future Time Intervals
	draft-ietf-simple-future-04		draft-ietf-simple-future-05
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		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		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.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 34 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on December 28, 2005.		This Internet-Draft will expire on June 23, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2005).
	Abstract		Abstract
	The Presence Information Data Format (PIDF) defines a basic XML		The Presence Information Data Format (PIDF) defines a basic XML
	format for presenting presence information for a presentity. This		format for presenting presence information for a presentity. This
	document extends PIDF, adding a timed status extension (<timed-		document extends PIDF, adding a timed status extension (<timed-
	skipping to change at page 2, line 22 ¶		skipping to change at page 2, line 22 ¶
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	6.1 URN Sub-Namespace Registration for		6.1 URN Sub-Namespace Registration for
	'urn:ietf:params:xml:ns:pidf:timed-status' . . . . . . . . 8		'urn:ietf:params:xml:ns:pidf:timed-status' . . . . . . . . 8
	6.2 Schema Registration for Schema		6.2 Schema Registration for Schema
	urn:ietf:params:xml:ns:pidf:timed-status' . . . . . . . . 8		urn:ietf:params:xml:ns:pidf:timed-status' . . . . . . . . 8
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 10		7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	8.1 Normative References . . . . . . . . . . . . . . . . . . . 11		8.1 Normative References . . . . . . . . . . . . . . . . . . . 11
	8.2 Informative References . . . . . . . . . . . . . . . . . . 11		8.2 Informative References . . . . . . . . . . . . . . . . . . 11
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11		Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11
	A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12		A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13
	B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13		B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
	Intellectual Property and Copyright Statements . . . . . . . . 14		Intellectual Property and Copyright Statements . . . . . . . . 15
	1. Introduction		1. Introduction
	Traditionally, presence information, e.g., represented as PIDF [3]		Traditionally, presence information, e.g., represented as PIDF [3]
	and RPID [6], describes the current state of the presentity.		(Presence Information Data Format) and augmented by RPID [7] (Rich
	However, a watcher can better plan communications if it knows about		Presence Information Data format), describes the current state of the
	the presentity's future plans. For example, if a watcher knows that		presentity. However, a watcher can better plan communications if it
	the presentity is about to travel, it might place a phone call		knows about the presentity's future plans. For example, if a watcher
	earlier.		knows that the presentity is about to travel, it might place a phone
			call earlier.
			In this document, we use terms defined in RFC 2778 [4]. In
			particular, a "presentity", abbreviating presence entity, provides
			presence information to a presence service. It is typically a
			uniquely-identified person.
	RPID already allows a presentity to indicate the period when a		RPID already allows a presentity to indicate the period when a
	particular aspect of its presence is valid. However, the <status>		particular aspect of its presence is valid. However, the <status>
	element in the PIDF <tuple> does not have this facility, so that it		element in the PIDF <tuple> does not have this facility, so that it
	is not possible to indicate that a presentity will be OPEN or CLOSED		is not possible to indicate that a presentity will be OPEN or CLOSED
	in the future, for example.		in the future, for example.
	It is also occasionally useful to represent past information since it		It is also occasionally useful to represent past information since it
	may be the only known presence information; it may give watchers an		may be the only known presence information; it may give watchers an
	indication of the current status. For example, indicating that the		indication of the current status. For example, indicating that the
	presentity was at an off-site meeting that ended an hour ago		presentity was at an off-site meeting that ended an hour ago
	indicates that the presentity is likely in transit at the current		indicates that the presentity is likely in transit at the current
	time.		time.
	It is unfortunately not possible to simply add time range attributes		It is unfortunately not possible to simply add time range attributes
	to the PIDF <status> element, as PIDF parsers without this capability		to the PIDF <status> element, as PIDF parsers without this capability
	would ignore thes attributes and thus not be able to distinguish		would ignore these attributes and thus not be able to distinguish
	current from future presence status information.		current from future presence status information.
	This document defines the <timed-status> element that describes the		This document defines the <timed-status> element that describes the
	status of a presentity that is either no longer valid or covers some		status of a presentity that is either no longer valid or covers some
	future time period.		future time period.
	2. Terminology and Conventions		2. Terminology and Conventions
	The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT,		The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT,
	RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted		RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted
	skipping to change at page 5, line 37 ¶		skipping to change at page 5, line 37 ¶
	future.		future.
	During composition, a presence agent (PA) may encounter a stored		During composition, a presence agent (PA) may encounter a stored
	<timed-status> elements that covers the present time. The PA MAY		<timed-status> elements that covers the present time. The PA MAY
	either discard those elements or MAY convert it to a regular <status>		either discard those elements or MAY convert it to a regular <status>
	element if it considers that information more credible.		element if it considers that information more credible.
	The <timed-status> element may contain the <basic> and <note>		The <timed-status> element may contain the <basic> and <note>
	elements, as well as any other element that is appropriate as a PIDF		elements, as well as any other element that is appropriate as a PIDF
	<status> extension and that has a limited validity period. Examples		<status> extension and that has a limited validity period. Examples
	include the PIDF-LO [5] extensions for location objects.		include the PIDF-LO [6] extensions for location objects.
	This extension chose absolute rather than relative times, since		This extension chose absolute rather than relative times, since
	relative times would be too hard to keep properly updated when		relative times would be too hard to keep properly updated when
	spacing notifications, for example. Implementations SHOULD ascertain		spacing notifications, for example. Originators of presence
	whether the time values in the <timed-status> elements are plausible,		information MUST generate time values in the <timed-status> elements
	for example, by checking whether the time stamp in a notification		that are fully in the past or future relative to local real
	protocol message corresponds to local time and by making sure that		(wallclock) time and the time information contained in the optional
	they are fully in the past or future, both relative to real time and		PIDF <timestamp> element.
	the time contained in the optional PIDF <timestamp> element.
	4. Example		4. Example
	An example combining PIDF and timed-status is shown below:		An example combining PIDF and timed-status is shown below:
	<presence xmlns="urn:ietf:params:xml:ns:pidf"		<presence xmlns="urn:ietf:params:xml:ns:pidf"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:ts="urn:ietf:params:xml:ns:pidf:timed-status"		xmlns:ts="urn:ietf:params:xml:ns:pidf:timed-status"
	xsi:schemaLocation="urn:ietf:params:xml:ns:pidf pidf.xsd		xsi:schemaLocation="urn:ietf:params:xml:ns:pidf pidf.xsd
	urn:ietf:params:xml:ns:pidf:data-model data-model.xsd		urn:ietf:params:xml:ns:pidf:data-model data-model.xsd
	skipping to change at page 10, line 7 ¶		skipping to change at page 10, line 7 ¶
	urn:ietf:params:xml:ns:pidf:timed-status'		urn:ietf:params:xml:ns:pidf:timed-status'
	URI: please assign		URI: please assign
	Registrant Contact: IESG		Registrant Contact: IESG
	XML: See Section 5		XML: See Section 5
	7. Security Considerations		7. Security Considerations
	The security issues are similar to those for RPID [6].		The security issues are similar to those for RPID [7].
	8. References		8. References
	8.1 Normative References		8.1 Normative References
	[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	[2] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[2] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	January 2004.		January 2004.
	[3] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and		[3] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and
	J. Peterson, "Presence Information Data Format (PIDF)",		J. Peterson, "Presence Information Data Format (PIDF)",
	RFC 3863, August 2004.		RFC 3863, August 2004.
	8.2 Informative References		8.2 Informative References
	[4] Rosenberg, J., "A Data Model for Presence",		[4] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and
	draft-ietf-simple-presence-data-model-02 (work in progress),		Instant Messaging", RFC 2778, February 2000.
	February 2005.
	[5] Peterson, J., "A Presence-based GEOPRIV Location Object Format",		[5] Rosenberg, J., "A Data Model for Presence",
			draft-ietf-simple-presence-data-model-06 (work in progress),
			October 2005.
			[6] Peterson, J., "A Presence-based GEOPRIV Location Object Format",
	draft-ietf-geopriv-pidf-lo-03 (work in progress),		draft-ietf-geopriv-pidf-lo-03 (work in progress),
	September 2004.		September 2004.
	[6] Schulzrinne, H., "RPID: Rich Presence Extensions to the Presence		[7] Schulzrinne, H., "RPID: Rich Presence Extensions to the Presence
	Information Data Format (PIDF)", draft-ietf-simple-rpid-06		Information Data Format (PIDF)", draft-ietf-simple-rpid-09
	(work in progress), June 2005.		(work in progress), September 2005.
	[7] Schulzrinne, H., "CIPID: Contact Information in Presence		[8] Schulzrinne, H., "CIPID: Contact Information in Presence
	Information Data Format", draft-ietf-simple-cipid-04 (work in		Information Data Format", draft-ietf-simple-cipid-06 (work in
	progress), June 2005.		progress), July 2005.
	Author's Address		Author's Address
	Henning Schulzrinne		Henning Schulzrinne
	Columbia University		Columbia University
	Department of Computer Science		Department of Computer Science
	450 Computer Science Building		450 Computer Science Building
	New York, NY 10027		New York, NY 10027
	US		US
	skipping to change at page 13, line 8 ¶		skipping to change at page 14, line 8 ¶
	Jonathan Rosenberg		Jonathan Rosenberg
	dynamicsoft		dynamicsoft
	600 Lanidex Plaza		600 Lanidex Plaza
	Parsippany, NJ 07054-2711		Parsippany, NJ 07054-2711
	USA		USA
	Email: jdrosen@dynamicsoft.com		Email: jdrosen@dynamicsoft.com
	Appendix B. Acknowledgments		Appendix B. Acknowledgments
	This document is based on the discussions within the IETF SIMPLE		This document is based on the discussions within the IETF SIMPLE
	working group. Mary Barnes, Miguel Garcia, Vijay Gurbani, Hisham		working group. Mary Barnes, Avri Doria, Miguel Garcia, Vijay
	Khartabil, Paul Kyzivat, Mikko Lonnfors, Yannis Pavlidis and Jon		Gurbani, Hisham Khartabil, Paul Kyzivat, Mikko Lonnfors, Yannis
	Peterson provided helpful comments.		Pavlidis and Jon Peterson provided helpful comments.
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		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		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
End of changes. 14 change blocks.
	33 lines changed or deleted		41 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/