Subject: [Simple] I-D ACTION:draft-ietf-simple-im-session-00.txt

From: [email-masked]
Date: Thu, 19 Jul 2001 07:06:35 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF.

	Title		: SIP Instant Message Sessions
	Author(s)	: B. Campbell, J. Rosenberg
	Filename	: draft-ietf-simple-im-session-00.txt
	Pages		: 12
	Date		: 18-Jul-01
	
The current specification for the SIP MESSAGE request method
indicates that SIP instant messages according to a model similar to
that of a text pager, in that each message stands alone. There is no
concept of a chat session or a text conference where there is a
stream of messages that are grouped into a session. This memo
proposes a method of describing MESSAGE sessions by treating the
message session just like any other media session described in an
SDP body in an INVITE request.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-im-session-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-simple-im-session-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-simple-im-session-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 20 Jul 2001 16:43:54 -0400

This is a great improvement to the SIMPLE stuff, because it begins
redraw the line between session initiation and media that was muddled
with the addition of MESSAGE to SIP. There clearly needs to be a way to
negotiate text messaging as one medium of a SIP call, and this provides
that.

I have a few questions/comments:

- how does one negotiate a oneway session? Presumably if alice wants 
  to receive but not sent, she can send the following in an invite:

      m=message 5060 sip sip:alice@alicepc
      a=recvonly

  but what does bob send in return? perhaps something like:

      m=message ??? sip ???
      a=sendonly

  And whatever this is, does it also work in an invite if the person
  inviting wants to be sendonly? 

  (I believe comedia used port 9 to indicate a sink. I suppose that
  could be adopted here - perhaps:

      m=message 9 sip
      a=sendonly

  but I don't find the use of the magic number 9 very appealing.)

  Similarly, what do I do to refuse the media stream?
  Do I still use port zero for this purpose, even though the port
  in this m= line is gratuitous?

- does there need to be any notion of HOLD in the sense that is
  used for voice? To go on hold, should I send a reinvite with
  c=0.0.0.0 even though the c= line is irrelevant here? Or should
  I reinvite as sendonly? (The general case of this has been
  discussed elsewhere. I favor a=sendonly as the media independent
  way to go on hold, with the c=0 being an optional step for media
  where it makes sense.)

- section 4 forbids no-SDP invites, using the excuse that the
  UAS will not know to offer the message medium. This shows a strong
  voice bias. If you don't offer media in an invite, you ought to 
  expect the UAS to offer whatever it thinks appropriate, which
  could be any medium if you haven't expressed any preference. 

  If I don't want to specify any specific media values, but I do 
  want to indicate what I might be interested in using, then
  callerprefs provides a way to do that: I can include a media=
  parameter to the Contact header in my INVITE.

- in draft-ietf-simple-im-sdp-00 there is mention of the possibility
  of other transports than sip. That is fine as far as the SDP
  syntax goes. But how would that work in practice with SIP? 
  Unlike codecs, I can't offer multiple transports with the same
  m= line. So it is difficult to see how I might negotiate which
  transport a pair of UAs might wish to use to exchange messages.

	Thanks,
	Paul Kyzivat
	Cisco Systems

---

From: Ben Campbell <[email-masked]>
Date: Thu, 26 Jul 2001 16:25:23 -0500

>   but what does bob send in return? perhaps something like:

Presumably it would be something like that. Since it is sendonly and we 
are not worrying about things like RTCP, the port and URL fields are 
meaningless.

>   but I don't find the use of the magic number 9 very appealing.)

Again, if the stream is sendonly, then I don't see that it matters what 
goes into the port and URL.

>   in this m= line is gratuitous?

That's a good question. We could do something simular by specifying a 
zero port in the URL. However, I lean towards putting zero in the port 
field, with the realization that the receiver must now pay attention to 
that field, at least to check for zeros.

>   way to go on hold, with the c=0 being an optional step for media

I think I agree with you.

>   could be any medium if you haven't expressed any preference. 

You will notice that one is in the open issue section. I waffled in both 
directions, and will be glad to accept the wg consensus.

>   transport a pair of UAs might wish to use to exchange messages.

I suppose one could offer multiple media streams, and the receiver could 
decline those it was not interested in. This could of course result in 
multiple simultaneous message sessions. I'm not sure if that is a 
problem or not.

Thanks!

Ben.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Jul 2001 15:09:00 -0400

The revisions Johnathon has proposed affect this. I will comment
on them separately. But some of the points here are still relevant
to discuss. See below.

	Paul

> are not worrying about things like RTCP, the port and URL fields are

I think it is bad to make a specification and leave things like this
undefined. It can lead to all sorts of interoperability problems. The
acceptable values should be specified. Perhaps the port field can be any
in the range 1:2^16-1, and perhaps the url should be omitted. 

> that field, at least to check for zeros.

Yep, just goes to show that something has to be said.

> multiple simultaneous message sessions. I'm not sure if that is a

Clearly this is just a special case of a broader problem in SIP.
There are lots of problems with offering multiple media sessions.
You really want to indicate they are alternatives rather than
independent sessions, and you would prefer not to have to allocate
resources for more than one.

Maybe there is no simple solution to this without SDP-ng. But I
am afraid there is going to be need for it sooner for use with
IM.

	Paul