Subject: [Simple] Message Session IDs

From: Ben Campbell <[email-masked]>
Date: Tue, 29 Oct 2002 15:18:45 -0600

You have probably noticed 2 new IDs on message sessions that hit the 
repository this morning. These drafts, while listing a small number of 
authors, are actually the result of a great deal of discussion among 
several people, including myself, Jonathan, Rohan, Jon, Robert, Dean, 
Brian, and Allison. (Please do not take this to mean that every person 
listed necessarily agree with every point in the drafts ;-) )

draft-campbell-simple-im-sessions-00 discusses the use of the SDP 
offer/answer model for initiating message sessions, without talking much 
about the message sessions themselves.

draft-campbell-simple-cpimmsg-sessions-00 proposes a message session 
transport that involves transporting messages over TCP or TLS using the 
message/cpim format. This draft depends on the signaling methods 
described in the im-sessions draft.

Neither of these drafts are complete, but we hope they can generate some 
discussion prior to the Atlanta meeting.

Thanks!

Ben.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 29 Oct 2002 16:35:56 -0500

let me add some more to what Ben has said here.

> described in the im-sessions draft.

This is the evolution of a long chain of drafts, starting with the IMTP 
proposal 
(http://www.jdrosen.net/papers/draft-rosenberg-simple-im-transport-00.txt), 
followed by the session-of-MESSAGE proposal 
(http://www.jdrosen.net/papers/draft-rosenberg-simple-message-session-00.txt).

At Yokohama, there was some support for the simple-message-session 
approach, but there were still concerns that this was not-quite-right. 
The essence of the problem is that SIP is not a session protocol. So, a 
group of folks got together, and we came to agree on some important 
points. First, SIPs strength is that it can set up all different kinds 
of sessions. There is no constraint that there be only ONE session 
transport protocol. However, we do need a baseline protocol that 
everyone agrees to implement. SIP can be used to signal something else 
if others are developed. Given that this is a baseline, the criteria we 
developed was minimalism. What is the minimal IM session transport we 
can develop which meets our requirements? Our conclusion was a 
CPIM-over-TCP approach. This is a really lightweight transport, its 
amenable to intermediaries [indeed, its intermediaries are much simpler 
than a sip proxy], and it suffers from none of the problems we had with 
trying to use SIP MESSAGE for this (congestion control, overlapping 
transactions, etc.).

As the simple-im-sessions draft discusses, there are many many benefits 
to the session model. As such, I consider it really important to FINALLY 
close on this contentious issue, and have a solution that we can start 
to deploy.

I personally hope that over the next few weeks, we can get consensus on 
these drafts as the basis for mesaging sessions. Please share your thoughts.

-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: Paul Kyzivat <[email-masked]>
Date: Tue, 29 Oct 2002 20:08:47 -0500

I forgot in prior message, so first let me say that I like the direction this is going much better than the prior attempts!

I'm having difficulty understanding the purpose of the From meta-data header. 

Section 3 says:

  "When used in an instant message session, the From and To meta-data
   headers are used to identify the session.  There is no expectation
   that these headers actually identify the participants in the session-
   -they are used only as tokens to identify the session itself."

Section 5 says: 

  "This message MUST contain a ... From meta-data header value,
   which SHOULD be used to identify the sender, but MAY be set
   to some other value for purposes of anonymity."

I figure there are a few kinds of things this header could contain:

- It could always contain the same value as the From/To
  (depending on direction of message) of the sip session that
  established the media session. 

- It could carry the URI from the a:uri line of the message sender.

- It could be the sip: or im: address of the actual message source.
  In simple cases it would be the same as the To/From address of
  the invite, but would be different when conferencing.

I can't think of any other plausible alternatives. The first two are useless redundant information that can be inferred. The last would be useful. So I will assume that is the intent even though it conflicts with section 3. Please let me know if this is a wrong assumption.

This is sensitive information that ought to have end-to-end confidentiality protection.

At the same time, this From header is a peer of the To header. The To header apparently is intended to carry the URI from the a:uri line of the SDP from the destination message. It is needed for the recipient to demux a shared connection and send the message to the proper session. Intermediaries must also do this demuxing, so they also need access to the To header. So the To header can't be confidential end-to-end.

How is confidentiality going to work so it hides the From header and not the To header?

I think these need to go into different envelopes. Why shouldn't the To go in the outer envelope?

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 29 Oct 2002 21:28:52 -0500

inline.

Paul Kyzivat wrote:
 > I forgot in prior message, so first let me say that I like the
 > direction this is going much better than the prior attempts!
 >
 > "This message MUST contain a ... From meta-data header value, which
 > SHOULD be used to identify the sender, but MAY be set to some other
 > value for purposes of anonymity."

Oops.

This was something we changed several revs in, and it looks like it 
didn't get changed everywhere. Its supposed to be the identity of the 
sender, ie., section 5 is correct.

 > - It could always contain the same value as the From/To (depending on
 > direction of message) of the sip session that established the media
 > session.
 >
 > In simple cases it would be the same as the To/From address of the
 > invite, but would be different when conferencing.

Yes. This is exactly the intent.

 >
 > I can't think of any other plausible alternatives. The first two are
 > useless redundant information that can be inferred. The last would be
 > useful. So I will assume that is the intent even though it conflicts
 > with section 3. Please let me know if this is a wrong assumption.

You are absolutely correct.

 > At the same time, this From header is a peer of the To header. The To
 > header apparently is intended to carry the URI from the a:uri line of
 > the SDP from the destination message. It is needed for the recipient
 > to demux a shared connection and send the message to the proper
 > session. Intermediaries must also do this demuxing, so they also need
 > access to the To header. So the To header can't be confidential
 > end-to-end.
 >

Hmm. Sounds reasonable. Its almost more like a request URI type of thing.

-Jonathan R.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 29 Oct 2002 22:30:09 -0600

> Hmm. Sounds reasonable. Its almost more like a request URI type of thing.

I also agree it sounds reasonable--although if we were to do that we 
might want to call it something other than To. That way, we could keep a 
more symetric use of To and From in the message/cpim headers. The main 
reason we chose To in the first place is it already existed in 
cpim-msgfmt--that is, it did not require an extension. It seems to me 
that putting an additional header in the outer envelope _does_ require 
an extension, so we might as well name it whatever we wish.

If we were to do this, does it also make sense to move MsgID to the 
outer envelope?

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 30 Oct 2002 09:08:25 -0500

> an extension, so we might as well name it whatever we wish.

Yes. I was going to complain about the name "To" in my earlier message but didn't want to appear petty. (I *am* petty, but didn't want to appear that way. :-)

I don't think "To" has the right connotation.

> If we were to do this, does it also make sense to move MsgID to the

I don't know about this. If it is only needed by the endpoints then it might as well be in the inner envelope. Protecting it should help protect against some kinds of attacks.

	Paul

---

From: Ben Campbell <[email-masked]>
Date: Wed, 30 Oct 2002 08:40:20 -0600

> Ben Campbell wrote:

[...]

> I don't know about this. If it is only needed by the endpoints then it might as well be in the inner envelope. Protecting it should help protect against some kinds of attacks.

On reflection, I agree with you. I had it in my head that an 
intermediary might use it for ordering purposes, but now that I am more 
awake I realize there is no need for that.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 02 Nov 2002 13:48:49 -0500

Agreed that msgID belongs inside the envelope. The issue, then, is what 
MIME header are we using in the outer envelope that would be used by the 
intermediary for routing? Is there an existing one that fits the job... 
suggestions anyone?

-Jonathan R.

Ben Campbell wrote:
>> I don't know about this. If it is only needed by the endpoints then it 
>> might as well be in the inner envelope. Protecting it should help 
>> protect against some kinds of attacks.
>>
> 
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>

---

From: Pekka Pessi <[email-masked]>
Date: 07 Nov 2002 15:41:08 +0200

>about the message sessions themselves.

	There are some things with SDP that might require modifications. 
	I would use the default mapping from SDP spec, according to it
	the message/cpim would be presented like m=message (port)
	(tport) cpim. I would also list the inner MIME types in fmtp or
	similar attribute line.

	So, instead of

m=message 8937 cpim/tls text/plain text/html

	I would write it like this:

m=message 8937 tls cpim
a=fmtp:cpim accept:text/plain,text/html

	As an added bonus, this would also work:

m=message 8937 tls/sctp cpim sip sipfrag
	
>message/cpim format. This draft depends on the signaling methods described
>in the im-sessions draft.

	The comedia draft does not define how the application should
	behave when a connection is closed (except with direction:both,
	which states that the endpoint SHOULD close an idle connection). 
	An explicit message like RTCP BYE might be useful here.

					Pekka