Subject: RE: [Simple] Implicit MESSAGE sessions revisited

From: "Patil Basavaraj (NET/Dallas)" <[email-masked]>
Date: Fri, 14 Sep 2001 13:37:06 -0500

> 
> While BEEP is a useful protocol, I fail to see what 
> advantages it offers
> compared to "smaller" solutions that don't require as much additional
> infrastructure and end system complexity.
>

Do we really need yet another (AL) protocol is what I had in mind.
Whether
BEEP has advantages should be evaluated against whether BEEP can
satisfy the requirements for IM sessions. 

-Reuse Vs Reinventing something else. The problem with the reinvention
is that by the time the "smaller" solution has addressed all the
requirements
and concerns, it ends up looking something that already exists and the
argument of simplicity is gone.

-Reuse of BEEP also means getting the IM for sessions spec/solution done

faster. If the IM for Sessions spec focused on getting the signaling
part done
and not have to worry about how to transport the data, that would
simplify the
spec and 

> "Patil Basavaraj (NET/Dallas)" wrote:
> > 
> > One of the protocols that has been suggested for use instead of
> > MESSAGE is BEEP. Are there any serious concerns *at this time*
> > why BEEP would not be good eniugh for IM Sessions?
> > 
> > -Basavaraj
> >
>

---

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Mon, 17 Sep 2001 13:31:03 -0400

[DW] I'm proposing providing
the concept of a "session" as a sequence of messages, with that sequence
association being indicated at the application rather than transport layer.

For example, the message body itself might contain a session identifier and
a sequence number.

This would allow the receiving client to render messages into appropriate
windows in an appropriate order, as appropriate to the implementation,
without the transport layer being aware of that behavior.

[RRR] I guess that it is quite possible. One of the possible suggestions to
achieve the objectives:

1. Establish the MESSAGE session as another media. This session ID will
serve as the global identifier.

2. Let this media to have multiple sequence of messages as a part of the
MESSAGE session (as if, videos within a video). 
These sequences of messages will serve as the sub-IDs of the global
identifier of item 1.

Radhika R. Roy
[email-masked]

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 17 Sep 2001 11:51:59 -0700

Since the use of BEEP is minuscule so far, the reuse argument is pretty
weak. I would much rather reuse Message, and if not that, then SOAP.

-- Christian Huitema

> -----Original Message-----
> From: Patil Basavaraj (NET/Dallas) [mailto:[email-masked]]
> Sent: Friday, September 14, 2001 11:37 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [Simple] Implicit MESSAGE sessions revisited
> 
> 
> >
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: "Robert Brown" <[email-masked]>
Date: Tue, 18 Sep 2001 18:25:22 -0700

I'm not convinced that the "Ann" example is legitimate.  This just
sounds like a poor UI design.

-----Original Message-----
From: Mark Watson [mailto:[email-masked]] 
Sent: Tuesday, September 18, 2001 10:59 AM
To: 'Dean Willis'; simple
Subject: RE: [Simple] Implicit MESSAGE sessions revisited

(1), it's not just a question of optimising the message routing, it's
also that in routing the initial INVITE I may use up certain resources
or require user intervention, and I don't want to repeat all that for
every message in the 'chat session'.

For example, Ann has all incoming sessions presented to their SIP client
but can hit a key to forward them to her assistant Bob. If it's an IM
chat session, and Bob gets into a long conversation, Ann does not want
to see every message, and have to hit a key to forward it.

Anns client could forward 'subsequent' messages automatically, but then
Ann's client is implicitly taking on a notion of a 'session' and we are
into the implicit session setup debate again - how does it detect when
this session has ended and a new one started ? What happens if Ann turns
her client off before Bob has finished chatting ? Ann could instruct her
proxy to forwared SIP requests to Bob, but perhaps she doesn't want to.
Perhaps she wants new calls to go to her mobile, but the rest of Bob's
chat session to continue unaffected.

