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

From: "Petri K. Koskelainen" <[email-masked]>
Date: Wed, 1 Aug 2001 14:56:27 -0400 (EDT)

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
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?

-Jonathan R.

---

From: [email-masked]
Date: Wed, 1 Aug 2001 15:22:36 -0500

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.

>-----Original Message-----
>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,
>
>
>_______________________________________________
>simple mailing list
>[email-masked]
>http://mailman.dynamicsoft.com/mailman/listinfo/simple
>

---

From: "Petri K. Koskelainen" <[email-masked]>
Date: Wed, 1 Aug 2001 18:56:40 -0400 (EDT)

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.

Petri