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

From: [email-masked]
Date: Mon, 23 Jul 2001 06:39:58 -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: "Boyer, D G (Dave)" <[email-masked]>
Date: Mon, 23 Jul 2001 10:33:36 -0400

Isn't this a two way signalling session and one way media session?
 
Dave Boyer

-----Original Message-----
From: Sean Olson (EUS) [mailto:[email-masked]]
Sent: Monday, July 23, 2001 10:29 AM
To: 'Paul Kyzivat'; [email-masked]'
Cc: [email-masked]'; '";"@cisco.com'; [email-masked]'
Subject: RE: [Simple] I-D ACTION:draft-ietf-simple-im-session-00.txt

>- 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'm curious what a one-way SIP signalling session would 
mean? You can receive an INVITE, but not send the 200 OK? 
No flame intended, I just don't understand the application 
you are thinking of. 

/sean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 30 Jul 2001 08:51:14 -0400

> From: Ben Campbell [mailto:[email-masked]]
> Sent: Sunday, July 29, 2001 11:40 PM
> To: Jonathan Rosenberg
> Cc: 'Paul Kyzivat'; [email-masked];
> [email-masked]
> Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-im-session-00.txt
> 
> 
> I agree that a URL in the c-line would be a better approach, 
> and we even 
> added it in the open issue section in the im-sdp draft.  I am 
> uncertain, 
> though, that this is permissible, as the SDP definition 
> explicitly says 
> IPv4 address (in the descriptive text section. The BNF actually says 
> (IP4|IP6)) for that field. It seems pretty clear the authors intended 
> that as a network address, not a URI. (in contrast to the m-line 
> definition, which specifically describes how to extend it.)

There is already an RFC extension to SIP that defines a new address family.
RFC 3108 (Conventions for the use of the Session Description Protocol (SDP)
for ATM Bearer Connections) defines "ATM" as a new address type. So, we are
following an existing practice.

> 
> So, if we do that, is it still SDP? Can we make that change without 
> updating the SDP RFC? I can see extended it to other network address 
> types, but extending to URIs seems like a change in philosophy.

Whether its a change in philosophy is indeed a good question (I don't think
so, but its worth getting input from Mark and co.), but apparently its
allowed to define new address types.

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 30 Jul 2001 09:28:16 -0400

> From: Vasilis Polychronidis 
> [mailto:[email-masked]]
> Sent: Monday, July 30, 2001 5:56 AM
> To: Jonathan Rosenberg
> Cc: 'Paul Kyzivat'; [email-masked]
> Jonathan Rosenberg wrote:
> 
> > Paul,
> >
> > Some excellent questions. I believe that, in general, until 
> we are at the
> > point where the answer is "you do X the same way for 
> messaging as for
> > voice", we still have more work to do.
> >
> > So, I had thought about the SDP usage some more since the draft was
> > released, and think I may have an even better way. Really, the URL
> > represents an address, and so it belongs in a c line. Its 
> not of type IP4,
> > but rather a new address space, of type URL. In that case, 
> the SDP might
> > look like:
> >
> > m=message 5060 sip message/cpim text/plain text/html
> > c=IN URL sip:[email-masked]
> >
> > This indicates that the media type message can be received 
> at the URL
> > address sip:[email-masked], and that the transport is 
> sip, with allowed
> > formats message/cpim, text/plain and text/html. I think 
> this is pretty
> > consistent with the meaning of these paramteres in SDP, and 
> it even allows
> > us to apply SDP negotiation to the selection of message 
> content types.
> >
> > So, based on that:
> >
> > 1. to disable a stream, the port is set to zero, as it is 
> for all media
> > types
> > 2. to hold a stream, you can set the address in the c line to IN IP4
> > 0.0.0.0, but the preferred means is a=sendonly, as it is 
> for other media
> > types.
> > 3. oneway sessions use a=recvonly or a=sendonly as for 
> other media types
> > 4. it becomes clear on how other transports might work. For 
> example, to use
> > "foo" as an alternate transport:
> >
> > m=message 334 foo message/cpim text/plain text/html
> > c=IN URL foo:[email-masked]
> >
> > very simple.
> >
> > I prefer this approach to what is currently documented in
> > draft-ietf-simple-im-sdp.
> >
> > Comments?
> 
> I like it too it is closer to the VoIP model.
> One small question:
> In your above example (SDP) how do you distinguish
> between sip/tcp or sip/udp?
> or more general foo/tcp, foo/udp, foo/sctp, etc. ?