So it's not just a message routing optimisation, there are other
resources being optimised too (Ann's time).

(2) SIP messages are not media, sure, but Instant Messages are. Instant
Messages are not 'user to user signalling' either, because they are not
signalling - they are a communication between the human end-users, not
between the equipment facilitating that communication (which is how I
would characterise 'signalling' here). So perhaps SIP messages should
not be used to carry Instant Messages - but this is a different point
entirely.

...Mark

	-----Original Message-----
	From: Dean Willis [mailto:[email-masked]]
	Sent: 18 September 2001 15:46
	To: simple
	Subject: Re: [Simple] Implicit MESSAGE sessions revisited

	I agree with #1,sortof. The best (only?) justfication for
INVITE-bounded message sessions is the use of Record-Route to allow
proxies that don't need to be in the route to opt out. This allows the
SIP-network to be "self optimizing" for message routing. However, such
SIP paths may be necessarily NOT end-to-end. For example, putting a SIP
UA behind a firewall proxy will require that messages transit the
firewall proxy. This is easily accomplished with record-route. Remember,
all the "signaling privacy" requirements like  calling-party-ID and
address-hiding apply to SIP messages. We already have mechanisms to meet
those requirements for SIP traffic -- reusing them for messages is
obviously functional.

	I disagree with requirement #2 -- SIP messages are inherently
NOT media. They are, in effect "user to user signaling". This is
consistent with my earlier position on the use of phone input (DTMF) as
"user to system signaling", not media.

	--
	Dean

		----- Original Message ----- 

		From: Mark Watson <mailto:[email-masked]>  

		To: 'Dean Willis' <mailto:[email-masked]>  ;
Patil Basavaraj (NET/Dallas) <mailto:[email-masked]>  ; 'ext
Ben Campbell' <mailto:[email-masked]>  

		Cc: simple <mailto:[email-masked]>  

		Sent: Monday, September 17, 2001 12:02 PM

		Subject: RE: [Simple] Implicit MESSAGE sessions
revisited

		Dean,

		I agree that they're independent. On the first one, I
had thought that the idea of IM 'sessions' fulfilled two key
requirements:

		1) I want to find my desired called party, and then
exchange multiple messages with this person

		Some of these things which can happen (in the
network/UEs) as a SIP message finds the desired end-user may take
time/cost money/require user interaction, and I don't want to repeat
them once I have found the person I want to chat to. Also, there is no
guarantee that repeating the process at a later time will get me to the
same end-user. So, I want to be able to do a 'session setup' and then
send messages directly to the person I've found.

		Of course, I could just treat the first message as an
implicit session setup, but this seems to be out of fashion.

		2) I want IM to be just another media that I can
negotiate, add & remove from a session etc.

		Again, I could do something clever with Call IDs to
connect a MESSAGE message with a pre-existing session etc. etc., but why
should I make an exception for this one kind of media. If I do that,
then no capabilities that I have now or invent in the future which are
supposed to be 'media type independent', will work for IM, and I will
have to be hacking the IM system constantly to keep up.

		Did you disagree with these requirements, or just with
the implementation ?

		Regards...Mark

			-----Original Message-----
			From: Dean Willis
[mailto:[email-masked]]
			Sent: 17 September 2001 17:32
			To: Watson, Mark [MAIFP:EP11:EXCH]; Patil
Basavaraj (NET/Dallas); 'ext Ben Campbell'
			Cc: simple
			Subject: Re: [Simple] Implicit MESSAGE sessions
revisited

			Both, actually. I believe the issues are
independent.

			--
			Dean

				----- Original Message ----- 

				From: Mark Watson
<mailto:[email-masked]>  

				To: 'Dean Willis'
<mailto:[email-masked]>  ; Patil Basavaraj (NET/Dallas)
<mailto:[email-masked]>  ; 'ext Ben Campbell'
<mailto:[email-masked]>  

				Cc: simple
<mailto:[email-masked]>  

				Sent: Monday, September 17, 2001 9:39 AM

				Subject: RE: [Simple] Implicit MESSAGE
