Subject: RE: [Speechsc] message-length clarification

From: "Shanmugham, Saravanan" <[email-masked]>
Date: Fri, 14 Apr 2006 11:06:21 -0700

Pete/Bergallo,
 
Leading spaces are illegal per the current ABNF definition. 
But Pete's suggestion is perfectly legal and makes the encoding phase
just as effciient.
 
I can add this clarification/suggestion for implementers into the
specification.
 
Thx,
 
Sarvi

________________________________

	From: Bergallo Patrizio [mailto:[email-masked]] 
	Sent: Friday, April 14, 2006 1:44 AM
	To: [email-masked]
	Subject: RE: [Speechsc] message-length clarification

	I agree that problems arise more on encoding side than in
decoding one.
	What about using leading SP, with the same purpose of leading
zeros
	mentioned by Pete?
	Is it legal?
	Anyway, though I'm not a big fan of message-length field, I
think that
	removing it at this stage of spec should be avoided.
	
	Regards,
	Patrizio Bergallo, Loquendo. 
	
	> -----Original Message-----
	> From: Pete Cordell [mailto:[email-masked]] 
	> Sent: Friday, April 14, 2006 9:55 AM
	> To: Dave Burke
	> Cc: [email-masked]
	> Subject: Re: [Speechsc] message-length clarification
	> 
	> 
	> As someone watching from the sidelines, this issue about the 
	> representation 
	> of the length field potentially changing the value of the 
	> length that needed 
	> to be encoded occurred to me also.
	> 
	> I wondered if you could use leading zeros in the length field 
	> so that it is 
	> always fixed length. e.g. in C it would be something like:
	> 
	> sprintf( lstr, "%04d", len ); // Not sure if 4 is the right
