< draft-ietf-simple-winfo-package-04.txt		draft-ietf-simple-winfo-package-05.txt >
	Internet Engineering Task Force SIMPLE WG		Internet Engineering Task Force SIMPLE WG
	Internet Draft J. Rosenberg		Internet Draft J. Rosenberg
	dynamicsoft		dynamicsoft
	draft-ietf-simple-winfo-package-04.txt		draft-ietf-simple-winfo-package-05.txt
	December 6, 2002		January 31, 2003
	Expires: June 2003		Expires: July 2003
	A Watcher Information Event Template-Package for the		A Watcher Information Event Template-Package for
	Session Initiation Protocol (SIP)		the Session Initiation Protocol (SIP)
	STATUS OF THIS MEMO		STATUS OF THIS MEMO
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	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
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 5, line 15 ¶		skipping to change at page 5, line 15 ¶
	Max-Forwards: 70		Max-Forwards: 70
	CSeq: 1288 NOTIFY		CSeq: 1288 NOTIFY
	Contact: sip:B@server.example.com		Contact: sip:B@server.example.com
	Event: presence.winfo		Event: presence.winfo
	Content-Type: application/watcherinfo+xml		Content-Type: application/watcherinfo+xml
	Content-Length: ...		Content-Length: ...
	<?xml version="1.0"?>		<?xml version="1.0"?>
	<watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"		<watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"
	version="0" state="full">		version="0" state="full">
	<watcher-list resource="sip:B@foo.com" package="presence">		<watcher-list resource="sip:B@example.com" package="presence">
	<watcher id="7768a77s" event="subscribe"		<watcher id="7768a77s" event="subscribe"
	status="pending">sip:A@foo.com</watcher>		status="pending">sip:A@example.com</watcher>
	</watcher-list>		</watcher-list>
	</watcherinfo>		</watcherinfo>
	This indicates to B that A has subscribed, and that the subscription		This indicates to B that A has subscribed, and that the subscription
	is pending (meaning, it is awaiting authorization). B's software can		is pending (meaning, it is awaiting authorization). B's software can
	alert B that this subscription is awaiting authorization. B can then		alert B that this subscription is awaiting authorization. B can then
	set policy for that subscription.		set policy for that subscription.
	3.2 Blacklist Alerts		3.2 Blacklist Alerts
	skipping to change at page 7, line 32 ¶		skipping to change at page 7, line 32 ¶
	4.5 NOTIFY Bodies		4.5 NOTIFY Bodies
	RFC 3265 [1] requires package definitions to describe the allowed set		RFC 3265 [1] requires package definitions to describe the allowed set
	of body types in NOTIFY requests, and to specify the default value to		of body types in NOTIFY requests, and to specify the default value to
	be used when there is no Accept header field in the SUBSCRIBE		be used when there is no Accept header field in the SUBSCRIBE
	request.		request.
	The body of the watcherinfo notification contains a watcher		The body of the watcherinfo notification contains a watcher
	information document. This document describes some or all of the		information document. This document describes some or all of the
	watchers for a given package, and the state of their subscriptions.		watchers for a given package, and the state of their subscriptions.
	All watcherinfo subscribers MUST support the		All watcherinfo subscribers and notifiers MUST support the
	application/watcherinfo+xml format described in [3], and MUST list		application/watcherinfo+xml format described in [3], and MUST list
	its MIME type, application/watcherinfo+xml, in any Accept header		its MIME type, application/watcherinfo+xml, in any Accept header
	field present in the SUBSCRIBE request.		field present in the SUBSCRIBE request.
	Other watcher information formats might be defined in the future. In		Other watcher information formats might be defined in the future. In
	that case, the watcherinfo subscriptions MAY indicate support for		that case, the watcherinfo subscriptions MAY indicate support for
	other formats. However, they MUST always support and list		other formats. However, they MUST always support and list
	application/watcherinfo+xml as an allowed format.		application/watcherinfo+xml as an allowed format.
	Of course, the watcherinfo notifications generated by the server MUST		Of course, the watcherinfo notifications generated by the server MUST
	skipping to change at page 10, line 15 ¶		skipping to change at page 10, line 15 ¶
	policy= +----------+		policy= +----------+
	reject | |<------------------------+		reject | |<------------------------+
	+------------>|terminated|<---------+ |		+------------>|terminated|<---------+ |
	| | | | |		| | | | |
	| | | |noresource |		| | | |noresource |
	| +----------+ |rejected |		| +----------+ |rejected |
	| ^noresource |deactivated |		| ^noresource |deactivated |
	| |rejected |probation |		| |rejected |probation |
	| |deactivated |timeout |noresource		| |deactivated |timeout |noresource
	| |probation | |rejected		| |probation | |rejected
	| |giveup | |deactivated		| |giveup | |giveup
	| | | |probation		| | | |approved
	+-------+ +-------+ +-------+ |giveup		+-------+ +-------+ +-------+ |
	| |subscribe| |approved| | |approved		| |subscribe| |approved| | |
	| init |-------->|pending|------->|active | |		| init |-------->|pending|------->|active | |
	| |no policy| | | | |		| |no policy| | | | |
	| | | | | | |		| | | | | | |
	+-------+ +-------+ +-------+ |		+-------+ +-------+ +-------+ |
	| | ^ ^ |		| | ^ ^ |
	| subscribe, | | | |		| subscribe, | | | |
	+-----------------------------------+ |		+-----------------------------------+ |
	policy = accept | | +-------+ |		policy = accept | | +-------+ |
	| |subscribe | | |		| |subscribe | | |
	| +----------|waiting|----------+		| +----------|waiting|----------+
	skipping to change at page 14, line 6 ¶		skipping to change at page 14, line 6 ¶
	resource. This server would accept the watcherinfo subscription		resource. This server would accept the watcherinfo subscription
	(assuming it was authorized, of course), and generate watcherinfo		(assuming it was authorized, of course), and generate watcherinfo
	notifications as the watcherinfo state changed. The watcherinfo		notifications as the watcherinfo state changed. The watcherinfo
	subscriber would only have a single dialog in this case.		subscriber would only have a single dialog in this case.
	5 Example Usage		5 Example Usage
	The following section discusses an example application and call flows		The following section discusses an example application and call flows
	using the watcherinfo package.		using the watcherinfo package.
	In this example, a user Joe, sip:joe@bar.com provides presence		In this example, a user Joe, sip:joe@example.com provides presence
	through the bar.com presence server. Joe subscribes to his own		through the example.com presence server. Joe subscribes to his own
	watcher information, in order to learn about people who subscribe to		watcher information, in order to learn about people who subscribe to
	his presence, so that he can approve or reject their subscriptions.		his presence, so that he can approve or reject their subscriptions.
	Joe sends the following SUBSCRIBE request:		Joe sends the following SUBSCRIBE request:
	SUBSCRIBE sip:joe@bar.com SIP/2.0		SUBSCRIBE sip:joe@example.com SIP/2.0
	Via: SIP/2.0/UDP pc34.bar.com;branch=z9hG4bKnashds7		Via: SIP/2.0/UDP pc34.example.com;branch=z9hG4bKnashds7
	From: sip:joe@bar.com;tag=123aa9		From: sip:joe@example.com;tag=123aa9
	To: sip:joe@bar.com		To: sip:joe@example.com
	Call-ID: 9987@pc34.bar.com		Call-ID: 9987@pc34.example.com
	CSeq: 9887 SUBSCRIBE		CSeq: 9887 SUBSCRIBE
	Contact: sip:joe@pc34.bar.com		Contact: sip:joe@pc34.example.com
	Event: presence.winfo		Event: presence.winfo
	Max-Forwards: 70		Max-Forwards: 70
	The server responds with a 401 to authenticate, and Joe resubmits the		The server responds with a 401 to authenticate, and Joe resubmits the
	SUBSCRIBE with credentials (message not shown). The server then		SUBSCRIBE with credentials (message not shown). The server then
	authorizes the subscription, since it allows Joe to subscribe to his		authorizes the subscription, since it allows Joe to subscribe to his
	own watcher information for presence. It responds with a 200 OK:		own watcher information for presence. It responds with a 200 OK:
	SIP/2.0 200 OK		SIP/2.0 200 OK
	Via: SIP/2.0/UDP pc34.bar.com;branch=z9hG4bKnashds8		Via: SIP/2.0/UDP pc34.example.com;branch=z9hG4bKnashds8
	;received=1.2.3.4		;received=192.0.2.8
	From: sip:joe@bar.com;tag=123aa9		From: sip:joe@example.com;tag=123aa9
	To: sip:joe@bar.com;tag=xyzygg		To: sip:joe@example.com;tag=xyzygg
	Call-ID: 9987@pc34.bar.com		Call-ID: 9987@pc34.example.com
	CSeq: 9988 SUBSCRIBE		CSeq: 9988 SUBSCRIBE
	Contact: sip:server19.bar.com		Contact: sip:server19.example.com
	Expires: 3600		Expires: 3600
	Event: presence.winfo		Event: presence.winfo
	The server then sends a NOTIFY with the current state of		The server then sends a NOTIFY with the current state of
	presence.winfo for joe@bar.com:		presence.winfo for joe@example.com:
	NOTIFY sip:joe@pc34.bar.com SIP/2.0		NOTIFY sip:joe@pc34.example.com SIP/2.0
	Via: SIP/2.0/UDP server19.bar.com;branch=z9hG4bKnasaii		Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaii
	From: sip:joe@bar.com;tag=xyzygg		From: sip:joe@example.com;tag=xyzygg
	To: sip:joe@bar.com;tag=123aa9		To: sip:joe@example.com;tag=123aa9
	Call-ID: 9987@pc34.bar.com		Call-ID: 9987@pc34.example.com
	CSeq: 1288 NOTIFY		CSeq: 1288 NOTIFY
	Contact: sip:server19.bar.com		Contact: sip:server19.example.com
	Event: presence.winfo		Event: presence.winfo
	Max-Forwards: 70		Max-Forwards: 70
	Content-Type: application/watcherinfo+xml		Content-Type: application/watcherinfo+xml
	Content-Length: ...		Content-Length: ...
	<?xml version="1.0"?>		<?xml version="1.0"?>
	<watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"		<watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"
	version="0" state="full">		version="0" state="full">
	<watcher-list resource="sip:joe@bar.com" package="presence">		<watcher-list resource="sip:joe@example.com" package="presence">
	<watcher id="77ajsyy76" event="subscribe"		<watcher id="77ajsyy76" event="subscribe"
	status="pending">sip:A@example.com</watcher>		status="pending">sip:A@example.com</watcher>
	</watcher-list>		</watcher-list>
	</watcherinfo>		</watcherinfo>
	Joe then responds with a 200 OK to the NOTIFY:		Joe then responds with a 200 OK to the NOTIFY:
	SIP/2.0 200 OK		SIP/2.0 200 OK
	Via: SIP/2.0/UDP server19.bar.com;branch=z9hG4bKnasaii		Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaii
	;received=1.2.3.8		;received=192.0.2.7
	From: sip:joe@bar.com;tag=xyzygg		From: sip:joe@example.com;tag=xyzygg
	To: sip:joe@bar.com;tag=123aa9		To: sip:joe@example.com;tag=123aa9
	Call-ID: 9987@pc34.bar.com		Call-ID: 9987@pc34.example.com
	CSeq: 1288 NOTIFY		CSeq: 1288 NOTIFY
	The NOTIFY tells Joe that user A currently has a pending		The NOTIFY tells Joe that user A currently has a pending
	subscription. Joe then authorizes A's subscription through some		subscription. Joe then authorizes A's subscription through some
	means. This causes a change in the status of the subscription (which		means. This causes a change in the status of the subscription (which
	moves from pending to active), and the delivery of another		moves from pending to active), and the delivery of another
	notification:		notification:
	NOTIFY sip:joe@pc34.bar.com SIP/2.0		NOTIFY sip:joe@pc34.example.com SIP/2.0
	Via: SIP/2.0/UDP server19.bar.com;branch=z9hG4bKnasaij		Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaij
	From: sip:joe@bar.com;tag=xyzygg		From: sip:joe@example.com;tag=xyzygg
	To: sip:joe@bar.com;tag=123aa9		To: sip:joe@example.com;tag=123aa9
	Call-ID: 9987@pc34.bar.com		Call-ID: 9987@pc34.example.com
	CSeq: 1289 NOTIFY		CSeq: 1289 NOTIFY
	Contact: sip:server19.bar.com		Contact: sip:server19.example.com
	Event: presence.winfo		Event: presence.winfo
	Max-Forwards: 70		Max-Forwards: 70
	Content-Type: application/watcherinfo+xml		Content-Type: application/watcherinfo+xml
	Content-Length: ...		Content-Length: ...
	<?xml version="1.0"?>		<?xml version="1.0"?>
	<watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"		<watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"
	version="1" state="partial">		version="1" state="partial">
	<watcher-list resource="sip:joe@bar.com" package="presence">		<watcher-list resource="sip:joe@example.com" package="presence">
	<watcher id="77ajsyy76" event="approved"		<watcher id="77ajsyy76" event="approved"
	status="active">sip:A@example.com</watcher>		status="active">sip:A@example.com</watcher>
	</watcher-list>		</watcher-list>
	</watcherinfo>		</watcherinfo>
	B then responds with a 200 OK to the NOTIFY:		B then responds with a 200 OK to the NOTIFY:
	SIP/2.0 200 OK		SIP/2.0 200 OK
	Via: SIP/2.0/UDP server19.bar.com;branch=z9hG4bKnasaij		Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaij
	;received=1.2.3.8		;received=192.0.2.7
	From: sip:joe@bar.com;tag=xyzygg		From: sip:joe@example.com;tag=xyzygg
	To: sip:joe@bar.com;tag=123aa9		To: sip:joe@example.com;tag=123aa9
	Call-ID: 9987@pc34.bar.com		Call-ID: 9987@pc34.example.com
	CSeq: 1289 NOTIFY		CSeq: 1289 NOTIFY
	6 Security Considerations		6 Security Considerations
	6.1 Denial of Service Attacks		6.1 Denial of Service Attacks
	Watcher information generates notifications about changes in the		Watcher information generates notifications about changes in the
	state of watchers for a particular resource. It is possible for a		state of watchers for a particular resource. It is possible for a
	single resource to have many watchers, resulting in the possibility		single resource to have many watchers, resulting in the possibility
	of a large volume of notifications. This makes watcherinfo		of a large volume of notifications. This makes watcherinfo
	skipping to change at page 17, line 33 ¶		skipping to change at page 17, line 33 ¶
	Watcher information indicates what users are interested in a		Watcher information indicates what users are interested in a
	particular resource. Depending on the package and the resource, this		particular resource. Depending on the package and the resource, this
	can be very sensitive information. For example, in the case of		can be very sensitive information. For example, in the case of
	presence, the watcher information for some user represents the		presence, the watcher information for some user represents the
	friends, family, and business relations of that person. This		friends, family, and business relations of that person. This
	information can be used for a variety of malicious purposes.		information can be used for a variety of malicious purposes.
	One way in which this information can be revealed is eavesdropping.		One way in which this information can be revealed is eavesdropping.
	An attacker can observe watcherinfo notifications, and learn this		An attacker can observe watcherinfo notifications, and learn this
	information. To prevent that, the notifications can be encrypted		information. To prevent that, watchers MAY use the SIPS scheme when
	using SIPs S/MIME feature. Another way in which this information can		subscribing to a watcherinfo resource. Notifiers for watcherinfo MUST
	be revealed is through spoofed subscriptions. These attacks can be		support TLS and SIPS as if they were a proxy (see Section 26.3.1 of
	prevented by authenticating and authorizing all watcherinfo		RFC 3261).
	subscriptions.
			SIP encryption, using S/MIME, MAY be used end-to-end for the
			transmission of both SUBSCRIBE and NOTIFY requests.
			Another way in which this information can be revealed is through
			spoofed subscriptions. These attacks can be prevented by
			authenticating and authorizing all watcherinfo subscriptions. In
			order for the notifier to authenticate the subscriber, it MAY use
			HTTP Digest (Section 22 of RFC 3261). As a result, all watchers MUST
			support HTTP Digest. This is a redundant requirement, however, since
			all SIP user agents are mandated to support it by RFC 3261.
	7 IANA Considerations		7 IANA Considerations
	This specification registers an event template package as specified		This specification registers an event template package as specified
	in Section 6.2 of RFC 3265 [1].		in Section 6.2 of RFC 3265 [1].
	Package Name: winfo		Package Name: winfo
	Template Package: yes		Template Package: yes
	skipping to change at page 18, line 24 ¶		skipping to change at page 18, line 34 ¶
	72 Eagle Rock Avenue		72 Eagle Rock Avenue
	First Floor		First Floor
	East Hanover, NJ 07936		East Hanover, NJ 07936
	email: jdrosen@dynamicsoft.com		email: jdrosen@dynamicsoft.com
	10 Normative References		10 Normative References
	[1] A. B. Roach, "Session initiation protocol (sip)-specific event		[1] A. B. Roach, "Session initiation protocol (sip)-specific event
	notification," RFC 3265, Internet Engineering Task Force, June 2002.		notification," RFC 3265, Internet Engineering Task Force, June 2002.
	[2] S. Bradner, "Key words for use in RFCs to indicate requirement		[2] S. Bradner, "Key words for use in rfcs to indicate requirement
	levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.		levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.
	[3] J. Rosenberg, "An extensible markup language (XML) based format		[3] J. Rosenberg, "An extensible markup language (XML) based format
	for watcher information," Internet Draft, Internet Engineering Task		for watcher information," internet draft, Internet Engineering Task
	Force, May 2002. Work in progress.		Force, Dec. 2002. Work in progress.
	[4] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.		[4] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J.
	Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session		Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session
	initiation protocol," RFC 3261, Internet Engineering Task Force, June		initiation protocol," RFC 3261, Internet Engineering Task Force, June
	2002.		2002.
	11 Informative References		11 Informative References
	[5] J. Rosenberg, "Session initiation protocol (SIP) extensions for		[5] J. Rosenberg, "A presence event package for the session
	presence," Internet Draft, Internet Engineering Task Force, May 2002.		initiation protocol (SIP)," internet draft, Internet Engineering Task
	Work in progress.		Force, Dec. 2002. Work in progress.
			Intellectual Property Statement
			The IETF takes no position regarding the validity or scope of any
			intellectual property or other rights that might be claimed to
			pertain to the implementation or use of the technology described in
			this document or the extent to which any license under such rights
			might or might not be available; neither does it represent that it
			has made any effort to identify any such rights. Information on the
			IETF's procedures with respect to rights in standards-track and
			standards-related documentation can be found in BCP-11. Copies of
			claims of rights made available for publication and any assurances of
			licenses to be made available, or the result of an attempt made to
			obtain a general license or permission for the use of such
			proprietary rights by implementors or users of this specification can
			be obtained from the IETF Secretariat.
			The IETF invites any interested party to bring to its attention any
			copyrights, patents or patent applications, or other proprietary
			rights which may cover technology that may be required to practice
			this standard. Please address the information to the IETF Executive
			Director.
	Full Copyright Statement		Full Copyright Statement
	Copyright (c) The Internet Society (2002). All Rights Reserved.		Copyright (c) The Internet Society (2003). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph are		kind, provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this		included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing		document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other		the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of		Internet organizations, except as needed for the purpose of
End of changes. 26 change blocks.
	64 lines changed or deleted		96 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/