< draft-ietf-simple-im-00.txt		draft-ietf-simple-im-01.txt >
	Internet Engineering Task Force J. Rosenberg		Internet Engineering Task Force J. Rosenberg
	Internet-Draft D. Willis		Internet-Draft D. Willis
	Expires: October 11, 2001 R. Sparks		Expires: January 16, 2002 R. Sparks
	B. Campbell		B. Campbell
	dynamicsoft		dynamicsoft
	H. Schulzrinne		H. Schulzrinne
	J. Lennox		J. Lennox
	Columbia University		Columbia University
	C. Huitema		C. Huitema
	B. Aboba		B. Aboba
	D. Gurle		D. Gurle
	Microsoft Corporation		Microsoft Corporation
	D. Oran		D. Oran
	Cisco Systems		Cisco Systems
	April 12, 2001		July 18, 2001
	SIP Extensions for Instant Messaging		SIP Extensions for Instant Messaging
	draft-ietf-simple-im-00		draft-ietf-simple-im-01
	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		other groups may also distribute working documents as
	Internet-Drafts.		Internet-Drafts.
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	months and may be updated, replaced, or obsoleted by other documents		months and may be updated, replaced, or obsoleted by other documents
	at any time. It is inappropriate to use Internet-Drafts as reference		at any 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 October 11, 2001.		This Internet-Draft will expire on January 16, 2002.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2001). All Rights Reserved.		Copyright (C) The Internet Society (2001). All Rights Reserved.
	Abstract		Abstract
	This document defines a SIP extension (a single new method) that		This document defines a SIP extension (a single new method) that
	supports Instant Messaging (IM).		supports Instant Messaging (IM).
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Changes Introduced in draft-ietf-simple-im-00 . . . . . . 4		2. Changes Introduced in draft-ietf-simple-im-01 . . . . . . . 3
	3. Changes Introduced in draft-rosenberg-impp-im-01 . . . . . 5		3. Changes Introduced in draft-ietf-simple-im-00 . . . . . . . 4
	4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5		4. Changes Introduced in draft-rosenberg-impp-im-01 . . . . . . 4
	5. Overview of Operation . . . . . . . . . . . . . . . . . . 5		5. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
	6. The MESSAGE request . . . . . . . . . . . . . . . . . . . 6		6. Overview of Operation . . . . . . . . . . . . . . . . . . . 4
	6.1 Method Definition . . . . . . . . . . . . . . . . . . . . 6		7. The MESSAGE request . . . . . . . . . . . . . . . . . . . . 5
	6.2 UAC processing of initial MESSAGE request . . . . . . . . 8		7.1 Method Definition . . . . . . . . . . . . . . . . . . . . . 5
	6.3 Finding the next hop . . . . . . . . . . . . . . . . . . . 9		7.2 UAC processing of MESSAGE request . . . . . . . . . . . . . 7
	6.4 Proxy processing of MESSAGE requests . . . . . . . . . . . 9		7.3 Finding the next hop . . . . . . . . . . . . . . . . . . . . 8
	6.5 UAS processing of MESSAGE requests . . . . . . . . . . . . 10		7.4 Proxy processing of MESSAGE requests . . . . . . . . . . . . 8
	6.6 UAS processing of initial MESSAGE response . . . . . . . . 10		7.5 UAS processing of MESSAGE requests . . . . . . . . . . . . . 9
	6.7 Subsequent MESSAGE requests . . . . . . . . . . . . . . . 11		7.6 UAS processing of MESSAGE response . . . . . . . . . . . . . 9
	6.8 Supporting multiple message destinations . . . . . . . . . 11		8. Caller Preferences . . . . . . . . . . . . . . . . . . . . . 9
	6.9 Caller Preferences . . . . . . . . . . . . . . . . . . . . 12		9. Mapping to CPIM . . . . . . . . . . . . . . . . . . . . . . 10
	6.10 Security . . . . . . . . . . . . . . . . . . . . . . . . . 12		9.1 Mapping SIP Requests to CPIM . . . . . . . . . . . . . . . . 10
	6.10.1 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 12		9.2 Mapping CPIM Responses to SIP . . . . . . . . . . . . . . . 11
	6.10.2 Message Integrity and Authenticity . . . . . . . . . . . . 13		9.3 Mapping CPIM operations to SIP . . . . . . . . . . . . . . . 11
	6.10.3 Outbound authentication . . . . . . . . . . . . . . . . . 13		9.4 Mapping SIP responses to CPIM . . . . . . . . . . . . . . . 11
	6.10.4 Replay Prevention . . . . . . . . . . . . . . . . . . . . 14		9.5 URL Scheme Mapping . . . . . . . . . . . . . . . . . . . . . 11
	7. Congestion Control . . . . . . . . . . . . . . . . . . . . 14		10. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	8. Example Messages . . . . . . . . . . . . . . . . . . . . . 14		10.1 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 17		10.2 Outbound authentication . . . . . . . . . . . . . . . . . . 12
	9.1 Must a MESSAGE actually include a message? . . . . . . . . 17		10.3 Replay Prevention . . . . . . . . . . . . . . . . . . . . . 12
	9.2 Should support for message/cpim be mandatory in all UAs? . 18		11. Congestion Control . . . . . . . . . . . . . . . . . . . . . 13
	9.3 message/cpim and the Accept header . . . . . . . . . . . . 18		12. Example Messages . . . . . . . . . . . . . . . . . . . . . . 13
	9.4 Message Sessions . . . . . . . . . . . . . . . . . . . . . 18		13. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 14
	9.5 What would a body in a 200 OK to a MESSAGE mean? . . . . . 18		13.1 Must a MESSAGE actually include a message? . . . . . . . . . 14
	9.6 The im: URL and RFC2543 proxies and registrars . . . . . . 19		13.2 The im: URL and RFC2543 proxies and registrars . . . . . . . 15
	9.7 Providing im: URL in Contact headers . . . . . . . . . . . 19		13.3 Providing im: URL in Contact headers . . . . . . . . . . . . 15
	9.8 Congestion control . . . . . . . . . . . . . . . . . . . . 19		13.4 Congestion control . . . . . . . . . . . . . . . . . . . . . 15
	9.9 Mapping to CPIM . . . . . . . . . . . . . . . . . . . . . 19		13.5 Mapping to CPIM . . . . . . . . . . . . . . . . . . . . . . 15
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 19		14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15
	References . . . . . . . . . . . . . . . . . . . . . . . . 20		References . . . . . . . . . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . 21		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17
	A. Requirements Evaluation . . . . . . . . . . . . . . . . . 23		A. Requirements Evaluation . . . . . . . . . . . . . . . . . . 19
	Full Copyright Statement . . . . . . . . . . . . . . . . . 27		Full Copyright Statement . . . . . . . . . . . . . . . . . . 23
	1. Introduction		1. Introduction
	This document defines an extension to SIP (RFC2543 [2]) to support		This document defines an extension to SIP (RFC2543 [2]) to support
	Instant Messaging.		Instant Messaging.
	Instant messaging is defined as the exchange of content between a		Instant messaging is defined as the exchange of content between a
	set of participants in real time. Generally, the content is short		set of participants in real time. Generally, the content is short
	textual messages, although that need not be the case. Generally, the		textual messages, although that need not be the case. Generally, the
	messages that are exchanged are not stored, but this also need not		messages that are exchanged are not stored, but this also need not
	skipping to change at page 3, line 49 ¶		skipping to change at page 3, line 49 ¶
	implemented into a single client application.		implemented into a single client application.
	Along a similar vein, the mechanisms needed in an IM protocol are		Along a similar vein, the mechanisms needed in an IM protocol are
	very similar to those needed to establish an interactive session -		very similar to those needed to establish an interactive session -
	rapid delivery of small content to a user at their current location,		rapid delivery of small content to a user at their current location,
	which may, in general, be dynamically changing as the user moves.		which may, in general, be dynamically changing as the user moves.
	The similarity of needed function implies that existing solutions		The similarity of needed function implies that existing solutions
	for initiation of sessions (namely, the Session Initiation Protocol		for initiation of sessions (namely, the Session Initiation Protocol
	(SIP) [2]) is an ideal base on which to build an IM protocol.		(SIP) [2]) is an ideal base on which to build an IM protocol.
	2. Changes Introduced in draft-ietf-simple-im-00		2. Changes Introduced in draft-ietf-simple-im-01
			This version removes the idea of implicit sessions created by
			MESSAGE requests. MESSAGE requests are now completely stateless in
			themselves.
			The version also some open issues: Bodies are not allowed in
			responses; an Accept header on a 415 response includes body types
			nested inside message/cpim bodies, all IM UAs MUST be able to
			receive message/cpim.
			This draft introduces a new section for CPIM mapping. The authors
			expect this section will need further work to complete.
			3. Changes Introduced in draft-ietf-simple-im-00
	The draft name changed to reflect its status as a SIMPLE working		The draft name changed to reflect its status as a SIMPLE working
	group item. This version introduces no other changes.		group item. This version introduces no other changes.
	3. Changes Introduced in draft-rosenberg-impp-im-01		4. Changes Introduced in draft-rosenberg-impp-im-01
	This submission serves to track transition of the work on a SIP		This submission serves to track transition of the work on a SIP
	implementation of IM to the newly formed SIMPLE working group. It		implementation of IM to the newly formed SIMPLE working group. It
	endeavors to capture the progress made in IMPP since the original		endeavors to capture the progress made in IMPP since the original
	submission (in particular, including the im: URL and the		submission (in particular, including the im: URL and the
	message/cpim body) and detail a set of open issues for the SIMPLE		message/cpim body) and detail a set of open issues for the SIMPLE
	working group to address.		working group to address.
	To support those goals, a great deal of the background and		To support those goals, a great deal of the background and
	motivation material in the original text has been shortened or		motivation material in the original text has been shortened or
	removed.		removed.
	4. Terminology		5. Terminology
	Most of the terminology used here is defined in RFC2778 [4].		Most of the terminology used here is defined in RFC2778 [4].
	However, we duplicate some of the terminology from SIP in order to		However, we duplicate some of the terminology from SIP in order to
	clarify this document:		clarify this document:
	User Agent (UA): A UA is a piece of software which is capable of		User Agent (UA): A UA is a piece of software which is capable of
	initiating requests, and of responding to requests.		initiating requests, and of responding to requests.
	User Agent Server (UAS): A UAS is the component of a UA which		User Agent Server (UAS): A UAS is the component of a UA which
	receives requests, and responds to them.		receives requests, and responds to them.
	User Agent Client (UAC): A UAC is the component of a UA which sends		User Agent Client (UAC): A UAC is the component of a UA which sends
	requests, and receives responses.		requests, and receives responses.
	Registrar: A registrar is a SIP server which can receive and		Registrar: A registrar is a SIP server which can receive and
	process REGISTER requests. These requests are used to construct		process REGISTER requests. These requests are used to construct
	address bindings.		address bindings.
	5. Overview of Operation		6. Overview of Operation
	When one user wishes to send an instant message to another, the		When one user wishes to send an instant message to another, the
	sender formulates and issues a SIP request using the new MESSAGE		sender formulates and issues a SIP request using the new MESSAGE
	method defined by this document. The request URI of this request		method defined by this document. The request URI of this request
	will normally be the im: URL of the party to whom the message is		will normally be the im: URL of the party to whom the message is
	directed (see CPIM [15]), but can also be a normal SIP URL. The body		directed (see CPIM [15]), but can also be a normal SIP URL. The body
	of the request will contain the message to be delivered. This body		of the request will contain the message to be delivered. This body
	can be of any MIME type, including "message/cpim" [16].		can be of any MIME type, including "message/cpim" [16].
	The request may traverse a set of SIP proxies using a variety of		The request may traverse a set of SIP proxies using a variety of
	transport mechanism (UDP, TCP, even SCTP [5]) before reaching its		transport mechanism (UDP, TCP, even SCTP [5]) before reaching its
	destination. The destination for each hop is located using the		destination. The destination for each hop is located using the
	address resolution rules detailed in the CPIM and SIP specifications		address resolution rules detailed in the CPIM and SIP specifications
	(see Section 6 for more detail). During traversal, each proxy may		(see Section 7 for more detail). During traversal, each proxy may
	rewrite the request URI based on available routing information.		rewrite the request URI based on available routing information.
	Provisional and final responses to the request will be returned to		Provisional and final responses to the request will be returned to
	the sender as with any other SIP request. Normally, a 200 OK		the sender as with any other SIP request. Normally, a 200 OK
	response will be generated by the user agent of the request's final		response will be generated by the user agent of the request's final
	recipient. Note that this indicates that the user agent accepted the		recipient. Note that this indicates that the user agent accepted the
	message, not that the user has seen it.		message, not that the user has seen it.
	Groups of messages in a common thread may be associated by keeping		MESSAGE requests do not create any implied session. They do not in
	them in the same session as identified by the combination of the To,		themselves establish a call leg, or any concept of call state. SIP
	From and Call-ID headers. Other potential means of grouping messages		proxies may not record-route MESSAGE requests.
	are discussed below.
	It is possible that a proxy may fork a MESSAGE request based on its
	available routing mechanism. This draft proposes a mechanism that
	takes advangage of this, delivering messages in a session to
	multiple endpoints until one sends a message back. After that, all
	remaining messages in the session are delivered to the responding
	agent.
	6. The MESSAGE request		7. The MESSAGE request
	This section defines the syntax and semantics of this extension.		This section defines the syntax and semantics of this extension.
	6.1 Method Definition		7.1 Method Definition
	This specification defines a new SIP method, MESSAGE. The BNF for		This specification defines a new SIP method, MESSAGE. The BNF for
	this method is:		this method is:
	Message = "MESSAGE"		Message = "MESSAGE"
	As with all other methods, the MESSAGE method name is case		As with all other methods, the MESSAGE method name is case
	sensitive.		sensitive.
	Tables 1 and 2 extend Tables 4 and 5 of SIP by adding an additional		Tables 1 and 2 extend Tables 4 and 5 of SIP by adding an additional
	column, defining the headers that can be used in MESSAGE requests		column, defining the headers that can be used in MESSAGE requests
	and responses.		and responses.
	where enc. e-e MESSAGE		where enc. e-e MESSAGE
	__________________________________________		__________________________________________
	Accept R e o		Accept R e -
	Accept 415 e o		Accept 415 e o
	Accept-Encoding R e o		Accept-Encoding R e o
	Accept-Encoding 415 e o		Accept-Encoding 415 e o
	Accept-Language R e o		Accept-Language R e o
	Accept-Language 415 e o		Accept-Language 415 e o
	Allow 200 e o		Allow 200 e o
	Allow 405 e m		Allow 405 e m
	Authorization R e o		Authorization R e o
	Authorization r e o		Authorization r e o
	Call-ID gc n e m		Call-ID gc n e m
	Contact R e m		Contact R e -
	Contact 2xx e o		Contact 2xx e -
	Contact 3xx e o		Contact 3xx e o
	Contact 485 e o		Contact 485 e o
	Content-Encoding e e o		Content-Encoding e e o
	Content-Length e e m		Content-Length e e m
	Content-Type e e *		Content-Type e e *
	CSeq gc n e m		CSeq gc n e m
	Date g e o		Date g e o
	Encryption g n e o		Encryption g n e o
	Expires g e o		Expires g e o
	From gc n e m		From gc n e m
	skipping to change at page 7, line 10 ¶		skipping to change at page 7, line 10 ¶
	Max-Forwards R n e o		Max-Forwards R n e o
	Organization g c h o		Organization g c h o
	Table 1: Summary of header fields, A--O		Table 1: Summary of header fields, A--O
	where enc. e-e MESSAGE		where enc. e-e MESSAGE
	________________________________________________________		________________________________________________________
	Priority R c e o		Priority R c e o
	Proxy-Authenticate 407 n h o		Proxy-Authenticate 407 n h o
	Proxy-Authorization R n h o		Proxy-Authorization R n h o
	Proxy-Require R n h o		Proxy-Require R n h o
	Record-Route R h o		Record-Route R h -
	Record-Route 2xx,401,484 h o		Record-Route 2xx,401,484 h -
	Require R e o		Require R e o
	Retry-After R c e -		Retry-After R c e -
	Retry-After 404,413,480,486 c e o		Retry-After 404,413,480,486 c e o
	500,503 c e o		500,503 c e o
	600,603 c e o		600,603 c e o
	Response-Key R c e o		Response-Key R c e o
	Route R h o		Route R h o
	Server r c e o		Server r c e o
	Subject R c e o		Subject R c e o
	Timestamp g e o		Timestamp g e o
	skipping to change at page 7, line 35 ¶		skipping to change at page 7, line 35 ¶
	Via gc(2) n e m		Via gc(2) n e m
	Warning r e o		Warning r e o
	WWW-Authenticate R c e o		WWW-Authenticate R c e o
	WWW-Authenticate 401 c e o		WWW-Authenticate 401 c e o
	(1): copied with possible addition of tag		(1): copied with possible addition of tag
	(2): UAS removes first Via header field		(2): UAS removes first Via header field
	Table 2: Summary of header fields, P--Z		Table 2: Summary of header fields, P--Z
	A MESSAGE request MAY (Open Issue Section 9.1) contain a body, using		A MESSAGE request MAY (Open Issue Section 13.1) contain a body,
	the standard MIME headers to identify the content.		using the standard MIME headers to identify the content.
	Unless stated otherwise in this document, the protocol for emitting		Unless stated otherwise in this document, the protocol for emitting
	and responding to a MESSAGE request is identical to that for a BYE		and responding to a MESSAGE request is identical to that for a BYE
	request as defined in [2]. The behavior of SIP entities not		request as defined in [2]. The behavior of SIP entities not
	implementing the MESSAGE (or any other unknown) method is explicitly		implementing the MESSAGE (or any other unknown) method is explicitly
	defined in [2].		defined in [2].
	6.2 UAC processing of initial MESSAGE request		7.2 UAC processing of MESSAGE request
	A MESSAGE request MUST contain a To, From, Call-ID, CSeq, Via,		A MESSAGE request MUST contain a To, From, Call-ID, CSeq, Via, and
	Content-Length, and Contact header, formatted as specified in [2].		Content-Length, formatted as specified in [2].
	All UAs MUST be prepared to send and receive MESSAGE requests with a		All UAs MUST be prepared to send and receive MESSAGE requests with a
	body of type text/plain. All UAs wishing to provide the end to end		body of type text/plain. They MUST be prepared to receive
	security mechanisms defined in CPIM MUST be prepared to send and		message/cpim body types, and MAY choose to send message/cpim body
	receive MESSAGE requests with a body type of message/cpim. All UAs		types.
	implementing MESSAGE SHOULD provide the end to end security
	mechanisms defined in CPIM (Open Issue Section 9.2).
	MESSAGE requests MAY contain an Accept header listing the allowable
	MIME types which may be sent in the response, or in subsequent
	requests in the reverse direction. The absence of the Accept header
	implies that the only allowed MIME type is text/plain. This
	simplifies operation in small devices, such as wireless appliances,
	which will generally only have support for text, but still allows
	any other MIME type to be used if both sides support it. (Open Issue
	Section 9.3)
	A UAC MAY send a MESSAGE request within an existing SIP call,		A UAC MAY send a MESSAGE request within an existing SIP call,
	established with an INVITE. In this case, the MESSAGE request is		established with an INVITE. In this case, the MESSAGE request is
	processed identically to the INFO method [9]. The only difference is		processed identically to the INFO method [9]. The only difference is
	that a MESSAGE request is assumed to be for the purpose of instant		that a MESSAGE request is assumed to be for the purpose of instant
	messaging as part of the call, whereas INFO is less specific.		messaging as part of the call, whereas INFO is less specific.
	A UAC MAY associate sequential MESSAGEs in a common thread by		MESSAGE requests do not imply any sort of association or session on
	constructing them with common To, From, and Call-ID headers and		their own. User Agents MUST not insert contact headers into MESSAGE
	increasing CSeq values. (Open Issue Section 9.4)		requests.
	6.3 Finding the next hop		A UA SHOULD NOT attempt to associate REQUEST messages with each
			other in any way, unless those messages are part of a call leg
			established through other means.
			7.3 Finding the next hop
	The mechanism used to determine the next hop destination for a SIP		The mechanism used to determine the next hop destination for a SIP
	MESSAGE request is detailed in [15] and [2]. Briefly, for the URL		MESSAGE request is detailed in [15] and [2]. Briefly, for the URL
	im:user@host,		im:user@host,
	1. The UA makes a DNS SRV [12] query for _im._sip.host. If any RRs		1. The UA makes a DNS SRV [12] query for _im._sip.host. If any RRs
	are returned, they determine the next hop. Otherwise:		are returned, they determine the next hop. Otherwise:
	2. The UA makes a DNS SRV query for _sip.host. If any RRs are		2. The UA makes a DNS SRV query for _sip.host. If any RRs are
	returned, they determine the next hop. Otherwise:		returned, they determine the next hop. Otherwise:
	3. The UA makes a DNS A query for host. If any records are		3. The UA makes a DNS A query for host. If any records are
	returned, they determine the address of the next hop. The		returned, they determine the address of the next hop. The
	desination port is determined from the input URL (if the input		destination port is determined from the input URL (if the input
	was an im: URL, the request is sent to the default SIP port of		was an im: URL, the request is sent to the default SIP port of
	5060).		5060).
	For sip: URLs, the UA starts at step 2.		For sip: URLs, the UA starts at step 2.
	6.4 Proxy processing of MESSAGE requests		7.4 Proxy processing of MESSAGE requests
	Proxies route requests with method MESSAGE the same as they would		Proxies route requests with method MESSAGE the same as they would
	any other SIP request (proxy routing in SIP does not depend on the		any other SIP request (proxy routing in SIP does not depend on the
	method). Note that the MESSAGE request MAY fork; this allows for		method). Note that the MESSAGE request MAY fork; this allows for
	delivery of the message to several possible terminals where the user		delivery of the message to several possible terminals where the user
	might be.		might be.
			Proxies MUST NOT create call state based on MESSAGE requests alone.
			Proxies MUST NOT insert record-route headers. If a route header is
			present in the request, a proxy MUST honor it.
	If a MESSAGE request hits a proxy that uses registrations to route		If a MESSAGE request hits a proxy that uses registrations to route
	requests, but no registration exists for the target user in the		requests, but no registration exists for the target user in the
	request-URI, the request is rejected with a 404 (Not Found).		request-URI, the request is rejected with a 404 (Not Found).
	Proxies MAY have access rules which prohibit the transmission of		Proxies MAY have access rules which prohibit the transmission of
	instant messages based on certain criteria. Typically, this criteria		instant messages based on certain criteria. Typically, this criteria
	will be based on the identity of the sender of the instant messages.		will be based on the identity of the sender of the instant messages.
	Establishment of this criteria in the proxy is outside the scope of		Establishment of this criteria in the proxy is outside the scope of
	this extension. We anticipate that such access controls will often		this extension. We anticipate that such access controls will often
	be controlled through web pages accessible by users, mitigating the		be controlled through web pages accessible by users, mitigating the
	need for standardization of a protocol for defining access rules.		need for standardization of a protocol for defining access rules.
	6.5 UAS processing of MESSAGE requests		7.5 UAS processing of MESSAGE requests
	As specified in RFC 2543, if a UAS receives a request with a body of		As specified in RFC 2543, if a UAS receives a request with a body of
	type it does not understand, it MUST respond with a 415 (Unsupported		type it does not understand, it MUST respond with a 415 (Unsupported
	Media Type) containing an Accept header listing those types which		Media Type) containing an Accept header listing those types which
	are acceptable. (This brings up Open Issue Section 9.3 again)		are acceptable. This list SHOULD also include types acceptable
			nested within a message/cpim body.
	Servers MAY reject requests (using a 413 response code) that are too		Servers MAY reject requests (using a 413 response code) that are too
	long, where too long is a matter of local configuration. All servers		long, where too long is a matter of local configuration. All servers
	MUST accept requests which are up to 1184 bytes in length.		MUST accept requests which are up to 1184 bytes in length.
	1184 = minimum IPv6 guaranteed length (1280 bytes) minus UDP (8		1184 = minimum IPv6 guaranteed length (1280 bytes) minus UDP (8
	bytes) minus IPSEC (48 bytes) minus layer one encapsulation (40		bytes) minus IPSEC (48 bytes) minus layer one encapsulation (40
	bytes).		bytes).
	A UAS receiving a MESSAGE request SHOULD respond with a final		A UAS receiving a MESSAGE request SHOULD respond with a final
	response immediately. A 200 OK is sent if the request is acceptable.		response immediately. A 200 OK is sent if the request is acceptable.
	Note, however, that the UAS is not obliged to display the message to		Note, however, that the UAS is not obliged to display the message to
	the user either before or after responding with a 200 OK. A 200		the user either before or after responding with a 200 OK. A 200
	class response to a MESSAGE request MAY contain a body, but this		class response to a MESSAGE request MUST NOT contain a body.
	will often not be the case, since these responses are generated
	automatically. (Open Issue Section 9.5)
	Like any other SIP request, an IM MAY be redirected, or otherwise		Like any other SIP request, an IM MAY be redirected, or otherwise
	responded to with any SIP response code. Note that a 200 OK response		responded to with any SIP response code. Note that a 200 OK response
	to a MESSAGE request does not mean the user has read the message.		to a MESSAGE request does not mean the user has read the message.
	A UAS which is, in fact, a message relay, storing the message and		A UAS which is, in fact, a message relay, storing the message and
	forwarding it later on, or forwarding it into a non-SIP domain,		forwarding it later on, or forwarding it into a non-SIP domain,
	SHOULD return a 202 (Accepted) response indicating that the message		SHOULD return a 202 (Accepted) response indicating that the message
	was accepted, but end to end delivery has not been guaranteed.		was accepted, but end to end delivery has not been guaranteed.
	6.6 UAS processing of initial MESSAGE response		7.6 UAS processing of MESSAGE response
	A 200 OK response to an initial IM may contain Record-Route headers.
	If present, these MUST be used to construct a Route header for use
	in subsequent requests for the same call-leg (defined as the
	combination of remote address, local address, and Call-ID), using
	the process described in Section 6.29 of SIP [2] as if the request
	were INVITE. Note that per Section 6.8 the 200 OK response may not
	contain a Contact header.
	A 400 or 500 class response indicates that the message was not		A 400 or 500 class response indicates that the message was not
	delivered successfully. A 600 response means it was delivered		delivered successfully. A 600 response means it was delivered
	successfully, but refused.		successfully, but refused.
	6.7 Subsequent MESSAGE requests		A UAS MUST NOT insert a contact header into a 200 class response.
	Any subsequent MESSAGEs in a session (see Section 9.4 follow the
	path established by the Route headers computed by the UA. The CSeq
	header MUST be larger than a CSeq header used in a previous request
	for the same call leg. Is is strongly RECOMMENDED that the CSeq
	number be computed as described in Section 6.17 of SIP, using a
	clock. This allows for the CSeq to increment without requiring the
	UA to store the previous CSeq values.
	6.8 Supporting multiple message destinations
	A UAS MAY include a Contact in a 200 class response. Including a
	Contact header enables end to end messaging, which is good for
	efficiency. However, it rules out the possibility of effectively
	supporting more than one terminal which can handle IM
	simultaneously.
	This odd but seemingly innocuous requirement enables a very
	important feature. If a user is connected at several hosts, an
	initial IM will fork, and arrive at each. Each UAS responds with
	a 200 OK immediately, one of which is arbitrarily forwarded
	upstream towards the UAC. If another IM is sent for the same
	call-leg, we still wish for this IM to fork, since we still don't
	know where the user is currently residing. This information is
	known when the user sends an IM in the reverse direction. This IM
	will contain a Contact, and when it arrives at the originator of
	the initial MESSAGE, will update the Route so that now IMs are
	delivered only to that one host where the user is residing.
	A UAS constructs a set of Route headers from the Record-Route and
	Contact headers in the MESSAGE request, as per the procedure defined
	in [10].
	MESSAGE requests for an established IM session MUST contain a Tag in
	the From field. Responses to an IM SHOULD contain a tag in the To
	field. This represents a slightly different operation than for
	INVITE. When a user sends an INVITE, they will receive a 200 OK with
	a tag. Requests in the reverse direction then contain that tag, and
	that tag only, in the From field. Here, the response to IM will
	contain a tag in the To field, and a MESSAGE will contain a tag in
	the From field. However, the UA may receive MESSAGE requests with
	tags in the From field that do not match the tag in the 200 OK
	received to the initial IM. This is because only a single 200 OK is
	returned to a MESSAGE request, as opposed to multiple 200 OK for
	INVITE. Thus, the UA MUST be prepared to receive MESSAGEs with many
	different tags, each from a different PUA.
	A UAS MUST be prepared to update the Route is has stored for an IM
	session with a Contact received in a request, if that Contact is
	different from one previously received, or if there was no Contact
	previously.
	6.9 Caller Preferences		8. Caller Preferences
	User agents SHOULD add the "methods" tag defined in the caller		User agents SHOULD add the "methods" tag defined in the caller
	preference specification [8] to Contact headers with SIP URLs placed		preference specification [8] to Contact headers with SIP URLs placed
	in REGISTER requests, indicating support for the MESSAGE method.		in REGISTER requests, indicating support for the MESSAGE method.
	Other elements of caller preferences MAY be supported. For example:		Other elements of caller preferences MAY be supported. For example:
	REGISTER sip:dynamicsoft.com SIP/2.0		REGISTER sip:dynamicsoft.com SIP/2.0
	Via: SIP/2.0/UDP mypc.dynamicsoft.com		Via: SIP/2.0/UDP mypc.dynamicsoft.com
	To: sip:jdrosen@dynamicsoft.com		To: sip:jdrosen@dynamicsoft.com
	From: sip:jdrosen@dynamicsoft.com		From: sip:jdrosen@dynamicsoft.com
	Call-ID: asidhasd@1.2.3.4		Call-ID: asidhasd@1.2.3.4
	CSeq: 39 REGISTER		CSeq: 39 REGISTER
	Contact: sip:jdrosen@im-pc.dynamicsoft.com;methods="MESSAGE"		Contact: sip:jdrosen@im-pc.dynamicsoft.com;methods="MESSAGE"
	Content-Length: 0		Content-Length: 0
	Registrar/proxies which wish to offer IM service SHOULD implement		Registrar/proxies which wish to offer IM service SHOULD implement
	the proxy processing defined in the caller preferences specification		the proxy processing defined in the caller preferences specification
	[8].		[8].
	6.10 Security		9. Mapping to CPIM
			9.1 Mapping SIP Requests to CPIM
			The CPIM draft[15] describes an abstract set of Instant Messaging
			operations that all instant messaging services must map to to insure
			interoperability. This section describes the mapping between SIP
			instant messaging and CPIM.
			The SIP MESSAGE request maps to the CPIM message operation, which
			requires the parameters of source, destination, transID, and the
			message to be sent.
			The From header maps to the source parameter, in the case of
			unauthenticated MESSAGE requests. However, a CPIM compliant gateway
			SHOULD authenticate the message request. If the request is in fact
			authenticated, then the source parameter MUST be the authenticated
			credentials of the sender.
			The requestURI maps to the destination parameter.
			The transID mapping needs further discussion (Open Issue Section
			13.5.) It must contain enough information to identify the
			transaction state at a CPIM gateway, so that the correct SIP
			response can be generated.
			The message to be sent maps to the body of the MESSAGE request. If
			the body has a MIME type of message/cpim, it SHOULD be sent as is.
			Any other mime-types MUST be embedded into a message/cpim body part.
			If a gateway UAS cannot determine the results of the message
			operation in a short time, it MUST return a 202 accepted response.
			9.2 Mapping CPIM Responses to SIP
			CPIM specifies the response types of success, failure, and
			indeterminate. A success response maps to a 200 OK message. An
			indeterminate response maps to a 202 Accepted response. The mapping
			for failure needs further discussion. (Open Issue Section 13.5)
			9.3 Mapping CPIM operations to SIP
			When a gateway maps a CPIM message operation to SIP, it MUST
			generate a MESSAGE request. The request URI and the To header MUST
			both contain the URL from the CPIM destination parameter. The From
			header SHOULD contain the URL from the source parameter. The message
			MUST copied into the body unchanged. Otherwise, the MESSAGE request
			is generated using normal SIP. The gateway UAC MUST keep enough
			transaction state to be able to determine the transID from the SIP
			response.
			9.4 Mapping SIP responses to CPIM
			Then the gateway UAC receives a response to a MESSAGE request, it
			determines the CPIM response according to the following rules: A 202
			response maps to "undetermined." Any other 200 class response maps
			to "success." Any 400, 500, and 600 class response maps to
			"failure". 100 class responses MUST be consumed by the gateway UAC.
			300 class responses SHOULD be acted upon by the gateway UAC
			according to normal SIP rules.
			9.5 URL Scheme Mapping
			Mapping of URLs between URL schemes needs further discussion.(Open
			Issue Section 13.5) This is likely to be controlled by local policy
			at least to some degree.
			10. Security
	End-to-end security concerns for instant messaging were a primary		End-to-end security concerns for instant messaging were a primary
	driving force behind the creation of message/cpim [16]. Applications		driving force behind the creation of message/cpim [16]. Applications
	needing end-to-end security should study that work carefully.		needing end-to-end security should study that work carefully.
	SIP provides numerous security mechanisms which can be utilized in		SIP provides numerous security mechanisms which can be utilized in
	addition to those made available through the use of message/cpim.		addition to those made available through the use of message/cpim.
	6.10.1 Privacy		10.1 Privacy
	In order to enhance privacy of instant messages, it is RECOMMENDED		In order to enhance privacy of instant messages, it is RECOMMENDED
	that between network servers (proxies to proxies, proxies to		that between network servers (proxies to proxies, proxies to
	redirect servers), transport mode ESP [6] or TLS is used to encrypt		redirect servers), transport mode ESP [6] or TLS is used to encrypt
	all traffic. Coupled with persistent connections, this makes it		all traffic. Coupled with persistent connections, this makes it
	impossible for eavesdroppers on non-UA connections to determine when		impossible for eavesdroppers on non-UA connections to determine when
	a particular user has even sent an IM, let alone what the content		a particular user has even sent an IM, let alone what the content
	is. Of course, the content of unencrypted IMs are exposed to		is. Of course, the content of unencrypted IMs are exposed to
	proxies.		proxies.
	Between a UAC and its local proxy, TLS [11] is RECOMMENDED.		Between a UAC and its local proxy, TLS [11] is RECOMMENDED.
	Similarly, TLS SHOULD be used between a proxy and the UAS receiving		Similarly, TLS SHOULD be used between a proxy and the UAS receiving
	the IM. The proxy can determine whether TLS is supported by the		the IM. The proxy can determine whether TLS is supported by the
	receiving client based on the transport parameter in the Contact		receiving client based on the transport parameter in the Contact
	header of its registration. If that registration contains the token		header of its registration. If that registration contains the token
	"tls" as transport, it implies that the UAS supports TLS. (Open		"tls" as transport, it implies that the UAS supports TLS. (Open
	issue Section 9.7)		issue Section 13.3)
	Furthermore, we allow for the Contact header in the MESSAGE request
	to contain TLS as a transport. The Contact header is used to route
	subsequent messages between a pair of entities. It defines the
	address and transport used to communicate with the user agent for
	subsequent requests in the reverse direction. If no proxies insert
	Record-Route headers, the recipient of the original IM, when it
	wishes to send an IM back, will use the Contact header, and
	establish a direct TLS connection for the remainder of the IM
	communications. If a proxy does Record-Route, the situation is
	different. When the recipient of the original IM (call this
	participant B) sends an IM back to the originator of the original IM
	(call this participant A), this will be sent to the proxy closest to
	B which inserted Record- Route. This proxy, in turn, sends the
	request to the proxy before it which Record-Routed. The first proxy
	after A which inserted Record- Route will then use TLS to contact A.
	Since we suspect that most proxies will not insert Record-Route into
	instant messages, efficient, secure, direct IM will occur
	frequently.
	If encrypted message/cpim bodies are not available, sensitive data		If encrypted message/cpim bodies are not available, sensitive data
	may be protected from being observed by intermediate proxies by		may be protected from being observed by intermediate proxies by
	using SIP encryption for the transmission of MESSAGE requests. SIP		using SIP encryption for the transmission of MESSAGE requests. SIP
	supports PGP based encryption, which does not require the		supports PGP based encryption, which does not require the
	establishment of a session key for encryption of messages within a		establishment of a session key for encryption of messages within a
	session (basically, a new session key is established for each		session (basically, a new session key is established for each
	message as part of the PGP encryption).		message as part of the PGP encryption).
	6.10.2 Message Integrity and Authenticity		10.2 Outbound authentication
	In addition to the integrity and authenticity protections offered
	through message/cpim, SIP provides PGP based authentication and
	message integrity checks (both challenge-response and normal
	signatures), as well as http basic and digest authentication.
	6.10.3 Outbound authentication
	When local proxies are used for transmission of outbound messages,		When local proxies are used for transmission of outbound messages,
	proxy authentication is RECOMMENDED. This is useful to verify the		proxy authentication is RECOMMENDED. This is useful to verify the
	identity of the originator, and prevent spoofing and spamming at the		identity of the originator, and prevent spoofing and spamming at the
	originating network.		originating network.
	6.10.4 Replay Prevention		10.3 Replay Prevention
	To prevent the replay of old SIP requests, all signed MESSAGE		To prevent the replay of old SIP requests, all signed MESSAGE
	requests and responses SHOULD contain a Date header covered by the		requests and responses SHOULD contain a Date header covered by the
	message signature. Any message with a date older than several		message signature. Any message with a date older than several
	minutes in the past, or which is more than several minutes in the		minutes in the past, or which is more than several minutes in the
	future, SHOULD be answered with a 400 (Incorrect Date or Time)		future, SHOULD be answered with a 400 (Incorrect Date or Time)
	message, unless such messages arrive repeatedly from the same		message, unless such messages arrive repeatedly from the same
	source, in which case they MAY be discarded without sending a		source, in which case they MAY be discarded without sending a
	response. Obviously, this replay attack prevention mechanism does		response. Obviously, this replay attack prevention mechanism does
	not work for devices without clocks.		not work for devices without clocks.
	Furthermore, all signed SIP MESSAGE requests MUST contain a Call-ID		Furthermore, all signed SIP MESSAGE requests MUST contain a Call-ID
	and CSeq header covered by the message signature. A user agent MAY		and CSeq header covered by the message signature. A user agent MAY
	store a list of Call-ID values, and for each, the higest CSeq seen		store a list of Call-ID values, and for each, the highest CSeq seen
	within that Call-ID. Any message that arrives for a Call-ID that		within that Call-ID. Any message that arrives for a Call-ID that
	exists, whose CSeq is lower than the highest seen so far, is		exists, whose CSeq is lower than the highest seen so far, is
	discarded.		discarded.
	Finally, challenge-response authentication MAY be used to prevent		Finally, challenge-response authentication MAY be used to prevent
	replay protection.		replay protection.
	7. Congestion Control		11. Congestion Control
	(Open Issue Section 9.8) Discussion needs to take place to populate		(Open Issue Section 13.4) Discussion needs to take place to populate
	this section.		this section.
	8. Example Messages		12. Example Messages
	An example message flow is shown in Figure 1. The message flow shows		An example message flow is shown in Figure 1. The message flow shows
	an initial IM sent from User 1 to User 2, both users in the same		an initial IM sent from User 1 to User 2, both users in the same
	domain, "domain", through a single proxy. A second IM, sent in		domain, "domain", through a single proxy.
	response, flows directly from User 2 to User 1.
	| F1 MESSAGE | |		| F1 MESSAGE | |
	|--------------------> | F2 MESSAGE |		|--------------------> | F2 MESSAGE |
	| | ----------------------->|		| | ----------------------->|
	| | |		| | |
	| | F3 200 OK |		| | F3 200 OK |
	| | <-----------------------|		| | <-----------------------|
	| F4 200 OK | |		| F4 200 OK | |
	|<-------------------- | |		|<-------------------- | |
	| | |		| | |
	| | |		| | |
	| | |		| | |
	| | F5 MESSAGE |
	| <--------------------|------------------------ |
	| | |
	| F6 200 OK | |
	| ---------------------|-----------------------> |
	| | |
	| | |
	| | |
	| | |
	| | |
	| | |
	| | |
	| | |
	| | |
	| | |
	| | |
	| | |
	| | |
	| | |
	| | |
	User 1 Proxy User 2		User 1 Proxy User 2
	Figure 1: Example Message Flow		Figure 1: Example Message Flow
	Message F1 looks like:		Message F1 looks like:
	MESSAGE im:user2@domain.com SIP/2.0		MESSAGE im:user2@domain.com SIP/2.0
	Via: SIP/2.0/UDP user1pc.domain.com		Via: SIP/2.0/UDP user1pc.domain.com
	From: im:user1@domain.com		From: im:user1@domain.com
	To: im:user2@domain.com		To: im:user2@domain.com
	Contact: sip:user1@user1pc.domain.com
	Call-ID: asd88asd77a@1.2.3.4		Call-ID: asd88asd77a@1.2.3.4
	CSeq: 1 MESSAGE		CSeq: 1 MESSAGE
	Content-Type: text/plain		Content-Type: text/plain
	Content-Length: 18		Content-Length: 18
	Watson, come here.		Watson, come here.
	User1 forwards this message to the server for domain.com (discovered		User1 forwards this message to the server for domain.com (discovered
	through the combination of SRV and A record processing described in		through the combination of SRV and A record processing described in
	Section 6.3 , using UDP. The proxy receives this request, and		Section 7.3 , using UDP. The proxy receives this request, and
	recognizes that it is the server for domain.com. It looks up user2		recognizes that it is the server for domain.com. It looks up user2
	in its database (built up through registrations), and finds a		in its database (built up through registrations), and finds a
	binding from im:user2@domain.com to sip:user2@user2pc.domain.com. It		binding from im:user2@domain.com to sip:user2@user2pc.domain.com. It
	forwards the request to user2, and does not insert a Record-Route		forwards the request to user2. The resulting message, F2, looks
	header. The resulting message, F2, looks like:		like:
	MESSAGE sip:user2@domain.com SIP/2.0		MESSAGE sip:user2@domain.com SIP/2.0
	Via: SIP/2.0/UDP proxy.domain.com		Via: SIP/2.0/UDP proxy.domain.com
	Via: SIP/2.0/UDP user1pc.domain.com		Via: SIP/2.0/UDP user1pc.domain.com
	From: im:user1@domain.com		From: im:user1@domain.com
	To: im:user2@domain.com		To: im:user2@domain.com
	Contact: sip:user1@user1pc.domain.com
	Call-ID: asd88asd77a@1.2.3.4		Call-ID: asd88asd77a@1.2.3.4
	CSeq: 1 MESSAGE		CSeq: 1 MESSAGE
	Content-Type: text/plain		Content-Type: text/plain
	Content-Length: 18		Content-Length: 18
	Watson, come here.		Watson, come here.
	The message is received by user2, displayed, and a response is		The message is received by user2, displayed, and a response is
	generated, message F3, and sent to the proxy:		generated, message F3, and sent to the proxy:
	SIP/2.0 200 OK		SIP/2.0 200 OK
	Via: SIP/2.0/UDP proxy.domain.com		Via: SIP/2.0/UDP proxy.domain.com
	Via: SIP/2.0/UDP user1pc.domain.com		Via: SIP/2.0/UDP user1pc.domain.com
	From: im:user1@domain.com		From: im:user1@domain.com
	To: im:user2@domain.com;tag=ab8asdasd9		To: im:user2@domain.com;tag=ab8asdasd9
	Contact: sip:user2@user1pc.domain.com
	Call-ID: asd88asd77a@1.2.3.4		Call-ID: asd88asd77a@1.2.3.4
	CSeq: 1 MESSAGE		CSeq: 1 MESSAGE
	Content-Length: 0		Content-Length: 0
	Note that most of the header fields are simply reflected in the		Note that most of the header fields are simply reflected in the
	response. The proxy receives this response, strips off the top Via,		response. The proxy receives this response, strips off the top Via,
	and forwards to the address in the next Via, user1pc.domain.com, the		and forwards to the address in the next Via, user1pc.domain.com, the
	result being message F4:		result being message F4:
	SIP/2.0 200 OK		SIP/2.0 200 OK
	Via: SIP/2.0/UDP user1pc.domain.com		Via: SIP/2.0/UDP user1pc.domain.com
	From: im:user1@domain.com		From: im:user1@domain.com
	To: im:user2@domain.com;tag=ab8asdasd9		To: im:user2@domain.com;tag=ab8asdasd9
	Call-ID: asd88asd77a@1.2.3.4		Call-ID: asd88asd77a@1.2.3.4
	CSeq: 1 MESSAGE		CSeq: 1 MESSAGE
	Content-Length: 0		Content-Length: 0
	Now, user2 wishes to send an IM to user1, message F5. As there are		13. Open Issues
	no Record-Routes in the original IM, it can simply send the IM
	directly to the address in the Contact header. Note how the To and
	From fields are now reversed from the response it sent in message
	F4:
	MESSAGE sip:user1@user1pc.domain.com SIP/2.0
	Via: SIP/2.0/UDP user2pc.domain.com
	To: im:user1@domain.com
	From: im:user2@domain.com;tag=ab8asdasd9
	Contact: sip:user2@user2pc.domain.com
	Call-ID: asd88asd77a@1.2.3.4
	CSeq: 1 MESSAGE
	Content-Type: multipart/signed; boundary=next;
	MDALG=SHA-1; type=application/pkcs7
	Content-Length: <however many bytes that is below>
	--next
	Content-Type: message/cpim
	From: <im:user2@domain.com>
	To: <im:user1@domain.com>
	Date: 2001-02-28T01:20:00-06:00
	Content-Type: text/plain
	My name is User2, not Watson.
	--next
	Content-Type: application/pkcs7
	(signature stuff)
	:
	--next--
	This is sent directly to user1, who responds with a 200 OK in
	message F6:
	SIP/2.0 200 OK
	Via: SIP/2.0/UDP user2pc.domain.com
	To: im:user1@domain.com;tag=2c09sj3sd9
	From: im:user2@domain.com;tag=ab8asdasd9
	Call-ID: asd88asd77a@1.2.3.4
	CSeq: 1 MESSAGE
	Content-Length: 0
	9. Open Issues
	9.1 Must a MESSAGE actually include a message?		13.1 Must a MESSAGE actually include a message?
	Section 6 specifies that a MESSAGE MAY contain a MIME body. Should		Section 7 specifies that a MESSAGE MAY contain a MIME body. Should
	this be MUST? Does it make sense to have a MESSAGE with no body?		this be MUST? Does it make sense to have a MESSAGE with no body?
	9.2 Should support for message/cpim be mandatory in all UAs?		13.2 The im: URL and RFC2543 proxies and registrars
	Section 6 requires that UAs implementing MESSAGE support text/plain
	bodies as the lowest common denominator. Should this be message/cpim
	instead? Any UA wishing to support end-end signing or encryption of
	messages passing across simple/apex/prim boundaries MUST support
	message/cpim. If, however, end-end security is not desired, clients
	and messaging can be made a little lighter by not including the
	message/cpim wrapper. An unsigned message/cpim body can be created
	from messages from those clients when crossing a boundary that
	requires one.
	9.3 message/cpim and the Accept header
	Do we need text to make it clear that a UA should indicate the mime
	types it supports _inside_ a message/cpim body as well as supporting
	message/cpim?
	9.4 Message Sessions
	Several implementations of the -00 version of this draft grouped
	messages in a common thread by placing them in a "call-leg" (common
	To, From, and Call-ID). The first message sent or received in a
	thread established the leg. This has provided enough information to
	allow user interfaces to present separate threads in separate
	dialogs. There is some concern that there is no way to formally
	terminate this "call-leg".
	The -00 version noded that there is state at the UA associated with
	this notion of session, encapsulated in the Call-ID, Route headers,
	and CSeq numbers. A UA MAY terminate this session at any time,
	including after each MESSAGE. No messaging is required to terminate
	it. Any associated state with the session is simply discarded. The
	idempotency of SIP requests will ensure that if one side (side A)
	discards session state, and the other (side B) does not, a message
	from side B will appear as a new IM, and standard processing will
	reconstitute the session on side A.
	o Should we define a way to use INVITE/BYE to surround a group of
	MESSAGE requests that are part of a logical session?
	9.5 What would a body in a 200 OK to a MESSAGE mean?
	Section 6.5 states "A 200 class response to a MESSAGE request MAY
	contain a body, but this will often not be the case, since these
	responses are generated automatically." If one were to appear, what
	would it mean?
	9.6 The im: URL and RFC2543 proxies and registrars
	What are the implications of an im: URL showing up in the request		What are the implications of an im: URL showing up in the request
	URI in a MESSAGE request received by an RFC2543 proxy, or the To:		URI in a MESSAGE request received by an RFC2543 proxy, or the To:
	header of a REGISTER request received by an RFC2543 registrar?		header of a REGISTER request received by an RFC2543 registrar?
	9.7 Providing im: URL in Contact headers		13.3 Providing im: URL in Contact headers
	What are the ramifications of a UA providing an im: URL in a		What are the ramifications of a UA providing an im: URL in a
	Contact: header for a REGISTER method, or a MESSAGE method? For the		Contact: header for a REGISTER method, or a MESSAGE method? For the
	forseeable future, most SIP endpoints aren't going to have SRV		forseeable future, most SIP endpoints aren't going to have SRV
	records of the form _im._sip.host or even _sip.host pointing to		records of the form _im._sip.host or even _sip.host pointing to
	them. Falling back to A records in that case seems to preclude the		them. Falling back to A records in that case seems to preclude the
	use of non-UDP transports.		use of non-UDP transports.
	9.8 Congestion control		13.4 Congestion control
	Per the amendments made to the SIMPLE charter by the IESG prior to		Per the amendments made to the SIMPLE charter by the IESG prior to
	approval, congestion control needs attention. In particular the		approval, congestion control needs attention. In particular the
	requirements of BCP 41 must be met by this extension. Specifying the		requirements of BCP 41 must be met by this extension. Specifying the
	use of transport protocols with congestion control built in,		use of transport protocols with congestion control built in,
	particularly with the recommendation of reuse of connections, is an		particularly with the recommendation of reuse of connections, is an
	option. The question is when can we use those that don't (UDP) and		option. The question is when can we use those that don't (UDP) and
	what needs to be done in addition to what SIP already does in that		what needs to be done in addition to what SIP already does in that
	case. Among other things, this interacts with Section 9.7		case. Among other things, this interacts with Section 13.3
	9.9 Mapping to CPIM		13.5 Mapping to CPIM
	This document needs to detail the mapping of this extension onto		This version offers a first cut at describing CPIM mapping. However,
	CPIM.		the entire subject needs further discussion. How do we map SIP
			transactions to CPIM "transID?" What is the correct SIP response
			code for a CPIM failure response? How do we handle mapping between
			URL schema at a gateway? Do we need to describe gateway timing
			issues?
	10. Acknowledgements		14. Acknowledgments
	The authors would like to thank the following people for their		The authors would like to thank the following people for their
	support of the concept of SIP for IM, support for this work, and for		support of the concept of SIP for IM, support for this work, and for
	their useful comments and insights:		their useful comments and insights:
	Jon Peterson Level(3) Communications		Jon Peterson Level(3) Communications
	Sean Olson Ericsson		Sean Olson Ericsson
	Adam Roach Ericsson		Adam Roach Ericsson
	Billy Biggs University of Waterloo		Billy Biggs University of Waterloo
	Stuart Barkley UUNet		Stuart Barkley UUNet
	skipping to change at page 20, line 18 ¶		skipping to change at page 17, line 29 ¶
	draft-ietf-impp-cpim-01 (work in progress), February 2001.		draft-ietf-impp-cpim-01 (work in progress), February 2001.
	[16] Atkins, D. and G. Klyne, "Common Presence and Instant		[16] Atkins, D. and G. Klyne, "Common Presence and Instant
	Messaging Message Format", draft-ietf-impp-cpim-msgfmt-00		Messaging Message Format", draft-ietf-impp-cpim-msgfmt-00
	(work in progress), February 2001.		(work in progress), February 2001.
	Authors' Addresses		Authors' Addresses
	Jonathan Rosenberg		Jonathan Rosenberg
	dynamicsoft		dynamicsoft
	200 Executive Drive		72 Eagle Rock Avenue
	Suite 120		First Floor
	West Orange, NJ 07052		East Hanover, NJ 07936
	email: jdrosen@dynamicsoft.com		email: jdrosen@dynamicsoft.com
	Dean Willis		Dean Willis
	dynamicsoft		dynamicsoft
	5100 Tennyson Parkway		5100 Tennyson Parkway
	Suite 1200		Suite 1200
	Plano, TX 75024		Plano, TX 75024
	email: dwillis@dynamicsoft.com		email: dwillis@dynamicsoft.com
	Robert J. Sparks		Robert J. Sparks
	dynamicsoft		dynamicsoft
	5100 Tennyson Parkway		5100 Tennyson Parkway
	Suite 1200		Suite 1200
	Plano, TX 75024		Plano, TX 75024
	email: rsparks@dynamicsoft.com		email: rsparks@dynamicsoft.com
			Ben Campbell
	Ben Cambpell
	dynamicsoft		dynamicsoft
	5100 Tennyson Parkway		5100 Tennyson Parkway
	Suite 1200		Suite 1200
	Plano, TX 75024		Plano, TX 75024
	email: bcampbell@dynamicsoft.com		email: bcampbell@dynamicsoft.com
	Henning Schulzrinne		Henning Schulzrinne
	Columbia University		Columbia University
	M/S 0401		M/S 0401
	1214 Amsterdam Ave.		1214 Amsterdam Ave.
	New York, NY 10027-7003		New York, NY 10027-7003
	email: schulzrinne@cs.columbia.edu		email: schulzrinne@cs.columbia.edu
	Jonathan Lennox		Jonathan Lennox
	Columbia University		Columbia University
End of changes. 62 change blocks.
	330 lines changed or deleted		201 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/