< draft-ietf-geopriv-pres-01.txt		draft-ietf-geopriv-pres-02.txt >
	GEOPRIV WG J. Peterson		GEOPRIV WG J. Peterson
	Internet-Draft NeuStar		Internet-Draft NeuStar
	Expires: January 13, 2005 July 15, 2004		Expires: March 9, 2005 September 8, 2004
	A Presence Architecture for the Distribution of Geopriv Location		A Presence Architecture for the Distribution of GEOPRIV Location
	Objects		Objects
	draft-ietf-geopriv-pres-01		draft-ietf-geopriv-pres-02
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		By submitting this Internet-Draft, I certify that any applicable
	patent or other IPR claims of which I am aware have been disclosed,		patent or other IPR claims of which I am aware have been disclosed,
	and any of which I become aware will be disclosed, in accordance with		and any of which I become aware will be disclosed, in accordance with
	RFC 3668.		RFC 3668.
	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 33 ¶		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 January 13, 2005.		This Internet-Draft will expire on March 9, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	Abstract		Abstract
	Geopriv defines the concept of a 'using protocol', a protocol that		GEOPRIV defines the concept of a 'using protocol', a protocol that
	carries Geopriv location objects. Geopriv also defines various		carries GEOPRIV location objects. GEOPRIV also defines various
	scenarios for the distribution of location objects that require the		scenarios for the distribution of location objects that require the
	concept of subscriptions and asynchronous notifications. This		concept of subscriptions and asynchronous notifications. This
	document examines some existing IETF work on the concept of presence,		document examines some existing IETF work on the concept of presence,
	shows how presence architectures map onto Geopriv architectures, and		shows how presence architectures map onto GEOPRIV architectures, and
	moreover demonstrates that tools already developed for presence could		moreover demonstrates that tools already developed for presence could
	be reused to simplify the standardization and implementation of		be reused to simplify the standardization and implementation of
	Geopriv.		GEOPRIV.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Framework Analysis . . . . . . . . . . . . . . . . . . . . . . 3		2. Framework Analysis . . . . . . . . . . . . . . . . . . . . . . 3
	3. Presence Architecture for Geopriv . . . . . . . . . . . . . . 4		3. Presence Architecture for GEOPRIV . . . . . . . . . . . . . . 4
	4. Geopriv Extensions to PIDF . . . . . . . . . . . . . . . . . . 6		4. GEOPRIV Extensions to PIDF . . . . . . . . . . . . . . . . . . 6
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 6		5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	7. Informative References . . . . . . . . . . . . . . . . . . . . 6
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7		Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7
	Intellectual Property and Copyright Statements . . . . . . . . 8		7. Informative References . . . . . . . . . . . . . . . . . . . . 6
			A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
			Intellectual Property and Copyright Statements . . . . . . . . 9
	1. Introduction		1. Introduction
	Geopriv is a standard for the transmission of location information		GEOPRIV is a standard for the transmission of location information
	over the Internet. Location information is a description of a		and privacy policies over the Internet. Location information is a
	particular spatial location, which may be represented as coordinates		description of a particular spatial location, which may be
	(via longitude, latitude, and so on), or as civil addresses (such as		represented as coordinates (via longitude, latitude, and so on), or
	postal addresses), or in other ways. Geopriv focuses on the privacy		as civil addresses (such as postal addresses), or in other ways.
	and security issues, both from a technology perspective and a policy		GEOPRIV focuses on the privacy and security issues, both from a
	perspective, of sharing location information over the Internet; it		technology perspective and a policy perspective, of sharing location
	essentially defines a secure container class capable of carrying both		information over the Internet; it essentially defines a secure
	location information and policy data governing the distribution of		container class capable of carrying both location information and
	this information. Geopriv also defines the concept of a 'using		policy data governing the distribution of this information. GEOPRIV
	protocol', a protocol that carries the Geopriv location object.		also defines the concept of a 'using protocol', a protocol that
			carries the GEOPRIV location object.
	Presence is a service defined in RFC2778 [2] that allows users of a		Presence is a service defined in RFC2778 [2] that allows users of a
	communications service to monitor one another's availability and		communications service to monitor one another's availability and
	disposition in order to make decisions about communicating. Presence		disposition in order to make decisions about communicating. Presence
	information is highly dynamic, and generally characterizes whether a		information is highly dynamic, and generally characterizes whether a
	not a user is online or offline, busy or idle, away from		user is online or offline, busy or idle, away from communications
	communications devices or nearby, and the like.		devices or nearby, and the like.
	This document shows the applicability of presence to Geopriv, and		This document shows the applicability of presence to GEOPRIV, and
	argues that a presence protocol might be a suitable using protocol		shows that a presence protocol could be a suitable using protocol for
	for Geopriv. This document is not intended to demonstrate that		GEOPRIV. This document is not intended to demonstrate that presence
	presence is the only method by which Geopriv location objects might		is the only method by which GEOPRIV location objects might be
	be distributed. However, there are numerous applications of Geopriv		distributed. However, there are numerous applications of GEOPRIV
	that depend on the fundamental subscription/notification architecture		that depend on the fundamental subscription/notification architecture
	that also underlies presence.		that also underlies presence.
	2. Framework Analysis		2. Framework Analysis
	The Geopriv framework [1] defines four primary network entities: a		The GEOPRIV framework [1] defines four primary network entities: a
	Location Generator, a Location Server, a Location Recipient, and a		Location Generator, a Location Server, a Location Recipient, and a
	Rule Holder. Three interfaces between these entities are defined,		Rule Holder. Three interfaces between these entities are defined,
	including a publication interface and a notification interface.		including a publication interface and a notification interface.
	Geopriv specifies that a 'using protocol' is employed to transport		GEOPRIV specifies that a 'using protocol' is employed to transport
	location objects from one place to another. If the publication		location objects from one place to another. If the publication
	interface and notification interface are network connections, then a		interface and notification interface are network connections, then a
	using protocol would be responsible for the transmission of the		using protocol would be responsible for the transmission of the
	location object. Location Recipients may request that a Location		location object. Location Recipients may request that a Location
	Server provide them with Geopriv location information concerning a		Server provide them with GEOPRIV location information concerning a
	particular Target. The Location Generator publishes Location		particular Target. The Location Generator publishes Location
	Information to a Location Server, which, in coordination with		Information to a Location Server, which, in coordination with
	policies set by the Rule Maker, distributes the location information		policies set by the Rule Maker, distributes the location information
	to Location Recipients as necessary.		to Location Recipients as necessary.
	The Geopriv requirements document shows three scenarios for the use		The GEOPRIV requirements document shows three scenarios for the use
	of the Geopriv protocol. In some of these scenarios (such as the		of the GEOPRIV protocol. In some of these scenarios (such as the
	third), a Location Recipient sends some kind of message to the		third), a Location Recipient sends some kind of message to the
	Location Server to request the periodic transmission of location		Location Server to request the periodic transmission of location
	information. The location of a Geopriv Target is likely to vary over		information. The location of a GEOPRIV Target is likely to vary over
	time (if the Target is a person, or something similarly mobile) and		time (if the Target is a person, or something similarly mobile) and
	consequently the concept of a persistent subscription to the location		consequently the concept of a persistent subscription to the location
	of a Target resulting in periodic notification is valuable to		of a Target resulting in periodic notification is valuable to
	Geopriv. In other scenarios, a Location Recipient may request a		GEOPRIV. In other scenarios, a Location Recipient may request a
	one-time notification of the geographical location of the Target.		one-time notification of the geographical location of the Target.
	Geopriv places few requirements on using protocols. However, it is		GEOPRIV places few requirements on using protocols. However, it is
	clear from the description above that there must be some mechanism to		clear from the description above that there must be some mechanism to
	allow Location Recipients to establish a persistent subscription in		allow Location Recipients to establish a persistent subscription in
	order to receive regular notification of the geographical location of		order to receive regular notification of the geographical location of
	a Target as their location changes over time. There must also be a		a Target as their location changes over time. There must also be a
	way for Location Generators to publish location information to a		way for Location Generators to publish location information to a
	Location Server that applies further policies for distribution.		Location Server that applies further policies for distribution.
	This document adopts a model in which the using protocol is		This document adopts a model in which the using protocol is
	responsible for requesting subscriptions, handling publications, and		responsible for requesting subscriptions, handling publications, and
	sending notifications. There are other models for Geopriv in which		sending notifications. There are other models for GEOPRIV in which
	such operations might be built into location objects themselves.		such operations might be built into location objects themselves.
	However, there is a significant amount of pre-existing work in the		However, there is a significant amount of pre-existing work in the
	IETF related to managing publications, subscriptions and		IETF related to managing publications, subscriptions and
	notifications for data sets that vary over time. In fact, these		notifications for data sets that vary over time. In fact, these
	concepts all correspond exactly to architectures for presence that		concepts all correspond exactly to architectures for presence that
	have been developed in support of real-time communications		have been developed in support of real-time communications
	applications such as instant messaging, voice and video sessions.		applications such as instant messaging, voice and video sessions.
	Note that there are some Geopriv scenarios in which the Location		Note that there are some GEOPRIV scenarios in which the Location
	Recipient does not actively request the location of a Target, but		Recipient does not actively request the location of a Target, but
	rather it receives an unsolicited notification of Target's location.		rather it receives an unsolicited notification of Target's location.
	This document focuses on the use of presence only for those scenarios		This document focuses on the use of presence only for those scenarios
	in which the Location Recipient actively solicits location		in which the Location Recipient actively solicits location
	information. It is however possible that many of these base		information. It is however possible that many of these base
	operations of the subscription/notification framework of presence		operations of the subscription/notification framework of presence
	could be reused in for cases in which the Location Recipient is		could be reused in for cases in which the Location Recipient is
	passive.		passive.
	3. Presence Architecture for Geopriv		3. Presence Architecture for GEOPRIV
	The Common Profile for Presence [4] (CPP) defines a set of operations		The Common Profile for Presence [4] (CPP) defines a set of operations
	for delivery of presence information. These primarily consist of		for delivery of presence information. These primarily consist of
	subscription operations and notification operations. A subscription		subscription operations and notification operations. A subscription
	creates a persistent connection between a 'watcher' (which		creates a persistent connection between a 'watcher' (which
	corresponds to the Location Recipient of Geopriv) and a 'presentity'		corresponds to the Location Recipient of GEOPRIV) and a 'presentity'
	(which corresponds roughly to the Location Server). When a watcher		(which corresponds roughly to the GEOPRIV target). When a watcher
	subscribes to a presentity, a persistent connection is created;		subscribes to a presentity, a persistent connection is created;
	notifications of presence information will henceforth be sent to the		notifications of presence information will henceforth be sent to the
	watcher as the presence information changes. CPP also supports		watcher as the presence information changes. CPP also supports
	unsubscriptions (terminating the persistent subscription) and fetches		unsubscriptions (terminating the persistent subscription) and fetches
	(one-time requests for presence information that result in no		(one-time requests for presence information that result in no
	persistent subscription).		persistent subscription).
	CPP provides a number of attributes of these operations that flesh		CPP provides a number of attributes of these operations that flesh
	out the presence system. There is a system for automatically		out the presence system. There is a system for automatically
	expiring subscriptions if they are not refreshed at user-defined		expiring subscriptions if they are not refreshed at user-defined
	skipping to change at page 5, line 25 ¶		skipping to change at page 5, line 26 ¶
	and a URI scheme ("pres:") is defined to identify watchers and		and a URI scheme ("pres:") is defined to identify watchers and
	presentities.		presentities.
	The IETF IMPP WG has also defined an XML data format for presence		The IETF IMPP WG has also defined an XML data format for presence
	information called the Presence Information Data Format [6] (PIDF).		information called the Presence Information Data Format [6] (PIDF).
	PIDF is a body carried by presence protocols that contains presence		PIDF is a body carried by presence protocols that contains presence
	information, including the current state of a presentity. PIDF is		information, including the current state of a presentity. PIDF is
	discussed in more detail in Section 4.		discussed in more detail in Section 4.
	At a high-level, then, the presence architecture seems to have		At a high-level, then, the presence architecture seems to have
	considerable applicability to the problem of delivering Geopriv		considerable applicability to the problem of delivering GEOPRIV
	information. However, the CPP framework is an abstract framework -		information. However, the CPP framework is an abstract framework -
	it doesn't actually specify a protocol, it specifies a framework and		it doesn't actually specify a protocol, it specifies a framework and
	a set of requirements to which presence protocols must conform.		a set of requirements to which presence protocols must conform.
	Also, CPP does not define any concept similar to a Location Server.		Also, CPP does not define any concept similar to a Location Server.
	However, the IETF has standardized protocols that instantiate this
	framework, such as SIMPLE [7] and XMPP [8].
	XMPP and SIMPLE both have architectural elements comparable to a		However, the IETF has standardized protocols that instantiate this
	Location Server: points where presentities register their		framework, such as SIMPLE [7] and XMPP [8]. XMPP and SIMPLE both
	availability, and where policies for distributing presence can be		have architectural elements comparable to a Location Server: points
	managed. The presence community has also defined a policy protocol		where presentities register their availability, and where policies
	and schema set called XCAP [9] through which authorization policies		for distributing presence can be managed. The presence community has
	can be provisioned in a presence server.		also defined a policy protocol and schema set called XCAP [9] through
			which authorization policies can be provisioned in a presence server.
	In summary, like Geopriv, presence requires an architecture for		In summary, like GEOPRIV, presence requires an architecture for
	publication, subscription, and notification for a mutable set of data		publication, subscription, and notification for a mutable set of data
	associated with a principal. Presence has already tackled many of		associated with a principal. Presence has already tackled many of
	the harder issues associated with subscription management, including		the harder issues associated with subscription management, including
	subscription expiration, development of identifiers for principals,		subscription expiration, development of identifiers for principals,
	and defining document formats for presence information. Rather than		and defining document formats for presence information. Rather than
	reinventing work that has been done elsewhere in the IETF, Geopriv		reinventing work that has been done elsewhere in the IETF, GEOPRIV
	should if at all possible reuse this existing work by specifying		has reused this existing work by specifying presence protocols as
	presence protocols as Geopriv using protocols. Moreover, the		GEOPRIV using protocols. Moreover, the existing foundational
	existing foundational presence tools developed in IMPP, such as PIDF,		presence tools developed in IMPP, such as PIDF, have immediate
	have immediate applicability to the efforts underway in Geopriv to		applicability to the efforts underway in GEOPRIV to develop objects
	develop objects for sharing location information.		for sharing location information.
	4. Geopriv Extensions to PIDF		4. GEOPRIV Extensions to PIDF
	As was mentioned above, the presence architecture developed in the		As was mentioned above, the presence architecture developed in the
	IETF IMPP WG has defined a format for presence information called		IETF IMPP WG has defined a format for presence information called
	PIDF. PIDF is an XML format that provides presence information about		PIDF. PIDF is an XML format that provides presence information about
	a presentity - primarily, this consists of status information, but		a presentity - primarily, this consists of status information, but
	also optionally includes contact addresses (a way of reaching the		also optionally includes contact addresses (a way of reaching the
	presentity), timestamps, and textual notes with arbitrary content.		presentity), timestamps, and textual notes with arbitrary content.
	PIDF is an extensible format. It defines an XML element for		PIDF is an extensible format. It defines an XML element for
	representing the status of a presentity (the status element), and		representing the status of a presentity (the status element), and
	gives some guidance on how this element might be extended. While the		gives some guidance on how this element might be extended. While the
	authors of PIDF viewed geographical location as a potential category		authors of PIDF viewed geographical location as a potential category
	of presence information, PIDF currently defines no way to do so.		of presence information, baseline PIDF defines no format for location
			information.
	PIDF meets the security requirements given in RFC2779 [3] (see		PIDF meets the security requirements given in RFC2779 [3] (see
	especially 5.1, 5.2 and 5.3), which parallel the security		especially 5.1, 5.2 and 5.3), which parallel the security
	requirements of the Geopriv location object given in the Geopriv		requirements of the GEOPRIV location object given in the GEOPRIV
	requirements [1]. CPP and PIDF specify mechanisms for mutual		requirements [1]. CPP and PIDF specify mechanisms for mutual
	authentication of participants in a presence exchange as well as		authentication of participants in a presence exchange as well as
	confidentiality and integrity properties for presence information.		confidentiality and integrity properties for presence information.
	So in short, many of the requirements of Geopriv objects map well		So in short, many of the requirements of GEOPRIV objects map well
	onto the capabilities of PIDF.		onto the capabilities of PIDF.
	5. Security Considerations		5. Security Considerations
	Geopriv information, like presence information, has very sensitive		GEOPRIV information, like presence information, has very sensitive
	security requirements. The requirements of RFC2779 [3], which are		security requirements. The requirements of RFC2779 [3], which are
	instantiated by CPP, PIDF and XCAP, in addition to the various		instantiated by CPP, PIDF and XCAP, in addition to the various
	derivative concrete presence protocols like XMPP and SIMPLE, map well		derivative concrete presence protocols like XMPP and SIMPLE, map well
	onto the security requirements of the Geopriv protocol, as defined in		onto the security requirements of the GEOPRIV protocol, as defined in
	the Geopriv requirements document and the Geopriv threat analysis		the GEOPRIV requirements document and the GEOPRIV threat analysis
	[10] document. Specifically, the presence security requirements call		[10] document. Specifically, the presence security requirements call
	for authentication of watchers, integrity and confidentiality		for authentication of watchers, integrity and confidentiality
	properties, and similar measures to prevent abuse of presence		properties, and similar measures to prevent abuse of presence
	information.		information.
	6. IANA Considerations		6. IANA Considerations
	This document introduces no considerations for the IANA.		This document introduces no considerations for the IANA.
	7 Informative References		7 Informative References
	[1] Cuellar, J., Morris, J., Mulligan, D., Peterson, J. and J.		[1] Cuellar, J., Morris, J., Mulligan, D., Peterson, J. and J.
	Polk, "Geopriv requirements", RFC 3693, February 2004.		Polk, "GEOPRIV requirements", RFC 3693, February 2004.
	[2] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and		[2] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and
	Instant Messaging", RFC 2778, February 2000.		Instant Messaging", RFC 2778, February 2000.
	[3] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging /		[3] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging /
	Presence Protocol Requirements", RFC 2779, February 2000.		Presence Protocol Requirements", RFC 2779, February 2000.
	[4] Peterson, J., "A Model for Presence and Instant Messaging",		[4] Peterson, J., "A Model for Presence and Instant Messaging", RFC
	draft-ietf-impp-pres-04 (work in progress), August 2003.		3859, August 2004.
	[5] Peterson, J., "Address Resolution for Instant Messaging and		[5] Peterson, J., "Address Resolution for Instant Messaging and
	Presence", draft-ietf-impp-srv-04 (work in progress), September		Presence", RFC 3861, August 2004.
	2003.
	[6] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and		[6] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and
	J. Peterson, "CPIM Presence Information Data Format",		J. Peterson, "CPIM Presence Information Data Format", RFC 3863,
	draft-ietf-impp-cpim-pidf-08 (work in progress), May 2003.		August 2004.
	[7] Rosenberg, J., "A Presence Event Package for the Session		[7] Rosenberg, J., "A Presence Event Package for the Session
	Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work		Initiation Protocol (SIP)", RFC 3856, August 2004.
	in progress), Jan 2003.
	[8] Saint-Andre, P., "Extensible Messaging and Presence Protocol		[8] Saint-Andre, P., "Extensible Messaging and Presence Protocol
	(XMPP): Instant Messaging and Presence", draft-ietf-xmpp-im-22		(XMPP): Instant Messaging and Presence", draft-ietf-xmpp-im-22
	(work in progress), April 2004.		(work in progress), April 2004.
	[9] Rosenberg, J., "The Extensible Markup Language (XML)		[9] Rosenberg, J., "The Extensible Markup Language (XML)
	Configuration Access Protocol (XCAP)",		Configuration Access Protocol (XCAP)",
	draft-ietf-simple-xcap-02 (work in progress), February 2004.		draft-ietf-simple-xcap-02 (work in progress), February 2004.
	[10] Danley, M., Morris, J., Mulligan, D. and J. Peterson, "Threat		[10] Danley, M., Morris, J., Mulligan, D. and J. Peterson, "Threat
	Analysis of the geopriv Protocol", RFC 3694, February 2004.		Analysis of the GEOPRIV Protocol", RFC 3694, February 2004.
	[11] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform		[11] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
	Resource Identifiers (URI): Generic Syntax", RFC 2396, August		Resource Identifiers (URI): Generic Syntax", RFC 2396, August
	1998.		1998.
	Author's Address		Author's Address
	Jon Peterson		Jon Peterson
	NeuStar, Inc.		NeuStar, Inc.
	1800 Sutter St		1800 Sutter St
	Suite 570		Suite 570
	Concord, CA 94520		Concord, CA 94520
	USA		USA
	Phone: +1 925/363-8720		Phone: +1 925/363-8720
	EMail: jon.peterson@neustar.biz		EMail: jon.peterson@neustar.biz
	URI: http://www.neustar.biz/		URI: http://www.neustar.biz/
			Appendix A. Acknowledgements
			Thanks to Randall Gellens, John Morris, Hannes Tschofenig, and Behcet
			Sarikaya for their 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
	found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
End of changes. 43 change blocks.
	76 lines changed or deleted		82 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/