Hi,
I just read the currently published version of the draft and I was
wondering if it would be an idea to also address the following issue:
In the case where participants with different access-speeds are joined
in a chat-room, how should the msrp-switch deal with the situation
when
it is not able to write data quickly enough to the slower
participants?
For example a user with a relative fast connection could start to
send a
large file into the chat-room which will cause the slower participants
to be blocked out from the chat-room until they managed to consume the
queued data. Also, should the switch just queue as long as it has
memory
available?
They way this is solved in IRC for example is to slow down the sending
client by starting to respond slowly for each SEND request. However,
this is not a suitable solution for msrp, since it is indented to deal
with all sorts of content (including multi-media).
Maybe there is a need for a 'chat-type' attribute to distinguish
between
for example 'conversation' or 'multi-media' rooms.
I think this is a realistic issue because of the following two
reasons:
- SIP is well on its way to bridge between the 'internet-world' and
the
'mobile-world'; two worlds with difference access-speeds
- simply because flooding a room could lead to a denial-of-service
attack in the case where the msrp-switch is forces to queue the data
which it is not able to send downwards.
Sebastian