Subject: [Simple] RE: Message Sessions

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

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

[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 ;-)
>>
>>
>>
>> Chris.
>>
>>
>>
>>
>>
>> ------------------------------------------------
>>
>> Chris Boulton
>>
>> Ubiquity Software
>>
>>
>>
>> Tel : +44 (0) 1633765600
>>
>> Fax : +44 (0) 1633765601
>>
>> ------------------------------------------------
>>
>>
>>
>>
>>
>>

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

---

From: Ben Campbell <[email-masked]>
Date: 11 Jul 2003 08:32:35 -0500

> Comments in-line.
[...]

> decide to decline the file from Alex and accept the file from James.

Chris knows which user the additional session is coming from the same
way he knew who originated the _original_ sessions; that is, he
authenticates the SIP requests (or whatever the signaling protocol
happens to be.) 

> didn't have a major burden on message size, which is in-keeping with the

http://www.softarmor.com/simple/drafts/draft-schulzrinne-simple-iscomposing-00.txt

Your proposal is certainly lighter weight than in the draft, but I think
Henning's approach is not all that heavyweight, and brings a lot more
flexibility. I would be interested in hearing other opinions, here,
though.

---

From: Ben Campbell <[email-masked]>
Date: 11 Jul 2003 08:32:35 -0500

[...]