Subject: RE: [Simple] Byte Range in MSRP

From: "Orit Levin" <[email-masked]>
Date: Wed, 19 Jan 2005 11:38:25 -0800

Cool.
It can be very useful to have this (i.e. non-chunked short message)
example using the byte range in the general section rather than in the
chunking section.
 
Thanks,
Orit.

________________________________

	From: Cullen Jennings [mailto:[email-masked]] 
	Sent: Tuesday, January 18, 2005 6:45 PM
	To: Orit Levin; Avshalom Houri; [email-masked]
	Subject: Re: [Simple] Byte Range in MSRP

	Agree - good point - I'll make sure there is an example in the
Framing and chunking section section that has this.
	
	Cullen
	
	On 1/18/05 4:14 PM, "Orit Levin" <[email-masked]> wrote:

		Avshalom has a good point here, which I have overlooked.

		We have never agreed that scanning is the always
preferred way of 
		finding the end of the packet. The current mechanism
allows for both, 
		indeed. 
		I would strongly suggest to include an example in the
draft that shows 
		the byte count being included even where no chunking is
performed. 
		
		When the originator doesn't chunk the message to start
from, the byte 
		range SHOULD be included (I think that MUST is even more
appropriate). 
		
		Thanks, 
		Orit. 
		
		> -----Original Message----- 
		> From: [email-masked] 
		> [mailto:[email-masked]] On Behalf Of
Jennings, Cullen 
		> Sent: Tuesday, January 18, 2005 3:51 PM 
		> To: Avshalom Houri; [email-masked] 
		> Subject: Re: [Simple] Byte Range in MSRP 
		> 
		> 
		> Right - this topic has been widely discussed on many
previous emails 
		> 
		> On 1/18/05 11:54 AM, "Avshalom Houri"
<[email-masked]> wrote: 
		> 
		> > 
		> > In the MSRP 09 draft following examples appear: 
		> > 
		> >    MSRP a786hjs2 SEND 
		> >    To-Path:
msrp://biloxi.example.com:12763/kjhd37s2s2;tcp 
		> >    From-Path:
msrp://atlanta.example.com:7654/jshA7we;tcp 
		> >    Message-ID: 87652 
		> >    Content-Type: text/plain 
		> >    Hey Bob, are you there? 
		> >    -------a786hjs2$ 
		> >    MSRP a786hjs2 200 OK 
		> >    To-Path:
msrp://atlanta.example.com:7654/jshA7we;tcp 
		> >    From-Path:
msrp://biloxi.example.com:12763/kjhd37s2s2;tcp 
		> >    Message-ID: 87652 
		> >    -------a786hjs2$ 
		> > 
		> > Note that this format of messages enforces the
reader of 
		> the messages 
		> > to scan the messages in order to find the end of the
message. 
		> Yes - this is because of the multiplexing behavior, a
message 
		> may be split up mid way through transmission on this -
since 
		> this is not known when it starts, you need of scan. 
		> 
		> Extensive playing with this has shown that scanning
for 
		> ------- is just as fast as coping to memory on every
system 
		> someone could find 
		> 
		> > 
		> > It does not enable an implementation that decides to
include byte 
		> > count in the message to do so. 
		> 
		> The draft does support including a byte count 
		> 
		> > 
		> > Was not there a suggestion to include a Byte-Range
(with an 
		> option to 
		> > put a '*' instead of a range) in every message even 
		> messages that are 
		> > not chunked? 
		> 
		> Yes this Byte-Range stuff is all in the 09 version of
the 
		> draft - and the stuff below 
		> 
		> > 
		> > This way an implementation that wants to start
writing to 
		> the output 
		> > buffer immediately will put "Byte-Range: *-*/*"
while an 
		> > implementation that wants to put the actual byte
count in order to 
		> > make message reading more efficient will put
"Byte-Range 
		> 1-N/N" where N is the size of the message. 
		> > 
		>  
		> > Avshalom 
		> > 
		> > 
		> > 
		> > _______________________________________________ 
		> > 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: Cullen Jennings <[email-masked]>
Date: Wed, 19 Jan 2005 17:45:08 -1000

Fair enough - I will go and update the examples in the Overview section to
have a Byte-Range header.

On 1/19/05 9:38 AM, "Orit Levin" <[email-masked]> wrote:

> Cool.
> It can be very useful to have this (i.e. non-chunked short message) example
> using the byte range in the general section rather than in the chunking
> section.
>  
> Thanks,
> Orit.
> 
>>  
>>  
>> 
>> Agree - good point - I'll make sure there is an  example in the Framing and
>> chunking section section that has  this.
>> 
>> Cullen
>> 
>>> We have never agreed that scanning is the always  preferred way of
>>> finding the end of the packet. The current mechanism  allows for both,
>>> indeed. 
>>> I would strongly suggest to include an  example in the draft that shows
>>> the byte count being included even where  no chunking is performed.
>>> 
>>> When the originator doesn't chunk the  message to start from, the byte
>>> range SHOULD be included (I think that  MUST is even more appropriate).
>>> 
>>> Thanks, 
>>> Orit. 
>>> 
>>>> >  [mailto:[email-masked]]  On Behalf Of Jennings, Cullen
>>>> > Right - this topic  has been widely discussed on many previous emails
>>>> > 
>>>> > On  1/18/05 11:54 AM, "Avshalom Houri" <[email-masked]> wrote:
>>>> > 
>>>>> > > 
>>>>> > >    To-Path:  msrp://biloxi.example.com:12763/kjhd37s2s2;tcp
>>>>> > >     From-Path: msrp://atlanta.example.com:7654/jshA7we;tcp
>>>>> > >    Message-ID: 87652
>>>>> > >     Content-Type: text/plain
>>>>> > > 
>>>>> > >     Hey Bob, are you there?
>>>>> > >     -------a786hjs2$
>>>>> > > 
>>>>> > >     MSRP a786hjs2 200 OK
>>>>> > >     To-Path: msrp://atlanta.example.com:7654/jshA7we;tcp
>>>>> > >    From-Path:  msrp://biloxi.example.com:12763/kjhd37s2s2;tcp
>>>>> > >     Message-ID: 87652
>>>>> > >     -------a786hjs2$
>>>>> > > 
>>>>> > > Note that  this format of messages enforces the reader of
>>>> > the messages
>>>>> > > to scan the messages in order to find the end of the message.
>>>> > Yes - this is because of the multiplexing behavior, a message
>>>> > may be split up mid way through transmission on this - since
>>>> > Extensive playing with this has shown that scanning for
>>>> >  ------- is just as fast as coping to memory on every system
>>>> > someone  could find
>>>> > 
>>>>> > > 
>>>>> > > It does not enable an  implementation that decides to include byte
>>>>> > > Was not there a suggestion to  include a Byte-Range (with an
>>>> > option to 
>>>> > Yes this Byte-Range stuff is  all in the 09 version of the
>>>>> > > This way an implementation that wants to start  writing to
>>>> > the output 
>>>>> > > buffer immediately will put  "Byte-Range: *-*/*" while an
>>>>> > > implementation that wants to put  the actual byte count in order to
>>>>> > > make message reading more  efficient will put "Byte-Range