Subject: [Simple] Message Sessions

From: "Chris Boulton" <[email-masked]>
Date: Thu, 10 Jul 2003 09:34:36 +0100

Ben,
 
            I've just had time to have a detailed look at the 'sessions'
draft.  This draft seems to answer a lot of the outstanding questions
associated with Instant Messaging within SIP.  I have a couple of
comments, apologies for being late:-
 
-          I understand the need for a separate data connection when
transferring large files - I was just wondering how a client would
associate the new data session with the original, textual one (I could
be missing something here so please SHOUT ;-).  I was wondering if this
could be done at the MSRP level by including a session style parameter
on the S-URL (e.g.
S-URL:msrp://relay.atlanta.com:7777/iau39;foo=abc123).  This way, if a
new session arrives with a matching session parameter, the MSRP client
knows which chat to prompt e.g. 'Do you want to accept a file transfer
from........'.
 
-          I was also considering the 'keystroke' functionality that we
have all come to know and love.  I realize that this may not be an issue
for the base messaging spec but I'll mention it anyway.  I was thinking
of maybe an optional MSRP header which signifies that activity (e.g.
keyboard) has taken place.  This could then be sent in an MSRP SEND
request, usually a refresh without a content.  So if I start typing a
message, a blank SEND is sent with the 'activity' header set to true.
This would notify the recipient that the far-end is responding.  This
header would require an 'expires' parameter, to invalidate the activity
(e.g. 10 seconds).  This expires would be set both locally and on the
receiving endpoint.  If a client types a message, the activity refresh
is sent, and the other end is informed BUT if the expiry fires, this
information should be withdrawn.  The generating client would not
re-send an activity SEND if the timer has not expired.  This would
increase the size of an MSRP message :-( BUT would be an optional
header.
 
That's my observations, feel free to ignore ;-)
 
Chris.

------------------------------------------------
Chris Boulton
Ubiquity Software
 
Tel : +44 (0) 1633765600
Fax : +44 (0) 1633765601 
------------------------------------------------

---

From: Ben Campbell <[email-masked]>
Date: 10 Jul 2003 16:40:06 -0500

On Thu, 2003-07-10 at 03:34, Chris Boulton wrote:
> Ben,
> 
>  
> 
>             I’ve just had time to have a detailed look at the
> ‘sessions’ draft.  This draft seems to answer a lot of the outstanding
> questions associated with Instant Messaging within SIP.  I have a
> couple of comments, apologies for being late:-

No problem.
> transferring large files – I was just wondering how a client would
> be missing something here so please SHOUT ;-).  I was wondering if
> this could be done at the MSRP level by including a session style
> parameter on the S-URL (e.g.
> knows which chat to prompt e.g. ‘Do you want to accept a file transfer
> from……..’.
> 

Hmm. I don't think we really have talked much about associating the two.
If that is in fact a requirement, I would lean toward creating the
association on the signaling side rather than in the URI. It is not
clear to me if associating file transfer with text sessions is as much
of a requirement as simply understanding what sort of data is being
sent, and acting appropriately. In the case of transferring large
content, the client can make some determinations based on the size and
content-type.

>  
> 
> -         I was also considering the ‘keystroke’ functionality that we
> have all come to know and love.  I realize that this may not be an
> issue for the base messaging spec but I’ll mention it anyway.  I was
> thinking of maybe an optional MSRP header which signifies that
> activity (e.g. keyboard) has taken place.  This could then be sent in
> an MSRP SEND request, usually a refresh without a content.  So if I
> start typing a message, a blank SEND is sent with the ’activity’
> header set to true.  This would notify the recipient that the far-end
> is responding.  This header would require an ‘expires’ parameter, to
> invalidate the activity (e.g. 10 seconds).  This expires would be set
> both locally and on the receiving endpoint.  If a client types a
> message, the activity refresh is sent, and the other end is informed
> BUT if the expiry fires, this information should be withdrawn. The
> generating client would not re-send an activity SEND if the timer has
> not expired.  This would increase the size of an MSRP message L BUT
> would be an optional header.
> 

I wonder if it would make sense to use the same technique for this as is
being discussed for page-mode messaging; that is, send a message with a
particular MIME type. A client can indicate support by including that
type in the format list.
 
> 
> That’s my observations, feel free to ignore ;-)
> 
>  
> 
> Chris.
> 
>  
> 
>  
> 

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Ben Campbell <[email-masked]>
Date: 10 Jul 2003 16:40:06 -0500

No problem.