< draft-ietf-simple-rpid-01.txt		draft-ietf-simple-rpid-02.txt >
	SIMPLE H. Schulzrinne		SIMPLE H. Schulzrinne
	Internet-Draft Columbia U.		Internet-Draft Columbia U.
	Expires: August 9, 2004 V. Gurbani		Expires: September 11, 2004 V. Gurbani
	Lucent		Lucent
	P. Kyzivat		P. Kyzivat
	Cisco		Cisco
	J. Rosenberg		J. Rosenberg
	dynamicsoft		dynamicsoft
	February 9, 2004		March 13, 2004
	RPID - Rich Presence Information Data Format		RPID: Rich Presence: Extensions to the Presence Information Data
	draft-ietf-simple-rpid-01		Format (PIDF)
			draft-ietf-simple-rpid-02
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		By submitting this Internet-Draft, I certify that any applicable
	all provisions of Section 10 of RFC2026.		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
			RFC 3667.
	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 other		Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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 http://		The list of current Internet-Drafts can be accessed at http://
	www.ietf.org/ietf/1id-abstracts.txt.		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 August 9, 2004.		This Internet-Draft will expire on September 11, 2004.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	Abstract		Abstract
	The Rich Presence Information Data Format (RPID) adds elements to the		The Rich Presence Information Data Format (RPID) adds elements to the
	Presence Information Data Format (PIDF) that provide additional		Presence Information Data Format (PIDF) that provide additional
	information about the presentity and its contacts. This information		information about the presentity and its contacts. The information
	can be translated into call routing behavior or be delivered to		is designed so that much of it can be derived automatically, e.g.,
	watchers, for example. The information is designed so that much of		from calendar files or user activity.
	it can be derived automatically, e.g., from calendar files or user
	activity.		This extension includes information about what the presentity is
			doing (the activity element), a grouping identifier for a tuple (the
			class element), the type of tuple (the contact-type element), whether
			a contact is idle (the idle element), the typle of place a presentity
			is in (the placetype element), whether the presentity is in a public
			or private space (the privacy element), the relationship of a tuple
			to another presentity (the relationship element), and the overall
			role of the presentity (the sphere element).
	Table of Contents		Table of Contents
	1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology and Conventions . . . . . . . . . . . . . . . . . 4		2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3
	3. The Meaning of "open" and "closed" . . . . . . . . . . . . . . 5		3. The Meaning of "open" and "closed" . . . . . . . . . . . . . . 3
	4. RPID Elements . . . . . . . . . . . . . . . . . . . . . . . . 6		4. RPID Elements . . . . . . . . . . . . . . . . . . . . . . . . 3
	4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6		4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4.2 Activity Element . . . . . . . . . . . . . . . . . . . . . . . 6		4.2 Activities Element . . . . . . . . . . . . . . . . . . . . . . 4
	4.3 Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7		4.3 Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4.4 Contact-Type Element . . . . . . . . . . . . . . . . . . . . . 8		4.4 Contact-Type Element . . . . . . . . . . . . . . . . . . . . . 6
	4.5 Idle Element . . . . . . . . . . . . . . . . . . . . . . . . . 8		4.5 Idle Element . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4.6 Type of Place Element . . . . . . . . . . . . . . . . . . . . 8		4.6 Type of Place Element . . . . . . . . . . . . . . . . . . . . 7
	4.7 Privacy Element . . . . . . . . . . . . . . . . . . . . . . . 9		4.7 Privacy Element . . . . . . . . . . . . . . . . . . . . . . . 8
	4.8 Relationship Element . . . . . . . . . . . . . . . . . . . . . 10		4.8 Relationship Element . . . . . . . . . . . . . . . . . . . . . 8
	4.9 Sphere Element . . . . . . . . . . . . . . . . . . . . . . . . 10		4.9 Sphere Element . . . . . . . . . . . . . . . . . . . . . . . . 8
	5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11		5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	5.1 Presentity with Activity . . . . . . . . . . . . . . . . . . . 11		5.1 Presentity with Activity . . . . . . . . . . . . . . . . . . . 9
	6. XML Schema Definitions . . . . . . . . . . . . . . . . . . . . 13		6. XML Schema Definitions . . . . . . . . . . . . . . . . . . . . 10
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		6.1 urn:ietf:params:xml:ns:pidf:rpid-tuple . . . . . . . . . . . . 11
			6.2 urn:ietf:params:xml:ns:pidf:status:rpid-status . . . . . . . . 11
			7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	7.1 URN Sub-Namespace Registration for		7.1 URN Sub-Namespace Registration for
	'urn:ietf:params:xml:ns:pidf:rpid-status' . . . . . . . . . . 16		'urn:ietf:params:xml:ns:pidf:status:rpid-status' . . . . . . . 13
	7.2 URN Sub-Namespace Registration for		7.2 URN Sub-Namespace Registration for
	'urn:ietf:params:xml:ns:pidf:rpid-tuple' . . . . . . . . . . . 17		'urn:ietf:params:xml:ns:pidf:rpid-tuple' . . . . . . . . . . . 14
	7.3 Place Type, Tuple Type, Activities, Relationships . . . . . . 17		7.3 Schema Registration for Schema
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 18		urn:ietf:params:xml:ns:pidf:rpid-tuple' . . . . . . . . . . . 15
	Normative References . . . . . . . . . . . . . . . . . . . . . 19		7.4 Schema Registration for Schema
	Informative References . . . . . . . . . . . . . . . . . . . . 20		urn:ietf:params:xml:ns:pidf:status:rpid-status' . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20		7.5 Token Registrations . . . . . . . . . . . . . . . . . . . . . 15
	A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22		8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	Intellectual Property and Copyright Statements . . . . . . . . 23		Normative References . . . . . . . . . . . . . . . . . . . . . 16
			Informative References . . . . . . . . . . . . . . . . . . . . 16
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
			A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
			Intellectual Property and Copyright Statements . . . . . . . . 19
	1. Scope		1. Scope
	This extension does not replace media negotiation mechanisms defined		The Presence Information Data Format (PIDF) defines a basic format
	for SIP (e.g., SDP [8]), therefore media negotiation (e.g., choice of		for representing presence information for a presentity. That format
	voice and video codecs) MUST be performed according to RFC 3264 [10].		defines a textual note, an indication of availability (open or
	This extension is only aimed to give the watchers hints about the		closed) and a URI for communication. However, it is frequently
	presentity's preferences, willingness and capabilities to communicate		useful to convey additional information about a user that needs to be
	before watchers initiate SIP-based communication with the presentity.		interpreted by an automata, and is therefore not appropriate for
			placement in the note element of the PIDF document. This document
			defines extensions to the PIDF document format for conveying richer
			presence information. Generally, the extensions have been chosen to
			provide features common in existing presence systems at the time of
			writing, in addition to elements that could readily be derived
			automatically from existing sources of presence, such as calendaring
			systems, or sources describing the user's current physical
			environment.
	2. Terminology and Conventions		2. Terminology and Conventions
	This memo makes use of the vocabulary defined in the IMPP Model		This memo makes use of the vocabulary defined in the IMPP Model
	document [4]. Terms such as CLOSED, INSTANT MESSAGE, OPEN, PRESENCE		document [5]. Terms such as CLOSED, INSTANT MESSAGE, OPEN, PRESENCE
	SERVICE, PRESENTITY, WATCHER, and WATCHER USER AGENT in the memo are		SERVICE, PRESENTITY, WATCHER, and WATCHER USER AGENT in the memo are
	used in the same meaning as defined therein. The key words MUST,		used in the same meaning as defined therein. The key words MUST,
	MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and		MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and
	OPTIONAL in this document are to be interpreted as described in BCP		OPTIONAL in this document are to be interpreted as described in BCP
	XX, RFC 2119 [1].		14, RFC 2119 [1].
	3. The Meaning of "open" and "closed"		3. The Meaning of "open" and "closed"
	PIDF describes the basic status values of "open" or "closed" only as		PIDF describes the basic status values of "open" or "closed" only as
	"have meanings of general availability for other communications		"have meanings of general availability for other communications
	means". We define "closed" in our context as meaning that		means". We define "closed" in our context as meaning that
	communication to the contact address will in all likelihood not		communication to the contact address will in all likelihood not
	succeed, is undesired or will not reach the intended party. (For		succeed, is undesired or will not reach the intended party. (For
	example, a presentity may include a hotel phone number as a contact.		example, a presentity may include a hotel phone number as a contact.
	After check-out, the phone number will still ring, but reach the		After check-out, the phone number will still ring, but reach the
	chambermaid or the next guest. Thus, it would be declared "closed".)		chambermaid or the next guest. Thus, it would be declared "closed".)
	For "pres" contacts, "closed" means that no presence status		For "pres" contacts, "closed" means that no presence status
	information is available.		information is available.
	4. RPID Elements		4. RPID Elements
	4.1 Introduction		4.1 Introduction
	Below, we describe the RPID elements in detail. <activity>, <idle>		Below, we describe the RPID elements in detail. <activities>,
	<placetype>, <privacy>, <relationship>, extend the PIDF <status>		<idle>, <placetype> and <privacy> extend the PIDF <status> element,
	element, while <class> and <contacttype> extend the PIDF <tuple>		while <class>, <contacttype> and <relationship> extend the PIDF
	element.		<tuple> element.
	In general, it is highly unlikely that a presentity will publish or		In general, it is highly unlikely that a presentity will publish or
	announce all of these elements at the same time. Rather, these		announce all of these elements at the same time. Rather, these
	elements were chosen to give the presentity maximum flexibility in		elements were chosen to give the presentity maximum flexibility in
	deriving this information from existing sources, such as calendaring		deriving this information from existing sources, such as calendaring
	tools, device activity sensors or location trackers, as well as to		tools, device activity sensors or location trackers, as well as to
	manually configure this information.		manually configure this information.
	The namespace URIs for these elements defined by this specification		The namespace URIs for these elements defined by this specification
	are URNs [2], using the namespace identifier 'ietf' defined by [3]		are URNs [2], using the namespace identifier 'ietf' defined by [4]
	and extended by [5]:		and extended by [6]:
	urn:ietf:params:xml:ns:pidf:rpid-status		urn:ietf:params:xml:ns:pidf:status:rpid-status
	urn:ietf:params:xml:ns:pidf:rpid-tuple		urn:ietf:params:xml:ns:pidf:status:rpid-tuple
	4.2 Activity Element		This document uses a separate namespace for extending the PIDF
			'status' namespace, in accordance with Section 4.2.5 of [7].
	The <activity> indication describes what the presentity is currently		All elements described in this document are optional.
			The elements <activity>, <placetype>, <privacy> and <sphere> MAY be
			qualified with the 'since' and 'until' attributes to describe the
			absolute time when the element assumed this value and the absolute
			time until which is element is expected to be valid. The 'since'
			time MUST be in the past, the 'until' time in the future relative to
			the time of publication of the presence information and, if
			available, the PIDF 'timestamp' element.
			4.2 Activities Element
			The <activities> element describes what the presentity is currently
	doing. This can be quite helpful to the watcher in judging how		doing. This can be quite helpful to the watcher in judging how
	appropriate a communication attempt is and which means of		appropriate a communication attempt is and which means of
	communications is most likely to succeed and not annoy the		communications is most likely to succeed and not annoy the
	presentity. The activity indications correspond roughly to the		presentity. The activity indications correspond roughly to the
	category field in calendar entries, such as Section 4.8.1.2 of RFC		category field in calendar entries, such as Section 4.8.1.2 of RFC
	2445.		2445 [10].
	An activity indication consists of one or more values drawn from the		An activity enumeration consists of one or more values drawn from the
	list below, any other token string or IANA-registered values (Section		list below, any other token string or IANA-registered values (Section
	Section 7). Communities of interest such as a profession or an		Section 7).
	organization may define additional activity labels for their internal
	use.
	Depending on the presentity intent, all but the "available"		Depending on the presentity intent, all but the "permanent-absence"
	indication can be used with either status OPEN or CLOSED.		indication can be used with either status OPEN or CLOSED.
	Available: The presentity is available for communication.		on-the-phone: The presentity is talking on the telephone. This
	On-the-phone: The presentity is talking on the telephone. This
	activity is included since it can often be derived automatically.		activity is included since it can often be derived automatically.
			away: The presentity is physically away from the device location.
	Away: The presentity is physically away from the device location.
	This activity was included since it can often be derived		This activity was included since it can often be derived
	automatically from security systems, energy management systems or		automatically from security systems, energy management systems or
	entry badge systems.		entry badge systems.
			appointment: The presentity has a calendar appointment, without
	Appointment: The presentity has a calendar appointment.		specifying exactly of what type. This activity is indicated if
			more detailed information is not available or the presentity
	Holiday: This is a scheduled national or local holiday. This		choses not to reveal more information.
			holiday: This is a scheduled national or local holiday. This
	information can typically be derived automatically from calendars.		information can typically be derived automatically from calendars.
			meal: The presentity is scheduled for a meal. This activity category
	Meal: The presentity is scheduled for a meal. This activity category
	can often be generated automatically from a calendar.		can often be generated automatically from a calendar.
			meeting: A meeting is a sub-class of an appointment. This activity
	Meeting: This activity category can often be generated automatically		category can often be generated automatically from a calendar.
	from a calendar.		steering: The presentity is controlling a vehicle, ship or plane.
			in-transit: The presentity is riding in a vehicle, such as a car, but
	Steering: The presentity is controlling a vehicle, ship or plane.		not steering. The 'placetype' element provides more specific
			information about the type of conveyance the presentity is using.
	In-transit: The presentity is riding in a vehicle, such as a car, but		travel: The presentity is on a business or personal trip, but not
	not steering. Alternatively, the presentity MAY offer more
	specific information.
	Travel: The presentity is on a business or personal trip, but not
	necessarily in-transit. This category can often be generated		necessarily in-transit. This category can often be generated
	automatically from a calendar.		automatically from a calendar.
			vacation: Leisure travel. This activity category can often be
	Vacation: This activity category can often be generated automatically		generated automatically from a calendar.
	from a calendar.		sleeping: This activity category can often be generated automatically
	Sleeping: This activity category can often be generated automatically
	from a calendar, local time information or biometric data.		from a calendar, local time information or biometric data.
			busy: User is busy, without further details. While this activity
			would typically be associated with a status of CLOSED, a
			presentity may declare itself busy to discourage communication,
			but indicate that it still can be reached if needed.
			permanent-absence: Presentity will not return for the foreseeable
			future, e.g., because it is no longer working for the company.
			This activity is associated with a status of CLOSED.
	Busy: User is busy, without further details. This activity category		The <activity> element MAY be qualified with the 'since' and 'until'
	would typically be indicated manually.		attributes as described in Section 4.
	Permanent-absence: Presentity will not return for the foreseeable		The <activities> element can be used with tuples of all values of
	future, e.g., because it is no longer working for the company.		<contact-type>. For tuples consisting of multiple physical devices,
			i.e., of <contact-type> 'service' or 'presentity', these components
			can engage in multiple types of activities, particularly if qualified
			by a <relationship> element. In those cases, the <activities>
			element enumerates all unique values as child <activity> elements.
	The <activity> element MAY be qualified with the 'from' and 'until'		The <activities> element can be extended by adding elements from
	attributes to describe the time when the element assumed this value		other namespaces, e.g., to reflect activities appropriate for a
	and the time until which is element is expected to be valid. The		particular occupation.
	'from' time MUST be in the past, the 'until' time in the future
	relative to the publication of the presence information.
	4.3 Class		4.3 Class
	The 'class' attribute describes the class of the tuple. Multiple		The 'class' attribute describes the class of the tuple. Multiple
	tuples can have the same class name within a presence document. The		tuples can have the same class name within a presence document. The
	naming of classes is left to the presentity. The presentity can use		naming of classes is left to the presentity. The presentity can use
	this information to group similar tuples or to convey information		this information to group similar tuples or to convey information
	that the presence agent can use for filtering.		that the presence agent can use for filtering.
	4.4 Contact-Type Element		4.4 Contact-Type Element
	The <contacttype> element describes the type of the tuple. A tuple		The <contacttype> element describes the type of the tuple. A tuple
	can represent a communication facility ("device"), a face-to-face		can represent a communication facility ("device"), a face-to-face
	communication tuple ("in-person"), a set of devices offering a common		communication tuple ("in-person"), a set of devices offering a common
	service ("service"), or a whole presentity ("presentity").		service ("service"), or a whole presentity ("presentity").
	Additional types can be registered with IANA.		Additional types can be registered with IANA.
	4.5 Idle Element		4.5 Idle Element
	The <idle> records the absolute time and date the communication		For tuples representing a single device, i.e., having a
	device was last used. This provides an indication as to how likely a		<contact-type> of 'device', the <idle> element records the absolute
	user is to answer the device. A device that has not been used in a		time and date the communication device was last used. This provides
	while may still be OPEN, but a watcher may choose to first contact a		an indication as to how likely a user is to answer when contacting
	device that is both OPEN and not marked as idle.		that device. A device that has not been used in a while may still be
			OPEN, but a watcher may choose to first contact a device that is both
			OPEN and has been used more recently. Note that the idle time refers
			to the whole device, not just the particular service. For example, a
			tuple describing an instant messaging device expresses the last time
			that the PC or PDA was used, not the last time an instant message has
			been sent.
			For tuples representing a 'presentity' or 'service' with multiple
			devices, the device with the most recent usage, i.e., the shortest
			idle time, determines the idle time for the whole tuple.
			The use of 'idle' for tuples with contact-type 'in-person' is not
			defined.
	The <idle> element can be empty if the presentity wants to indicate		The <idle> element can be empty if the presentity wants to indicate
	that the device has not been used for a while, but does not want to		that the device has not been used for a while, but does not want to
	reveal the precise duration:		reveal the precise duration, as in:
	<idle/>		<idle/>
	The <idle> SHOULD be included in the presence document if the idle		The <idle> element SHOULD be included in the presence document if the
	time exceeds a user-setable threshold, with a RECOMMENDED default		idle time exceeds a user-setable threshold, with a RECOMMENDED
	value of 10 minutes. Configuration MUST include the option to omit		default value of 10 minutes. Configuration MUST include the option
	the timestamp.		to omit the timestamp.
	4.6 Type of Place Element		4.6 Type of Place Element
	The <placetype> element describes the type of place the presentity is		The <placetype> element describes the type of place the presentity is
	currently at. This offers the watcher an indication what kind of		currently at. This offers the watcher an indication what kind of
	communication is likely to be appropriate. We define an initial set		communication is likely to be appropriate. We define an initial set
	of values below:		of values below:
	home: The presentity is in a private or residential setting, not		home: The presentity is in a private or residential setting, not
	necessarily the personal residence of the presentity, e.g.,		necessarily the personal residence of the presentity, e.g.,
	skipping to change at page 8, line 45 ¶		skipping to change at page 7, line 16 ¶
	4.6 Type of Place Element		4.6 Type of Place Element
	The <placetype> element describes the type of place the presentity is		The <placetype> element describes the type of place the presentity is
	currently at. This offers the watcher an indication what kind of		currently at. This offers the watcher an indication what kind of
	communication is likely to be appropriate. We define an initial set		communication is likely to be appropriate. We define an initial set
	of values below:		of values below:
	home: The presentity is in a private or residential setting, not		home: The presentity is in a private or residential setting, not
	necessarily the personal residence of the presentity, e.g.,		necessarily the personal residence of the presentity, e.g.,
	including hotel or a friend's home.		including hotel or a friend's home.
	office: The presentity is in a business setting, such as an office.		office: The presentity is in a business setting, such as an office.
			quiet: The presentity is in a place such as a library, restaurant,
			place-of-worship, or theater that discourages noise, conversation
			and other distractions.
	public: The presentity is in a public area such as a shopping mall,		public: The presentity is in a public area such as a shopping mall,
	street, park, public building, train station, airport or in public		street, park, public building, train station, airport or in public
	conveyance such as a bus, train, plane or ship. Alternatively, the		conveyance such as a bus, train, plane or ship. This general
	more detailed indications below may be provided.		description encompasses the more precise descriptors 'street',
			'public-transport', 'aircraft', 'ship', 'bus', 'train', 'airport',
			'mall' and 'outdoors' below.
	street: Walking in a street.		street: Walking in a street.
	public-transport: Any form of public transport, including aircraft,		public-transport: Any form of public transport, including aircraft,
	bus, train or ship.		bus, train or ship.
	aircraft: The presentity is in a plane, helicopter or balloon.		aircraft: The presentity is in a plane, helicopter or balloon.
	ship: Water vessel, boat.		ship: Water vessel, boat.
			bus: Public or charter bus.
	bus: Public bus.		train: The presentity is traveling in a train, monorail, maglev,
			cable car or similar conveyance.
	train: The presentity is traveling in a train, cable car.
	airport: Airport, heliport or similar location.		airport: Airport, heliport or similar location.
	station: Bus or train station.		station: Bus or train station.
	mall: Shopping mall or shopping area.		mall: Shopping mall or shopping area.
	outdoors: General outdoors area, such as a park or city streets.		outdoors: General outdoors area, such as a park or city streets.
	This list can be augmented by free-text values or additional		This list can be augmented by free-text values or additional
	IANA-registered values (Section Section 7).		IANA-registered values (Section Section 7).
	The <placetype> element MAY be qualified with the 'from' and 'until'		The <placetype> element can be used with tuples of all values of
	attributes to describe the time when the element assumed this value		<contact-type>. For tuples consisting of multiple physical devices,
	and the time until which is element is expected to be valid. The		i.e., of <contact-type> 'service' or 'presentity', these devices can
	'from' time MUST be in the past, the 'until' time in the future		be in multiple types of places. In those cases, the <placetype>
	relative to the publication of the presence information.		element enumerates all unique values as a token list.
			The <placetype> element MAY be qualified with the 'since' and 'until'
			attributes as described in Section 4.
	4.7 Privacy Element		4.7 Privacy Element
	The 'privacy' element indicates whether third parties may be able to		The 'privacy' element indicates whether third parties may be able to
	hear or view parts of the communication.		hear or view parts of the communication.
	public: Others may be able to see or hear the communications.		public: Others may be able to see or hear the communications.
	private: Inappropriate individuals are not likely to see or hear the		private: Inappropriate individuals are not likely to see or hear the
	communications.		communications.
	quiet: The presentity is in a place such as a library, restaurant,
	place-of-worship, or theater that discourages noise, conversation
	and other distractions.
	This indication is not limited to voice communications. For example,		This indication is not limited to voice communications. For example,
	a presentity might label her privacy as "quiet" when giving a talk,		a presentity might label her privacy as "quiet" when giving a talk,
	since it would be inappropriate if an instant message popped up on		since it would be inappropriate if an instant message popped up on
	the laptop screen that is being projected for the audience.		the laptop screen that is being projected for the audience.
	The 'activity' element MAY be qualified with the 'from' and 'until'		The 'placetype' element MAY be qualified with the 'since' and 'until'
	attributes to describe the time when the element assumed this value		attributes as described in Section 4.
	and the time until which is element is expected to be valid. The
	'from' time MUST be in the past, the 'until' time in the future
	relative to the publication of the presence information.
	4.8 Relationship Element		4.8 Relationship Element
	The <relationship> element designates the type of relationship an		The <relationship> element extends <tuple> and designates the type of
	alternate contact has with the presentity. This element is provided		relationship an alternate contact has with the presentity. This
	only if the tuple refers to somebody other than the presentity.		element is provided only if the tuple refers to somebody other than
	Relationship values include "family", "associate" (e.g., for a		the presentity. Relationship values include "family", "associate"
	colleague), "assistant", "supervisor". Other free-text values and		(e.g., for a colleague), "assistant", "supervisor". Other free-text
	additional IANA-registered values (Section Section 7) can be used as		values and additional IANA-registered values (Section 7) can be used
	well.		as well.
			If a relationship is indicated, the RPID <status> values describe the
			<contact>, not the presentity.
	The <contact> element for tuples labeled with a relationship can		The <contact> element for tuples labeled with a relationship can
	contain either a communication URI such as "im", "sip"/"sips",		contain either a communication URI such as "im", "sip"/"sips",
	"h323", "tel" or "mailto", or a presence URI, such as "pres" or		"h323", "tel" or "mailto", or a presence URI, such as "pres" or
	"sip".		"sip".
	4.9 Sphere Element		4.9 Sphere Element
	The <sphere> element designates the current state and role that the		The <sphere> element designates the current state and role that the
	presentity plays. For example, it might describe whether the		presentity plays. For example, it might describe whether the
	skipping to change at page 11, line 5 ¶		skipping to change at page 9, line 9 ¶
	Spheres are likely to be used for two purposes: they allow the		Spheres are likely to be used for two purposes: they allow the
	presentity to easily turn on or off certain rules that depend on what		presentity to easily turn on or off certain rules that depend on what
	groups of people should be made aware of the presentity's status.		groups of people should be made aware of the presentity's status.
	For example, if the presentity is a Boy Scout leader, he might set		For example, if the presentity is a Boy Scout leader, he might set
	the sphere to 'scouting' and then have a rule set that allows other		the sphere to 'scouting' and then have a rule set that allows other
	scout masters in his troup to see his presence status. As soon as he		scout masters in his troup to see his presence status. As soon as he
	switches his status to 'work' or 'home' or some other sphere, the		switches his status to 'work' or 'home' or some other sphere, the
	fellow scouts would lose access.		fellow scouts would lose access.
			The <sphere> element can be used with tuples of all values of
			<contact-type>. For tuples representing multiple physical devices,
			<contact-type> 'service' or 'presentity', these devices can be
			controlled by people in multiple different spheres. In those cases,
			the <sphere> element enumerates all unique values as a token list.
			The <sphere> element MAY be qualified with the 'since' and 'until'
			attributes as described in Section 4.
	5. Examples		5. Examples
	5.1 Presentity with Activity		5.1 Presentity with Activity
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<presence xmlns="urn:ietf:params:xml:ns:pidf"		<presence xmlns="urn:ietf:params:xml:ns:pidf"
	xmlns:es="urn:ietf:params:xml:ns:pidf:rpid-status"		xmlns:ep="urn:ietf:params:xml:ns:pidf:status:rpid-status"
	xmlns:et="urn:ietf:params:xml:ns:pidf:rpid-tuple"		xmlns:et="urn:ietf:params:xml:ns:pidf:rpid-tuple"
	entity="pres:someone@example.com">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
			entity="pres:someone@example.com">
	<note>I'm in a boring meeting</note>		<tuple id="c8dqui">
			<status>
	<tuple id="7c8dqui">		<basic>open</basic>
	<et:class>assistant</et:class>		<ep:relationship>assistant</ep:relationship>
	<et:contact-type>presentity</et:contact-type>		</status>
	<status>		<et:class>assistant</et:class>
	<basic>open</basic>		<et:contact-type>presentity</et:contact-type>
	<contact>sip:secretary@example.com</contact>		<contact>sip:secretary@example.com</contact>
	<ep:relationship>assistant</ep:relationship>		<note>My secretary</note>
	</status>		</tuple>
	<note>My secretary</note>		<tuple id="x765">
	</tuple>		<status>
			<basic>open</basic>
	<tuple id="18x765">		<ep:activity>
	<et:class>sip</et:class>		<ep:activity>meeting</ep:activity></ep:activity>
	<et:contact-type>service</et:contact-type>		<ep:placetype until="2003-01-27T17:30:00Z">office</ep:placetype>
	<status>		<ep:privacy>quiet</ep:privacy>
	<basic>open</basic>		<ep:idle>2003-01-27T10:43:00Z</ep:idle>
	<ep:activity>meeting</ep:meeting>		</status>
	<ep:placetype until="2003-01-27T17:30:00Z">office</ep:placetype>		<et:class>sip</et:class>
	<ep:privacy>quiet</ep:privacy>		<et:contact-type>service</et:contact-type>
	<ep:idle>2003-01-27T10:43:00Z</ep:idle>		<contact priority="0.8">sip:someone@example.com</contact>
	</status>		<timestamp>2001-10-27T16:49:29Z</timestamp>
	<contact priority="0.8">sip:someone@example.com</contact>
	<timestamp>2001-10-27T16:49:29Z</timestamp>
	</tuple>
	<tuple id="35bs9r">		</tuple>
	<et:class>phone</et:class>		<tuple id="bs9r">
	<et:contact-type>device</et:contact-type>		<status>
	<status>		<basic>open</basic>
	<basic>open</basic>		<ep:privacy>quiet</ep:privacy>
	<ep:privacy>quiet</ep:privacy>		</status>
	</status>		<contact priority="0.8">im:someone@mobilecarrier.net</contact>
	<contact priority="0.8">im:someone@mobilecarrier.net</contact>		<timestamp>2001-10-27T16:49:29Z</timestamp>
	<timestamp>2001-10-27T16:49:29Z</timestamp>		</tuple>
	</tuple>		<tuple id="eg92n">
	<tuple id="8eg92n">		<status>
	<et:class>mail</et:class>		<basic>open</basic>
	<et:contact-type>device</et:contact-type>		</status>
	<status>		<et:class>mail</et:class>
	<basic>open</basic>		<nn:blah>blah</nn:blah>
	</status>		<et:contact-type>device</et:contact-type>
	<contact priority="1.0">mailto:someone@example.com</contact>		<contact priority="1.0">mailto:someone@example.com</contact>
	</tuple>		<note>I'm in a boring meeting</note>
	</presence>		</tuple>
			</presence>
	6. XML Schema Definitions		6. XML Schema Definitions
			6.1 urn:ietf:params:xml:ns:pidf:rpid-tuple
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<xs:schema xmlns="urn:ietf:params:xml:ns:pidf:rpid-tuple"		<xs:schema xmlns="urn:ietf:params:xml:ns:pidf:rpid-tuple"
	xmlns:pidf="urn:ietf:params:xml:ns:pidf"		xmlns:pidf="urn:ietf:params:xml:ns:pidf"
	xmlns:xs="http://www.w3.org/2001/XMLSchema"		xmlns:xs="http://www.w3.org/2001/XMLSchema"
	elementFormDefault="qualified"		elementFormDefault="qualified"
	attributeFormDefault="unqualified">		attributeFormDefault="unqualified">
	<!-- This import brings in the XML language attribute xml:lang-->		<!-- This import brings in the XML language attribute xml:lang-->
	<xs:import namespace="http://www.w3.org/XML/1998/namespace"		<xs:import namespace="http://www.w3.org/XML/1998/namespace"
	skipping to change at page 13, line 36 ¶		skipping to change at page 11, line 35 ¶
	<xs:restriction base="xs:token">		<xs:restriction base="xs:token">
	<xs:enumeration value="device"/>		<xs:enumeration value="device"/>
	<xs:enumeration value="in-person"/>		<xs:enumeration value="in-person"/>
	<xs:enumeration value="service"/>		<xs:enumeration value="service"/>
	<xs:enumeration value="presentity"/>		<xs:enumeration value="presentity"/>
	</xs:restriction>		</xs:restriction>
	</xs:simpleType>		</xs:simpleType>
	</xs:element>		</xs:element>
	<xs:element name="class" type="xs:token"/>		<xs:element name="class" type="xs:token"/>
	</xs:schema>
	<?xml version="1.0" encoding="UTF-8"?>		<xs:element name="relationship" type="xs:token"/>
	<xs:schema xmlns="urn:ietf:params:xml:ns:pidf:status:rpid-status"		</xs:schema>
	xmlns:pidf="urn:ietf:params:xml:ns:pidf"
	xmlns:xs="http://www.w3.org/2001/XMLSchema"
	elementFormDefault="qualified"
	attributeFormDefault="unqualified">
	<!-- This import brings in the XML language attribute xml:lang-->		6.2 urn:ietf:params:xml:ns:pidf:status:rpid-status
	<xs:import namespace="http://www.w3.org/XML/1998/namespace"
	schemaLocation="http://www.w3.org/2001/xml.xsd"/>
	<xs:annotation>		<?xml version="1.0" encoding="UTF-8"?>
	<xs:documentation xml:lang="en">		<!-- edited with XMLSPY v2004 rel. 3 U (http://www.xmlspy.com) by Henning Schulzrinne (Columbia University) -->
			<xs:schema xmlns="urn:ietf:params:xml:ns:pidf:status:rpid-status" xmlns:pidf="urn:ietf:params:xml:ns:pidf" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
			<!-- This import brings in the XML language attribute xml:lang-->
			<xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"/>
			<xs:annotation>
			<xs:documentation xml:lang="en">
	Describes RPID status extensions for PIDF.		Describes RPID status extensions for PIDF.
	</xs:documentation>		</xs:documentation>
	</xs:annotation>		</xs:annotation>
			<xs:attributeGroup name="SinceUntil">
	<xs:element name="activity" type="activity_t"/>		<xs:attribute name="since" type="xs:dateTime"/>
			<xs:attribute name="until" type="xs:dateTime"/>
	<xs:simpleType name="activityToken">		</xs:attributeGroup>
	<xs:restriction base="xs:token">		<xs:simpleType name="tokenlist">
	</xs:restriction>		<xs:list itemType="xs:token"/>
	</xs:simpleType>		</xs:simpleType>
			<xs:element name="activities">
	<xs:complexType name="activity_t">		<xs:complexType>
	<xs:sequence>		<xs:sequence>
	<xs:element name="activity" type="activityToken"/>		<xs:element name="activity" minOccurs="0" maxOccurs="unbounded">
	</xs:sequence>		<xs:simpleType>
	<xs:attribute name="from" type="xs:dateTime"/>		<xs:restriction base="xs:token">
	</xs:complexType>		<xs:enumeration value="holiday"/>
			<xs:enumeration value="on-the-phone"/>
	<xs:element name="placetype">		<xs:enumeration value="away"/>
	<xs:complexType>		<xs:enumeration value="appointment"/>
	<xs:simpleContent>		<xs:enumeration value="meal"/>
	<xs:extension base="xs:token">		<xs:enumeration value="meeting"/>
	<xs:attribute name="from" type="xs:dateTime"/>		<xs:enumeration value="steering"/>
	<xs:attribute name="until" type="xs:dateTime"/>		<xs:enumeration value="in-transit"/>
	</xs:extension>		<xs:enumeration value="travel"/>
	</xs:simpleContent>		<xs:enumeration value="vacation"/>
	</xs:complexType>		<xs:enumeration value="sleeping"/>
	</xs:element>		<xs:enumeration value="busy"/>
			<xs:enumeration value="permanent-absence"/>
	<xs:simpleType name="privacy_t">		</xs:restriction>
	<xs:restriction base="xs:token">		</xs:simpleType>
	<xs:enumeration value="private"/>		</xs:element>
	<xs:enumeration value="public"/>		<xs:any maxOccurs="unbounded"/>
	<xs:enumeration value="quiet"/>		</xs:sequence>
	</xs:restriction>		</xs:complexType>
	</xs:simpleType>		</xs:element>
			<xs:element name="placetype">
	<xs:element name="privacy">		<xs:complexType>
	<xs:complexType>		<xs:simpleContent>
	<xs:simpleContent>		<xs:extension base="tokenlist">
	<xs:extension base="privacy_t">		<xs:attributeGroup ref="SinceUntil"/>
	<xs:attribute name="from" type="xs:dateTime"/>		</xs:extension>
	<xs:attribute name="until" type="xs:dateTime"/>		</xs:simpleContent>
	</xs:extension>		</xs:complexType>
	</xs:simpleContent>		</xs:element>
	</xs:complexType>		<xs:element name="privacy">
			<xs:complexType>
	</xs:element>		<xs:simpleContent>
			<xs:extension base="tokenlist">
	<xs:simpleType name="sphereToken">		<xs:attributeGroup ref="SinceUntil"/>
	<xs:restriction base="xs:token">		</xs:extension>
	</xs:restriction>		</xs:simpleContent>
	</xs:simpleType>		</xs:complexType>
			</xs:element>
	<xs:complexType name="sphere_t">		<xs:element name="sphere">
	<xs:sequence>		<xs:complexType>
	<xs:element name="sphere" type="sphereToken"/>		<xs:simpleContent>
	</xs:sequence>		<xs:extension base="tokenlist">
	</xs:complexType>		<xs:attributeGroup ref="SinceUntil"/>
			</xs:extension>
	<xs:element name="sphere">		</xs:simpleContent>
	<xs:complexType>		</xs:complexType>
	<xs:complexContent>		</xs:element>
	<xs:extension base="sphere_t">		<xs:element name="idle">
	<xs:attribute name="from" type="xs:dateTime"/>		<xs:complexType>
	<xs:attribute name="until" type="xs:dateTime"/>		<xs:attribute name="since" type="xs:dateTime"/>
	</xs:extension>		</xs:complexType>
	</xs:complexContent>		</xs:element>
	</xs:complexType>
	</xs:element>
	<xs:element name="relationship" type="xs:token"/>
	<xs:element name="idle" type="xs:dateTime"/>
	</xs:schema>		</xs:schema>
	7. IANA Considerations		7. IANA Considerations
	This document calls for IANA to:		This document calls for IANA to:
	o register two new XML namespace URNs per [5];		o register two new XML namespace URNs per [6];
			o establish registry for activity categories (Section 4.2), place
	o establish registry for activity categories (Section Section 4.2,		types (Section 4.6), and relationships (Section 4.8).
	place types (Section Section 4.6), and relationships (Section
	Section 4.8).
	Note that this document does not need a new content type. It		Note that this document does not need a new content type. It
	inherits the content type from [6], namely application/cpim-pidf+xml.		inherits the content type from [7], namely application/pidf+xml.
	7.1 URN Sub-Namespace Registration for		7.1 URN Sub-Namespace Registration for
	'urn:ietf:params:xml:ns:pidf:rpid-status'		'urn:ietf:params:xml:ns:pidf:status:rpid-status'
	URI: urn:ietf:params:xml:ns:rpid-status
			URI: urn:ietf:params:xml:ns:pidf:status:rpid-status
	Description: This is the XML namespace for XML elements defined by		Description: This is the XML namespace for XML elements defined by
	RFCXXXX to describe rich presence information extensions for the		RFC&rfc.number [RFC editor: replace with RFC number]; to describe
	status element in the PIDF presence document format in the		rich presence information extensions for the status element in the
	application/cpim-pidf+xml content type.		PIDF presence document format in the application/pidf+xml content
			type.
	Registrant Contact: IETF, SIMPLE working group, simple@ietf.org,		Registrant Contact: IETF, SIMPLE working group, simple@ietf.org,
	Henning Schulzrinne, hgs@cs.columbia.edu		Henning Schulzrinne, hgs@cs.columbia.edu
	XML:		XML:
	BEGIN		BEGIN
	<?xml version="1.0"?>		<?xml version="1.0"?>
	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"		<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
	"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">		"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
	<html xmlns="http://www.w3.org/1999/xhtml		<html xmlns="http://www.w3.org/1999/xhtml
	<head>		<head>
	<meta http-equiv="content-type"		<meta http-equiv="content-type"
	content="text/html;charset=iso-8859-1"/>		content="text/html;charset=iso-8859-1"/>
	<title>RPID -- Rich Presence Information Data Format		<title>RPID: Rich Presence: Extensions to the Presence
	for Presence</title>		Information Data Format (PIDF)</title>
	</head>		</head>
	<body>		<body>
	<h1>Namespace for rich presence extension (status)</h1>		<h1>Namespace for rich presence extension (status)</h1>
	<h2>application/pidf+xml</h2>		<h2>urn:ietf:params:xml:ns:pidf:status:rpid-status</h2>
	<p>See <a href="URL of published RFC">RFCXXXX</a>.</p>		<p>See <a href="URL of published RFC">RFC&rfc.number; [RFC
			editor: replace with RFC number]</a>.</p>
	</body>		</body>
	</html>		</html>
	END		END
	7.2 URN Sub-Namespace Registration for		7.2 URN Sub-Namespace Registration for
	'urn:ietf:params:xml:ns:pidf:rpid-tuple'		'urn:ietf:params:xml:ns:pidf:rpid-tuple'
	urn:ietf:params:xml:ns:rpid-tuple		URI: urn:ietf:params:xml:ns:pidf:rpid-tuple
			Description: This is the XML namespace for XML elements defined by
	This is the XML namespace for XML elements defined by RFCXXXX to		RFCXXXX [RFC editor: replace with RFC number] to describe rich
	describe rich presence information extensions for the tuple element		presence information extensions for the tuple element in the PIDF
	in the PIDF presence document format in the application/cpim-pidf+xml		presence document format in the application/pidf+xml content type.
	content type.		Registrant Contact: IETF, SIMPLE working group, simple@ietf.org,
			Henning Schulzrinne, hgs@cs.columbia.edu.
	IETF, SIMPLE working group, simple@ietf.org, Henning Schulzrinne,		XML:
	hgs@cs.columbia.edu.
	BEGIN		BEGIN
	<?xml version="1.0"?>		<?xml version="1.0"?>
	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"		<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
	"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">		"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
	<html xmlns="http://www.w3.org/1999/xhtml		<html xmlns="http://www.w3.org/1999/xhtml
	<head>		<head>
	<meta http-equiv="content-type"		<meta http-equiv="content-type"
	content="text/html;charset=iso-8859-1"/>		content="text/html;charset=iso-8859-1"/>
	<title>RPID -- Rich Presence Information Data Format		<title>RPID: Rich Presence: Extensions to the Presence
	for Presence</title>		Information Data Format (PIDF)</title>
	</head>		</head>
	<body>		<body>
	<h1>Namespace for rich presence extension (tuple)</h1>		<h1>Namespace for rich presence extension (tuple)</h1>
	<h2>application/pidf+xml</h2>		<h2>urn:ietf:params:xml:ns:pidf:rpid-tuple</h2>
	<p>See <a href="URL of published RFC">RFCXXXX</a>.</p>		<p>See <a href="URL of published RFC">RFC&rfc.number; [RFC
			editor: replace with RFC number]</a>.</p>
	</body>		</body>
	</html>		</html>
	END		END
	7.3 Place Type, Tuple Type, Activities, Relationships		7.3 Schema Registration for Schema
			urn:ietf:params:xml:ns:pidf:rpid-tuple'
	This document creates new IANA registries for activities, tuple		URI: please assign
	types, place types and relationships. All are XML tokens.		Registrant Contact: IESG
	Registered tokens must be documented at the time of registration, as		XML: See Section 6.1
	most descriptions are expected to be brief.
	The SIMPLE working group, or, if no longer available, the SIP working		7.4 Schema Registration for Schema
	group should be consulted prior to registration.		urn:ietf:params:xml:ns:pidf:status:rpid-status'
			URI: please assign
			Registrant Contact: IESG
			XML: See Section 6.2
			7.5 Token Registrations
			This document creates new IANA registries for RPID tokens:
			contact-type: See Section 4.4
			placetype: See Section 4.6
			privacy: See Section 4.7
			relationship: See Section 4.8
			All are XML tokens. Registered tokens must be documented at the time
			of registration, as most descriptions are expected to be brief.
			Following the policies outline in RFC 2434 [3], these tokens are
			assigned after Expert Review by the SIMPLE working group or its
			designated successor. Each registration must include the name of the
			token and a brief description similar to the ones offered in for the
			initial registrations contained this document.
	8. Security Considerations		8. Security Considerations
	The security considerations in [6] apply, as well as [7]. Compared to		The security considerations in [7] apply, as well as [8]. Compared to
	PIDF, this presence document format reveals additional information		PIDF, this presence document format reveals additional information
	that can be highly sensitive. Beyond traditional security measures to		that can be highly sensitive. Beyond traditional security measures to
	protect confidentiality and integrity, systems should offer a means		protect confidentiality and integrity, systems should offer a means
	to selectively reveal information to particular watchers and to		to selectively reveal information to particular watchers and to
	inspect the information that is being published, particularly if it		inspect the information that is being published, particularly if it
	is generated automatically from other sources, such as calendars or		is generated automatically from other sources, such as calendars or
	sensors.		sensors.
	Normative References		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] Moats, R., "URN Syntax", RFC 2141, May 1997.		[2] Moats, R., "URN Syntax", RFC 2141, May 1997.
	[3] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,		[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
			Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
			[4] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
	August 1999.		August 1999.
	[4] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and		[5] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and
	Instant Messaging", RFC 2778, February 2000.		Instant Messaging", RFC 2778, February 2000.
	[5] Mealling, M., "The IETF XML Registry",		[6] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January
	draft-mealling-iana-xmlns-registry-05 (work in progress), June		2004.
	2003.
	[6] Sugano, H. and S. Fujimoto, "Presence Information Data Format		[7] Sugano, H. and S. Fujimoto, "Presence Information Data Format
	(PIDF)", draft-ietf-impp-cpim-pidf-08 (work in progress), May		(PIDF)", draft-ietf-impp-cpim-pidf-08 (work in progress), May
	2003.		2003.
	[7] Rosenberg, J., "A Presence Event Package for the Session		[8] Rosenberg, J., "A Presence Event Package for the Session
	Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work		Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work
	in progress), January 2003.		in progress), January 2003.
	Informative References		Informative References
	[8] Handley, M. and V. Jacobson, "SDP: Session Description		[9] Handley, M. and V. Jacobson, "SDP: Session Description
	Protocol", RFC 2327, April 1998.		Protocol", RFC 2327, April 1998.
	[9] Dawson, F. and Stenerson, D., "Internet Calendaring and		[10] Dawson, F. and Stenerson, D., "Internet Calendaring and
	Scheduling Core Object Specification (iCalendar)", RFC 2445,		Scheduling Core Object Specification (iCalendar)", RFC 2445,
	November 1998.		November 1998.
	[10] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with		[11] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
	Session Description Protocol (SDP)", RFC 3264, June 2002.		Session Description Protocol (SDP)", RFC 3264, June 2002.
	[11] Lennox, J., Wu, X. and H. Schulzrinne, "CPL: A Language for		[12] Lennox, J., Wu, X. and H. Schulzrinne, "CPL: A Language for
	User Control of Internet Telephony Services",		User Control of Internet Telephony Services",
	draft-ietf-iptel-cpl-08 (work in progress), August 2003.		draft-ietf-iptel-cpl-08 (work in progress), August 2003.
	[12] Dawson, F., Reddy, S., Royer, D. and E. Plamondon, "iCalendar		[13] Dawson, F., Reddy, S., Royer, D. and E. Plamondon, "iCalendar
	DTD Document (xCal)", draft-ietf-calsch-many-xcal-02 (work in		DTD Document (xCal)", draft-ietf-calsch-many-xcal-02 (work in
	progress), July 2002.		progress), July 2002.
	Authors' Addresses		Authors' Addresses
	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
	skipping to change at page 21, line 4 ¶		skipping to change at page 17, line 41 ¶
	URI: http://www.cs.columbia.edu		URI: http://www.cs.columbia.edu
	Vijay Gurbani		Vijay Gurbani
	Lucent		Lucent
	2000 Naperville Rd.		2000 Naperville Rd.
	Room 6G-440		Room 6G-440
	Naperville, IL 60566-7033		Naperville, IL 60566-7033
	US		US
	EMail: vkg@lucent.com		EMail: vkg@lucent.com
	Paul Kyzivat		Paul Kyzivat
	Cisco Systems		Cisco Systems
	BXB500 C2-2		BXB500 C2-2
	1414 Massachusetts Avenue		1414 Massachusetts Avenue
	Boxborough, MA 01719		Boxborough, MA 01719
	US		US
	EMail: pkzivat@cisco.com		EMail: pkzivat@cisco.com
	Jonathan Rosenberg		Jonathan Rosenberg
	dynamicsoft		dynamicsoft
	600 Lanidex Plaza		600 Lanidex Plaza
	Parsippany, NJ 07054-2711		Parsippany, NJ 07054-2711
	US		US
	EMail: jdrosen@dynamicsoft.com		EMail: jdrosen@dynamicsoft.com
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
	The document reflects the discussion on the SIMPLE mailing list, with		The document reflects the discussion on the SIMPLE mailing list, with
	contributions from many individuals. Markus Isomaki, Hisham		contributions from many individuals. Markus Isomaki, Hisham
	Khartabil, Jon Peterson and Brian Rosen provided detailed comments		Khartabil, Jon Peterson and Brian Rosen provided detailed comments
	and suggestions. Xiaotao Wu assisted with schema testing.		and suggestions. Xiaotao Wu assisted with schema testing.
	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 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; neither does it represent that it		might or might not be available; nor does it represent that it has
	has made any effort to identify any such rights. Information on the		made any independent effort to identify any such rights. Information
	IETF's procedures with respect to rights in standards-track and		on the IETF's procedures with respect to rights in IETF Documents can
	standards-related documentation can be found in BCP-11. Copies of		be found in BCP 78 and BCP 79.
	claims of rights made available for publication and any assurances of
	licenses to be made available, or the result of an attempt made to		Copies of IPR disclosures made to the IETF Secretariat and any
	obtain a general license or permission for the use of such		assurances of licenses to be made available, or the result of an
	proprietary rights by implementors or users of this specification can		attempt made to obtain a general license or permission for the use of
	be obtained from the IETF Secretariat.		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		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights which may cover technology that may be required to practice		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF Executive		this standard. Please address the information to the IETF at
	Director.		ietf-ipr@ietf.org.
	Full Copyright Statement
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Disclaimer of Validity
	This document and translations of it may be copied and furnished to		This document and the information contained herein are provided on an
	others, and derivative works that comment on or otherwise explain it		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	or assist in its implementation may be prepared, copied, published		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	and distributed, in whole or in part, without restriction of any		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	kind, provided that the above copyright notice and this paragraph are		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	included on all such copies and derivative works. However, this		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	document itself may not be modified in any way, such as by removing		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of
	developing Internet standards in which case the procedures for
	copyrights defined in the Internet Standards process must be
	followed, or as required to translate it into languages other than
	English.
	The limited permissions granted above are perpetual and will not be		Copyright Statement
	revoked by the Internet Society or its successors or assignees.
	This document and the information contained herein is provided on an		Copyright (C) The Internet Society (2004). This document is subject
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		to the rights, licenses and restrictions contained in BCP 78, and
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		except as set forth therein, the authors retain all their rights.
	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.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes. 92 change blocks.
	366 lines changed or deleted		419 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/