Subject: RE: [Simple] MSRP Boundary header

From: "Vijay Hampapur Hampapur Parthasarathy" <[email-masked]>
Date: Tue, 29 Jun 2004 13:10:54 -0700

Why cannot this be handled with a content length header that specifies
the length of this chunk. And another header, say an ENDOFMESSAGE header
bool, that specifies if the message is completely done or more pieces
are present. This way the logic to parse would not need to look thro the
entire message before sending (in order to ensure the boundary
characters arent present) and to parse when reading to see where the
current chunk (/message) ends

Vijay

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ben Campbell
Sent: Monday, June 28, 2004 3:47 PM
To: Aditya Bhasin
Cc: [email-masked]
Subject: Re: [Simple] MSRP Boundary header

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:

> 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
> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: Monday, June 28, 2004 3:30 PM
> To: Aditya Bhasin
> Cc: [email-masked]
> Subject: Re: [Simple] MSRP Boundary header
> 
> 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.
> 
> 
> 
> Aditya Bhasin wrote:
> 
> 
>>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
>>
>>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
>>>
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>---
>>>
>>>_______________________________________________
>>>Simple mailing list
>>>[email-masked]
>>>https://www1.ietf.org/mailman/listinfo/simple
>>
>>
>>_______________________________________________
>>Simple mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/simple

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

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

---

From: Ben Campbell <[email-masked]>
Date: Tue, 29 Jun 2004 15:18:48 -0500

That works if you abort message content between chunks. We are talking 
about either aborting or splitting a chunk in mid-stream. And the 06 
draft already has something similar to your idea of an ENDOFMESSAGE flag 
in the continuation flag.

The problem if, if you put a content-length at the front of a message, 
you obviously have to know how long that message is in advance. If I 
need to interrupt a chunk at some arbitrary point in its transmission, I 
have violated that knowledge.