Subject: [Simple] MSRP Boundary header

From: "Murty Dasari" <[email-masked]>
Date: Wed, 23 Jun 2004 12:45:29 -0700

Hello,

I've a question about MSRP (based on
draft-ietf-simple-message-sessions-06.txt) "Closing" field.

What is the need for a "Closing" field?

Can't we use "Content-Length" similar to HTTP for determining the message
body length? If this is there for "Continuation-Flag" then probably we can
have another header that indicates continuation status. Though it might not
be lot of work to determine the "closing" tag, it might be easy for the
relays and clients to retrieve the message body based on content-length
header; further, we don't have to add restrictions on presence of "boundary"
in the message body in this case.

This question might have brought-up/answered earlier, but I couldn't find
out from the archives. Appreciate any comments.

Thanks for your time.

- Murty 

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

---

From: Ben Campbell <[email-masked]>
Date: Mon, 28 Jun 2004 16:03:45 -0500

The reason is, we added a requirement to be able abort a message without 
destroying framing for the TCP connection. The boundary approach has 
that property, content-length does not.

Murty Dasari wrote:

> Hello,
> 
>  
> 
> I’ve a question about MSRP (based on 
> draft-ietf-simple-message-sessions-06.txt) “Closing” field.
> 
>  
> 
> What is the need for a “Closing” field?
> 
>  
> 
> Can’t we use “Content-Length” similar to HTTP for determining the 
> message body length? If this is there for “Continuation-Flag” then 
> probably we can have another header that indicates continuation status. 
> Though it might not be lot of work to determine the “closing” tag, it 
> might be easy for the relays and clients to retrieve the message body 
> based on content-length header; further, we don’t have to add 
> restrictions on presence of “boundary” in the message body in this case.
> 
>  
> 
> This question might have brought-up/answered earlier, but I couldn’t 
> find out from the archives. Appreciate any comments.
> 
>  
> 
> Thanks for your time.
> 
> - Murty
> 
>  
> 
> 
> ------------------------------------------------------------------------
>

---

From: "Aditya Bhasin" <[email-masked]>
Date: Mon, 28 Jun 2004 15:03:54 -0700

Ben,

Could you explain this a little more.

Thx

aditya

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ben Campbell
Sent: Monday, June 28, 2004 2:04 PM
To: Murty Dasari
Cc: [email-masked]
Subject: Re: [Simple] MSRP Boundary header

Murty Dasari wrote:

> Can't we use "Content-Length" similar to HTTP for determining the 
> message body length? If this is there for "Continuation-Flag" then 
> Though it might not be lot of work to determine the "closing" tag, it 
> based on content-length header; further, we don't have to add 
> restrictions on presence of "boundary" in the message body in this case.
> 
>  
> 
> This question might have brought-up/answered earlier, but I couldn't

---

From: Ben Campbell <[email-masked]>
Date: Mon, 28 Jun 2004 17:29:38 -0500

If you use message-length for framing purposes, then once you have sent 
the message-length value, you have to send that many bytes. If you 
don't, the peer cannot tell when the current message ends and the next 
one starts. Once the peer loses track of framing in this way, framing is 
lost for the entire connection.

We could probably fix this with some sort of sync protocol, but that 
would be more complex than just going to a delimiter approach to 
framing, which is exactly what the boundary is.

---

From: "Aditya Bhasin" <[email-masked]>
Date: Mon, 28 Jun 2004 15:41:08 -0700

What applications are being targeted for this to be an issue?

The size of the content will have to be extremely large and the application
pretty close to a streaming application to be able to insert an ending
boundary delimiter.  

Sorry late to the discussions and only trying to understand what is driving
this requirement.

thx

---

From: Ben Campbell <[email-masked]>
Date: Mon, 28 Jun 2004 17:46:53 -0500

The ability to handle large content has been a generally accepted 
requirement. The entire chunking mechanism is there due to this requirement.

I do not understand what you mean by "being close to the application". 
There a a number of ways an application could talk to the MSRP layer. 
For an absurdly trivial example, you could simply pipe output from an 
app, and have MSRP recognize the end-of-file.

Aditya Bhasin wrote:

>>From: [email-masked] [mailto:[email-masked]] On Behalf
> 
> Of
> 
>>Ben Campbell