Same way done for other things:

m=message 334 foo/TCP message/cpim text/plain text/html
c=IN URL foo:[email-masked]

This is consistent with draft-ietf-mmusic-comedia, for example.

-Jonathan R.
---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 5 Aug 2001 18:06:28 -0400

> From: Petri K. Koskelainen [mailto:[email-masked]]
> Sent: Wednesday, August 01, 2001 6:57 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> I agree that it make no sense to limit the scheme
> to one method only.
> However, this is the case with the current draft.
> It is specifically meant for MESSAGE method
> (of course applying it to other methods is possible).
> 
> MESSAGE method should be the default method unless
> otherwise specified.
> It sounds a bit clumsy to set up an appliance control
> (or whatever) session and get 501 inside a session. 
> This should work just like voice session setup
> in which you agree on codecs and codec options beforehand
> in SIP signaling.

I think MESSAGE is implied by the fact that the media type is message. I
agree with Sean that setting up method-specific sessions makes little sense.

-Jonathan R.

---

> 
> 
> 
> Petri
> 
> 
> 
> > 
> > I don't see this as a real problem.
> > The IM session should really be a
> > SIP signalling session. If you 
> > don't support a request that you
> > receive within this signalling 
> > session, return a 501. Limiting
> > this SIP signalling session to
> > just a single method doesn't buy
> > you anything.
> > 
> > Regards,
> > Sean Olson
> > Ericsson Inc.
> > 
> > >From: Petri K. Koskelainen [mailto:[email-masked]]
> > >Sent: Wednesday, August 01, 2001 1:56 PM
> > >To: [email-masked]
> > >Subject: [Simple] I-D ACTION:draft-ietf-simple-im-session-00.txt
> > >
> > >
> > >
> > >Hi,
> > >
> > >
> > >The use of this scheme for non-MESSAGE sessions is still
> > >somewhat unclear..
> > >
> > >There seems to be several ways to define it,
> > >for example:
> > >
> > >1: Method name in SIP URL in c line, like
> > >c=IN URL sip:[email-masked];method=DO.
> > >However, this seems to be partly conflicting with
> > >the idea that only the address is in c line.
> > >
> > >2: New media type for new SIP methods,
> > >such as "appliance" or "control" for DO, like: 
> > >m=appliance 5061 sip text/plain application/dmp
> > >However, this scheme requires new media type
> > >for each new method (I can establish a foobar media
> > >session using SIP FOOBAR method..)
> > >
> > >3: Put SIP method name somewhere else in SDP.
> > >For example, 
> > >m=message 5061 sip DO application/dmp
> > >
> > >4: Method name is defined in SIP To header.
> > >
> > >
> > >Option 3 seems to be the most logical way..
> > >
> > >
> > >--
> > >Petri
> > >
> > >
> > >-------------------------------------
> > >
> > >
> > >
> > >Paul,
> > >
> > >Some excellent questions. I believe that, in general, until we 
> > >are at the
> > >represents an address, and so it belongs in a c line. Its not 
> > >of type IP4,
> > >but rather a new address space, of type URL. In that case, the 
> > >SDP might
> > >look like:
> > >
> > >address sip:[email-masked], and that the transport is sip, 
> > >with allowed
> > >consistent with the meaning of these paramteres in SDP, and it 
> > >even allows
> > >0.0.0.0, but the preferred means is a=sendonly, as it is for 
> > >other media
> > >types.
> > >3. oneway sessions use a=recvonly or a=sendonly as for other 
> > >media types
> > >_______________________________________________
> > >simple mailing list
> > >http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > >
> > 
> 
> _______________________________________________
> simple mailing list
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>