sessions revisited

				Dean, 

				Do you mean that you don't see the
advantage of using INVITE to set up an IM 'session' (indicating this in
the SDP), or just that once such a session is set up, there is no need
for the 'media' to use any different protocol than that used for
'paging' ?

				I think there are a lot of reasons why
IM 'sessions' set up using INVITE just like any other SIP session, make
sense. I don't care much yet what the transport protocol then is for the
IMs in the session.

				Sorry if this is covering old ground. 

				...Mark 

				> From: Dean Willis
[mailto:[email-masked]] 
				> Sent: 15 September 2001 05:31 
				> To: Patil Basavaraj (NET/Dallas); 'ext
Ben Campbell' 
				> Cc: simple 
				> Subject: Re: [Simple] Implicit MESSAGE
sessions revisited 
				> 
				> 
				> 
				> Just as MESSAGE for sessions has all
the wasted overhead of 
				> headers and 
				> routing mechanisms designed to find
users and traverse 
				> firewalls (assuming 
				> you think this is a waste), so does
BEEP. 
				> 
				> I personally have yet to see the need
for message sessions as 
				> a specialized 
				> transport. 
				> 
				> I think "pager" messages carrying a
session-ID and sequence number can 
				> provide the same user experience. 
				> 
				> -- 
				> dean 
				> 
				> 
				> ----- Original Message ----- 
				> From: "Patil Basavaraj (NET/Dallas)"
<[email-masked]> 
				> To: "'ext Ben Campbell'"
<[email-masked]> 
				> Cc: <[email-masked]> 
				> Sent: Friday, September 14, 2001 1:07
PM

---

From: "Mark Watson" <[email-masked]>
Date: Wed, 19 Sep 2001 10:01:24 +0100

Can you explain - I would have thought that allowing a user to screen
incoming sessions and decide on their disposition without answering the
session would be a common requirement. I don't understand how you could
avoid the problem below just by changing the UI.
 
...Mark

-----Original Message-----
From: Robert Brown [mailto:[email-masked]]
Sent: 19 September 2001 02:25
To: Watson, Mark [MAIFP:EP11:EXCH]; Dean Willis; simple
Subject: RE: [Simple] Implicit MESSAGE sessions revisited

I'm not convinced that the "Ann" example is legitimate.  This just sounds
like a poor UI design.

-----Original Message-----
From: Mark Watson [mailto:[email-masked]] 
Sent: Tuesday, September 18, 2001 10:59 AM
To: 'Dean Willis'; simple
Subject: RE: [Simple] Implicit MESSAGE sessions revisited

(1), it's not just a question of optimising the message routing, it's also
that in routing the initial INVITE I may use up certain resources or require
user intervention, and I don't want to repeat all that for every message in
the 'chat session'.

For example, Ann has all incoming sessions presented to their SIP client but
can hit a key to forward them to her assistant Bob. If it's an IM chat
session, and Bob gets into a long conversation, Ann does not want to see
every message, and have to hit a key to forward it.

Anns client could forward 'subsequent' messages automatically, but then
Ann's client is implicitly taking on a notion of a 'session' and we are into
the implicit session setup debate again - how does it detect when this
session has ended and a new one started ? What happens if Ann turns her
client off before Bob has finished chatting ? Ann could instruct her proxy
to forwared SIP requests to Bob, but perhaps she doesn't want to. Perhaps
she wants new calls to go to her mobile, but the rest of Bob's chat session
to continue unaffected.

