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: "Chris Boulton" <[email-masked]>
Date: Fri, 11 Jul 2003 09:23:44 +0100

Comments in-line.

>-----Original Message-----
>From: Ben Campbell [mailto:[email-masked]]
>Sent: 10 July 2003 22:40
>To: Chris Boulton
>Cc: Simple WG
>Subject: Re: Message Sessions
>
>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.
>>
>>
>>
>> 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.
>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.
>
>>

[Chris Boulton] I agree.  This would be sufficient.  I was just
brainstorming scenarios where a client might have multiple sessions
established using the same base session URL.  How does it choose which
session to associate the data transfer (new session)?  For security
reasons, a receiving client should have the ability to decline a data
transfer + know from which session it is being sent. E.g. Chris has two
sessions open with Alex and James using a relay uri of S-URL:
msrp://relay.atlanta.com:7777/xxxx.  Both wish to transfer a file but I
decide to decline the file from Alex and accept the file from James.

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

[Chris Boulton] Sorry - I wasn't aware of the current proposed method
for 'pager-mode' messaging.  Would be grateful if you could point me to
the appropriate material.  I just saw this solution as quite dynamic +
didn't have a major burden on message size, which is in-keeping with the
MSRP philosophy.  

Chris.

>> That's my observations, feel free to ignore ;-)

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