number!
	> 
	> Messages would then look like:
	> 
	> MRCP/2.0 0047 543256 200 COMPLETE
	> ...
	> 
	> Still a bit of a gotcha though, that could lead to one of 
	> those one in a 
	> hundred type bugs!
	> 
	> Regards,
	> 
	> Pete.
	> --
	> =============================================
	> Pete Cordell
	> Tech-Know-Ware Ltd
	> for XML to C++ data binding visit
	> http://www.tech-know-ware.com/lmx
	> (or http://www.xml2cpp.com) 
	> =============================================
	> 
	> ----- Original Message ----- 
	> From: "Dave Burke" 
	> To: "Shanmugham, Saravanan" ; "Brett Gavagni" 
	> 
	> Cc: 
	> Sent: Friday, April 14, 2006 12:39 AM
	> Subject: Re: [Speechsc] message-length clarification
	> 
	> 
	> > Just wanted to insert one point that I haven't seen
mentioned: The
	> > message-length makes it easier to decode but not encode.
	> >
	> > This is because the message-length also includes the number 
	> of bytes 
	> > that
	> > specify the message-length in the header. The algorithm for 
	> determining 
	> > the message-length has to add up all the bytes in the 
	> message to get a 
	> > total (label: N), then determine the number of bytes to
represent N 
	> > (label: M), then check if the total N+M rolls over a power 
	> of 10 (if it 
	> > does you need another byte). The value to insert for the 
	> message-length is 
	> > not simply N+M but rather
	> >
	> > (N >= (10^M-M)) ? N+M+1 : N+M
	> >
	> > For example, if N=97 then M=2 and N+M=99=message-length. 
	> However, if 
	> > N=98
	> > then M=2 but now N+M=100 => message-length=N+M+1
	> >
	> > Sorta awkward - no?
	> >
	> > Dave
	> >
	> >
	> >
	> >
	> >
	> > ----- Original Message -----
	> > From: "Brett Gavagni" 
	> > To: "Shanmugham, Saravanan" 
	> > Cc: 
	> > Sent: Thursday, April 13, 2006 1:52 PM
	> > Subject: RE: [Speechsc] message-length clarification
	> >
	> >
	> > Hi Sarvi,
	> >
	> > I realize that it may be late in the game for addressing 
	> problems in 
	> > the specification, but I would evangelize that its cheaper 
	> to pay now 
	> > (potential standardization delays) than to pay later (poor 
	> adoption) 
	> > due to convolution and problematic issues in the spec.
	> >
	> > Since the session control for MRCPv2 is separated (a la SIP,
RTSP, 
	> > etc..) and not tunnelled, what would be the compelling 
	> reason that the 
	> > message-length token exist in the start-line especially
since the 
	> > "Content-Length" header?
	> >
	> > I'm now proposing the removal of the message-length token
from the 
	> > start-line in entirety, as it is at least redundant and 
	> deviating from 
	> > the HTTP-like conventions leveraged throughout the spec.
	> >
	> > Thanks,
	> >
	> > Brett Gavagni
	> > WebSphere Voice Server Development 
	> > http://www-306.ibm.com/software/pervasive/voice_server/
	> > [email-masked]
	> >
	> ...cut... 
	> 
	> 
	> 
	> _______________________________________________
	> Speechsc mailing list
	> [email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc
	
	Gruppo Telecom Italia - Direzione e coordinamento di Telecom
Italia S.p.A.
	
	================================================
	CONFIDENTIALITY NOTICE
	This message and its attachments are addressed solely to the
persons
	above and may contain confidential information. If you have
received
	the message in error, be informed that any use of the content
hereof
	is prohibited. Please return it immediately to the sender and
delete
	the message. Should you have any questions, please send an
e_mail to
	<mailto:[email-masked]>[email-masked].
Thank you
	<http://www.loquendo.com>www.loquendo.com
	================================================

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

---

From: Brett Gavagni <[email-masked]>
Date: Fri, 14 Apr 2006 14:31:07 -0400

Am I the only one that thinks this suggestion for padding a fixed length 
is a Band-Aid (*hack) for the real problem identified by this thread?

Thanks,

Brett Gavagni 

"Shanmugham, Saravanan" <[email-masked]> 
04/14/2006 02:06 PM

To
"Bergallo Patrizio" <[email-masked]>, <[email-masked]>
cc

Subject
RE: [Speechsc] message-length clarification

Pete/Bergallo,
 
Leading spaces are illegal per the current ABNF definition. 
But Pete's suggestion is perfectly legal and makes the encoding phase just 
as effciient.

Thx,
 
Sarvi

I agree that problems arise more on encoding side than in decoding one.
What about using leading SP, with the same purpose of leading zeros
mentioned by Pete?
Is it legal?
Anyway, though I'm not a big fan of message-length field, I think that
removing it at this stage of spec should be avoided.

Regards,

> sprintf( lstr, "%04d", len ); // Not sure if 4 is the right number!
> 
> > Just wanted to insert one point that I haven't seen mentioned: The
> > total (label: N), then determine the number of bytes to represent N 
> > Since the session control for MRCPv2 is separated (a la SIP, RTSP, 
> > message-length token exist in the start-line especially since the 
> > "Content-Length" header?
> >
> > I'm now proposing the removal of the message-length token from the 
> [email-masked] https://www1.ietf.org/mailman/listinfo/speechsc
> 

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to
<mailto:[email-masked]>[email-masked]. Thank you
<http://www.loquendo.com>www.loquendo.com
================================================
_______________________________________________
Speechsc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc

---

From: Corby Anderson <[email-masked]>
Date: Fri, 14 Apr 2006 17:26:36 -0700

No, you're not the only one. :-)  It is hacky.  The size calculation 
that Dave Burke posted is concise, but it's cumbersome.

But stepping back a little, it *is* helpful to know the size ahead of 
time.  Since clients can share an MRCP control channel, it's makes the 
server's job easier if it knows ahead of time how many bytes will be in 
a particular command.  You can imagine an implementation where a the 
socket reader understands the first-line format enough to read all the 
bytes for a single message into a buffer and then hand it off to a 
different class/function/thread for further processing.

How about if  the length pertained to the size of everything *except* 
the first line?  That would make the size calculation trivial and would 
still offer the benefit of having the size around for parsing purposes.

Corby Anderson
Tellme Networks

---

From: Brett Gavagni <[email-masked]>
Date: Mon, 17 Apr 2006 10:42:36 -0400

That was the original suggestion when I started with this thread 
(http://www1.ietf.org/mail-archive/web/speechsc/current/msg01722.html), 
and this suggestion wasn't  too well received.

"Propose to modify the wording that message-length does NOT include the 
start-line as an issue to track for the next draft."

So then we diverged into the defining the true value of the message-length 
token, and thus the proposal for the removal of the message-length token 
in its entirety. 

This removal  proposal was fueled even more with the distinction that the 
MRCPv2 session control is separated, especially since MRCPv2 messages are 
NOT expected/described as tunnelled.

I'd be happy if the message-length was modified as originally proposed to 
NOT include the size of the start-line in the length, or if the 
message-length to be removed from the draft.

IMO, anything else is a hack. =) 

Continue the flame roasting as necessary. =)

Thanks,

Brett Gavagni 

Corby Anderson <[email-masked]> 
04/14/2006 08:26 PM

To
Brett Gavagni/West Palm Beach/IBM@IBMUS
cc
"Shanmugham, Saravanan" <[email-masked]>, [email-masked], Bergallo 
Patrizio <[email-masked]>
Subject
Re: [Speechsc] message-length clarification

No, you're not the only one. :-)  It is hacky.  The size calculation that 
Dave Burke posted is concise, but it's cumbersome.

But stepping back a little, it *is* helpful to know the size ahead of 
time.  Since clients can share an MRCP control channel, it's makes the 
server's job easier if it knows ahead of time how many bytes will be in a 
particular command.  You can imagine an implementation where a the socket 
reader understands the first-line format enough to read all the bytes for 
a single message into a buffer and then hand it off to a different 
class/function/thread for further processing.

How about if  the length pertained to the size of everything *except* the 
first line?  That would make the size calculation trivial and would still 
offer the benefit of having the size around for parsing purposes.

Corby Anderson
Tellme Networks

Brett Gavagni wrote: 

Thanks,

Brett Gavagni 

To

Subject

Pete/Bergallo,

as effciient.

Thx,
 
Sarvi

Regards,

-----Original Message-----
From: Pete Cordell [mailto:[email-masked]] 
Sent: Friday, April 14, 2006 9:55 AM
To: Dave Burke
Cc: [email-masked]
Subject: Re: [Speechsc] message-length clarification

Regards,

Pete.

----- Original Message ----- 
From: "Dave Burke" 

Cc: 

 
of bytes 
 
that
 
determining 

message to get a 

of 10 (if it 

message-length is 

 
However, if 
 
N=98

Sorta awkward - no?

Dave

----- Original Message -----
From: "Brett Gavagni" 
To: "Shanmugham, Saravanan" 
Cc: 
Sent: Thursday, April 13, 2006 1:52 PM
Subject: RE: [Speechsc] message-length clarification

Hi Sarvi,

problems in 

to pay now 

adoption) 

 
reason that the 

 
deviating from 

Thanks,

Brett Gavagni

...cut...

---

From: "Dave Burke" <[email-masked]>
Date: Mon, 17 Apr 2006 17:56:51 +0100

In the interests of rough consensus:

o Preference for:
    - Remove message-length altogether

o Can live with:
    - Zero-padding note (as per Sarvi's suggestion)

 o Don't like:
    - message-length doesn't include start-line
    (because this is a half-way house with negligible value - the
     parser will be searching for \n anyways so why not iterate up
     to Content-Length)

Dave

----- Original Message ----- 
From: "Brett Gavagni" <[email-masked]>
To: "Corby Anderson" <[email-masked]>
Cc: <[email-masked]>; "Shanmugham, Saravanan" <[email-masked]>;
"Bergallo Patrizio" <[email-masked]>
Sent: Monday, April 17, 2006 3:42 PM
Subject: Re: [Speechsc] message-length clarification