Subject: [Simple] MSRP Chunk transmission and presentation

From: Gunnar Hellström <[email-masked]>
Date: Sun, 9 Dec 2007 23:58:23 +0100

Hi,
I want to suggest registrating and using a new MIME Content-disposition
value to indicate that message chunks shall be sent on by MSRP relays and
presented immediately by the MSRP receiver.
 
I have (again) looked into the opportunity to use MSRP for real-time or
real-timish text transport. 
The main idea is to get a smoother flow of text so that receiving users do
not need to wait for complete messages to be entered before they can get a
view of what is typed. 
 
The chunk concept could be used, and time sampled chunks of text could be
sent with no extra action by the user. 
The receiving side would present chunks as they arrive, and present them
consecutively, so that received text message grows as more chunks are
received.
 
Most of this would be straightforward conventions of use of MSRP and
presentation conventions for some text MIME subtypes. 
 
Further investigation may indicate what sampling interval is suitable: 300
ms for real-time use or 1-3 seconds for real-timish. 
 
BUT,
Both for Chunk handling in the MSRP Relay as specified in RFC 4976 and for
MSRP Receivers in RFC 4975, it is not defined what they do with chunks.
Relays may recombine chunks into larger chunks, or messages, and receivers
can wait for all chunks to be received before anything is presented. 
In order for the real-timish use of MSRP to have a chance t be predictable,
there seems to be a need for a parameter in the SEND request, indicating
desire or demand for immediate transmission and presentation of the chunk.

This is what MSRP Relay RFC 4976 says in section 6.4.1 Forwarding SEND
requests:
 
"It MAY also combine message fragments
   received before or after this SEND request, and forward them out in a
   single SEND request."
 
and further down:
 
"The MSRP relay MAY choose whether to further fragment the message, or
   combine message fragments, or send the message as is, based on some
   policy that is administered, or based on the network speed to the
   next hop, or any other mechanism."
 
This is what MSRP RFC 4975 says about receivers:
"What is done with the body is outside the scope of MSRP and largely
   determined by the MIME Content-Type and Content-Disposition.  The
   body MAY be rendered after the whole message is received or partially
   rendered as it is being received." 
 
A new Content-disposition=convey-present   attribute value could inform the
relay and the receiver that progressive transmission and presentation of
chunks is desired, and that the relay and the reseivers should not wait for
recombination with later coming chunks.
 
If it is considered unappropriate to define the attribute as a
Content-disposition attribute, a new MIME Header can be defined and inserted
in the MSRP send header, e.g. Content-presentation=progressive, with the
same function.
 
I am not sure if we can mandate to transmit on or to present immediately.
There may be network limitations blocking that ambition. 
The description shoukld therefore be something like:
 
Content-disposition=convey-present.  When an MSRP chunk is received with
this attribute by an MSRP relay, it should be sent on to next destination
without waiting for other chunks. When an MSRP chunk is received with this
attribute by an MSRP destination, it should be presented adjacent to earlier
chunks in the same message without waiting for other chunks. 
 
Comments please.
 
Gunnar Hellström
-------------------------------------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
Tel: +46708204288
www.omnitor.se <http://www.omnitor.se/> 
 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: "Hisham Khartabil" <[email-masked]>
Date: Wed, 12 Dec 2007 14:35:01 +1100

The MSRP message chunking feature is not for the purpose you describe.
It is there for a totally different purpose related to network
congestion. My opinion would be not to use MSRP chunking for this
feature but instead think of something else. Maybe the opposite of
chunking. I.e. combining SEND message bodies and presenting them as
one message to the user. This can be signalled using some sort of
content-disposition type.

Hisham

On 10/12/2007, Gunnar Hellström <[email-masked]> wrote:
> A new Content-disposition=convey-present   attribute value
> could inform the relay and the receiver that progressive transmission and
> presentation of chunks is desired, and that the relay and the reseivers
> should not wait for recombination with later coming chunks.
>
> in the MSRP send header, e.g.
> Content-presentation=progressive, with the same function.
>
> Content-disposition=convey-present.  When an MSRP chunk is
> received with this attribute by an MSRP relay, it should be sent on to next
> destination without waiting for other chunks. When an MSRP chunk is received
> with this attribute by an MSRP destination, it should be presented adjacent
> to earlier chunks in the same message without waiting for other chunks.
>
> Comments please.
>
> Gunnar Hellström
> www.omnitor.se

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 12 Dec 2007 07:16:25 +0100