So it's not just a message routing optimisation, there are other resources
being optimised too (Ann's time).

(2) SIP messages are not media, sure, but Instant Messages are. Instant
Messages are not 'user to user signalling' either, because they are not
signalling - they are a communication between the human end-users, not
between the equipment facilitating that communication (which is how I would
characterise 'signalling' here). So perhaps SIP messages should not be used
to carry Instant Messages - but this is a different point entirely.

...Mark

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: 18 September 2001 15:46
To: simple
Subject: Re: [Simple] Implicit MESSAGE sessions revisited

I agree with #1,sortof. The best (only?) justfication for INVITE-bounded
message sessions is the use of Record-Route to allow proxies that don't need
to be in the route to opt out. This allows the SIP-network to be "self
optimizing" for message routing. However, such SIP paths may be necessarily
NOT end-to-end. For example, putting a SIP UA behind a firewall proxy will
require that messages transit the firewall proxy. This is easily
accomplished with record-route. Remember, all the "signaling privacy"
requirements like  calling-party-ID and address-hiding apply to SIP
messages. We already have mechanisms to meet those requirements for SIP
traffic -- reusing them for messages is obviously functional.

I disagree with requirement #2 -- SIP messages are inherently NOT media.
They are, in effect "user to user signaling". This is consistent with my
earlier position on the use of phone input (DTMF) as "user to system
signaling", not media.

--
Dean

----- Original Message ----- 

To: 'Dean Willis' <mailto:[email-masked]>  ; Patil Basavaraj
(NET/Dallas) <mailto:[email-masked]>  ; 'ext Ben Campbell'
<mailto:[email-masked]>  

Dean,

I agree that they're independent. On the first one, I had thought that the
idea of IM 'sessions' fulfilled two key requirements:

1) I want to find my desired called party, and then exchange multiple
messages with this person

Some of these things which can happen (in the network/UEs) as a SIP message
finds the desired end-user may take time/cost money/require user
interaction, and I don't want to repeat them once I have found the person I
want to chat to. Also, there is no guarantee that repeating the process at a
later time will get me to the same end-user. So, I want to be able to do a
'session setup' and then send messages directly to the person I've found.

Of course, I could just treat the first message as an implicit session
setup, but this seems to be out of fashion.

2) I want IM to be just another media that I can negotiate, add & remove
from a session etc.

Again, I could do something clever with Call IDs to connect a MESSAGE
message with a pre-existing session etc. etc., but why should I make an
exception for this one kind of media. If I do that, then no capabilities
that I have now or invent in the future which are supposed to be 'media type
independent', will work for IM, and I will have to be hacking the IM system
constantly to keep up.

Did you disagree with these requirements, or just with the implementation ?

Regards...Mark

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: 17 September 2001 17:32
To: Watson, Mark [MAIFP:EP11:EXCH]; Patil Basavaraj (NET/Dallas); 'ext Ben
Campbell'
Cc: simple

Both, actually. I believe the issues are independent.

--
Dean

----- Original Message ----- 

To: 'Dean Willis' <mailto:[email-masked]>  ; Patil Basavaraj
(NET/Dallas) <mailto:[email-masked]>  ; 'ext Ben Campbell'
<mailto:[email-masked]>  

Dean, 

Do you mean that you don't see the advantage of using INVITE to set up an IM
'session' (indicating this in the SDP), or just that once such a session is
set up, there is no need for the 'media' to use any different protocol than
that used for 'paging' ?

I think there are a lot of reasons why IM 'sessions' set up using INVITE
just like any other SIP session, make sense. I don't care much yet what the
transport protocol then is for the IMs in the session.

...Mark 

