Subject: [Simple] Proposal-Size parameter in MSRP start line

From: <[email-masked]>
Date: Thu, 29 Jun 2006 16:19:50 +0530

> Hi All,
> 
> To remove some implementation complexities I would like to propose
> addition of size field in the start line of MSRP Request and MSRP
> Response that gives the size of MSRP packet without affecting other
> operations. 
> 
> Current start line for request and response are: 
> 
> req-start    = pMSRP SP transact-id SP method CRLF
> resp-start  = pMSRP SP transact-id SP status-code [SP comment] CRLF
> 
> and the proposed changes are 
> 
> req-start   = pMSRP SP size SP transact-id SP method CRLF
> resp-start = pMSRP SP size SP transact-id SP status-code [SP comment]
> CRLF
> 
> The sender of the MSRP packet should include the size of the MSRP
> packet. 
> 
> It will be easy for the receiver to know the size of the received
> packet in advance. The receiver will not have search for the end line
> in the received buffer to check weather a complete MSRP packet is
> received or not.  
> 
> Example.
> ===========
> SEND Request:
> ===========
> 
> MSRP 248 a786hjs2 SEND\r\n
> To-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp\r\n
> From-Path: msrp://atlanta.example.com:7654/jshA7we;tcp\r\n
> Message-ID: 87652\r\n
> Byte-Range: 1-25/25\r\n
> Content-Type: text/plain\r\n
> \r\n
> Hey Bob, are you there?\r\n
> -------a786hjs2$\r\n
> 
> MSRP Response:
> =============
> 
> MSRP 178 a786hjs2 200 OK\r\n
> To-Path: msrp://atlanta.example.com:7654/jshA7we;tcp\r\n
> From-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp\r\n
> Byte-Range: 1-25/25\r\n
> -------a786hjs2$\r\n
> 
> REPORT Rquest:
> =============
> MSRP 192 dkei38sd REPORT\r\n
> To-Path: msrp://alicepc.example.com:7777/iau39;tcp\r\n
> From-Path: msrp://bob.example.com:8888/9di4ea;tcp\r\n
> Message-ID: 12339sdqwer\r\n
> Status: 000 200 OK\r\n
> -------dkei38sd$\r\n
> 
> Reason for Proposing the New Parameter:
> 
> 1. Receiver has to traverse whole MSRP receive packet for end line.
> 
> 2. As the underlying protocol is TCP, the recv()/read() function call
> returns the bytes available and that can be accommodated in the MSRP
> passed buffer. So there may be two case:
> 	a) Whole MSRP Send packet is not available (from Start line to
> End line).
> 	b) More then one MSRP Send packet is available and returned in
> read.
> 
> 3. As per MSRP draft max body size is 2048 bytes but it does not talk
> about the max packet size (content body size + header size). Max body
> size for a chunk is fixed but there is no size restriction for the
> header and header values. For example: Transaction id, message id,
> session id etc can be of any length and there is also provision for
> extension header and values. Receiver really does not know  the buffer
> size. so what will be criteria for allocating the buffer space for
> reading MSRP data from TCP?
> 
> IP Protocol and ST, Internet Stream Protocol, are examples where both
> header size as well as body size fields are present. There could be
> other protocols which give both header size and body size.
> 
> Regards,
> Amit Kumar Goel

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

---

From: Ben Campbell <[email-masked]>
Date: Thu, 29 Jun 2006 08:41:40 -0500

Hi,

A long time back, the working group had an extended discussion about  
whether to do message framing by the inclusion of a length parameter  
vs the use of an end-marker. We chose the end-marker for the reason  
that it is very possible that a sender does not know the full length  
of the message when it begins sending. For example, it may be sending  
the input from some streaming device.

Further comment inline:

On Jun 29, 2006, at 5:49 AM, <[email-masked]>  
<[email-masked]> wrote:

[...]

>> about the max packet size (content body size + header size).

MSRP does not have a maximum body size. The 2048 figure is a number  
of which the request must be constructed to be interruptible. In  
fact, if a sender has more than 2048 bytes to send, and has no reason  
to interrupt the request for more pressing traffic, it is encouraged  
to send it in one interruptible chunk.

>> Max body