Hishham,
Thanks for your response.

Yes, it is fully possible to create a real-timish mode of text communication
just based on presentation conventions for a series of MSRP messages.

The presentation layer presents characters from received messages
consecutively appended to earlier received characters as received, and does
not insert any separator until a New Line, CRLF or other agreed entry
separator is received.
That is the most logical way to interpret MSRP + message/cpim + text/plain
today without extra specification, but I think anyway that this mode should
be signaled by some agreed parameter.

The signaling for this case can be by

1. An sdp attribute e.g. a=append
(Something like this is needed anyway for negotiation between alternative
media for the same purpose)

2. The MIME type and subtype. E.g. say in a specification that text/plain
shall always be presented in this way. Or register a new subtype e.g.
text/t140m . 

3. A new MSRP header field

4. A new value for Content-disposition.  E.g. Content-disposition=append

I suggest to introduce an sdp attribute, define it for text/plain and also
add a Content-disposition parameter. 

I still like the idea to base it on chunks. Would it cause any problems to
define presentation rules on chunks?

Gunnar
-----Original Message-----
From: Hisham Khartabil [mailto:[email-masked]] 
Sent: Wednesday, December 12, 2007 4:35 AM
To: Gunnar Hellström
Cc: SIMPLE
Subject: Re: [Simple] MSRP Chunk transmission and presentation

The MSRP message chunking feature is not for the purpose you describe.
It is there for a totally different purpose related to network congestion.
My opinion would be not to use MSRP chunking for this feature but instead
think of something else. Maybe the opposite of chunking. I.e. combining SEND
message bodies and presenting them as one message to the user. This can be
signalled using some sort of content-disposition type.

Hisham

On 10/12/2007, Gunnar Hellström <[email-masked]> wrote:
>
> Hi,
> I want to suggest registrating and using a new MIME 
> Content-disposition value to indicate that message chunks shall be 
> sent on by MSRP relays and presented immediately by the MSRP receiver.
>
> I have (again) looked into the opportunity to use MSRP for real-time 
> or real-timish text transport.
> The main idea is to get a smoother flow of text so that receiving 
> users do not need to wait for complete messages to be entered before 
> they can get a view of what is typed.
>
> The chunk concept could be used, and time sampled chunks of text could 
> be sent with no extra action by the user.
> The receiving side would present chunks as they arrive, and present 
> them consecutively, so that received text message grows as more chunks 
> are received.
>
> Further investigation may indicate what sampling interval is suitable: 
> 300 ms for real-time use or 1-3 seconds for real-timish.
>
> BUT,
> Both for Chunk handling in the MSRP Relay as specified in RFC 4976 and 
> for MSRP Receivers in RFC 4975, it is not defined what they do with
chunks.
> Relays may recombine chunks into larger chunks, or messages, and 
> receivers can wait for all chunks to be received before anything is
presented.
> In order for the real-timish use of MSRP to have a chance t be 
> predictable, there seems to be a need for a parameter in the SEND 
> request, indicating desire or demand for immediate transmission and
presentation of the chunk.
> could inform the relay and the receiver that progressive transmission 
> and presentation of chunks is desired, and that the relay and the 
> reseivers should not wait for recombination with later coming chunks.
>
> Content-disposition attribute, a new MIME Header can be defined and 
> inserted in the MSRP send header, e.g.
> Content-disposition=convey-present.  When an MSRP chunk is received 
> with this attribute by an MSRP relay, it should be sent on to next 
> destination without waiting for other chunks. When an MSRP chunk is 
> received with this attribute by an MSRP destination, it should be 
> presented adjacent to earlier chunks in the same message without waiting
for other chunks.

---

From: "Hisham Khartabil" <[email-masked]>
Date: Thu, 13 Dec 2007 10:42:18 +1100

I don't believe it is a good idea for an endpoint to try and control
the relay's behaviour in relation to chunking. A relay has its own
variables that it uses to make decisions on chunking, merging,
re-chunking, etc. for the purpose of congestion control. Your proposal
will negatively impact those relay decisions.

Hisham