> From: Dean Willis [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> To: Patil Basavaraj (NET/Dallas); 'ext Ben Campbell' 
> Cc: simple 
> Just as MESSAGE for sessions has all the wasted overhead of 
> headers and 
> routing mechanisms designed to find users and traverse 
> firewalls (assuming 
> you think this is a waste), so does BEEP. 
> 
> I personally have yet to see the need for message sessions as 
> a specialized 
> transport. 
> 
> I think "pager" messages carrying a session-ID and sequence number can 
> From: "Patil Basavaraj (NET/Dallas)" <[email-masked]> 
> To: "'ext Ben Campbell'" <[email-masked]> 
> Sent: Friday, September 14, 2001 1:07 PM 
<http://mailman.dynamicsoft.com/mailman/listinfo/simple>  
<http://mailman.dynamicsoft.com/mailman/listinfo/simple>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 19 Sep 2001 18:14:06 -0400

Sorry for my prolonged absence on this list... I was on vacation and am just
now getting back to list mails.

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Wednesday, September 19, 2001 3:30 PM
To: Mark Watson; simple
Subject: Re: [Simple] Implicit MESSAGE sessions revisited

>
>
>Assume page-mode messages have a "sessionID" in their payload.
>
>Joe sends a message to Ann.
>Ann forwards to Bob.
>Bob replies to Joe. This reply carries the sessionID from Joe's original
message.
>Joe's app realizes his session is now with Bob and sends further messages
in the session 
>to Bob.
>Joe and Bob exchange many messages in this session.
>Ann has a life.

Sounds like you have assigned some additional semantics to messages with
different sources (i.e., ann vs. bob), but the same session id. In fact, it
sounds like you have just re-invented the old "replaces" approach that we
had, way back before we realized that implicit semantics like this get you
into trouble. How would conferencing work, then? Same session ID also? How
would Joe know whether Bob means to join the conference, or replace the
conversation with Ann? You'll need to define a special IM replaces
mechanism. Specifically, a header that says "hey, this session id replaces
that other one". You've just completely redone the replaces header.

THe one thing I feel REALLY strongly about here, is that if we want a notion
of a prolonged session of messages between endpoints, we use an INVITE/BYE
wrapper. The kind of little hacks that Dean has proposed above will all
eventually break and result in the need to reinvent all that we have done
for SIP today, but now, for IM. Please let us not do that. All of the
existing work - conferencing, remote party id, even manyfolks, can be made
to be useful for IM without any additional work with the INVITE/BYE session
wrapper. 

I do NOT want to invent a new mechanism for this using MESSAGE and implicit
sessions.

-Jonathan R.

----- Original Message ----- 
From: Mark Watson 
To: 'Dean Willis' ; simple 
Sent: Tuesday, September 18, 2001 12:59 PM
Subject: RE: [Simple] Implicit MESSAGE sessions revisited

...Mark

---
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: "Mark Watson" <[email-masked]>
Date: Thu, 20 Sep 2001 09:54:28 +0100

But this is just using a page-mode message to set up an implicit session.
That's fine by me for requirement (1) - all I wanted was the 'session'
concept. But the 'implicit' session set up seems to have been rejected in
previous discussions (unless I've misunderstood).
 
It doesn't solve requirement (2) anyway.
 
...Mark

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: 19 September 2001 20:30
To: Watson, Mark [MAIFP:EP11:EXCH]; simple
Subject: Re: [Simple] Implicit MESSAGE sessions revisited

 
Joe sends a message to Ann.
Ann forwards to Bob.
Bob replies to Joe. This reply carries the sessionID from Joe's original
message.
Joe's app realizes his session is now with Bob and sends further messages in
the session to Bob.
Joe and Bob exchange many messages in this session.
Ann has a life.
 
-_
Dean

----- Original Message ----- 
From: Mark Watson <mailto:[email-masked]>  
To: 'Dean Willis' <mailto:[email-masked]>  ; simple

 

 
...Mark

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: 18 September 2001 15:46
To: simple
Subject: Re: [Simple] Implicit MESSAGE sessions revisited

 
 
--
Dean

----- Original Message ----- 
From: Mark Watson <mailto:[email-masked]>  
To: 'Dean Willis' <mailto:[email-masked]>  ; Patil Basavaraj

Dean,

 

 

Regards...Mark

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: 17 September 2001 17:32
To: Watson, Mark [MAIFP:EP11:EXCH]; Patil Basavaraj (NET/Dallas); 'ext Ben
Campbell'
Cc: simple

--
Dean

----- Original Message ----- 
From: Mark Watson <mailto:[email-masked]>  
To: 'Dean Willis' <mailto:[email-masked]>  ; Patil Basavaraj

Dean, 

...Mark