Re: [Speechsc] message-length clarification

[Brett Gavagni <[e-mail]>]

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 
WebSphere Voice Server Development 
http://www-306.ibm.com/software/pervasive/voice_server/
[e-mail]




Corby Anderson <[e-mail]> 
04/14/2006 08:26 PM

To
Brett Gavagni/West Palm Beach/IBM@IBMUS
cc
"Shanmugham, Saravanan" <[e-mail]>, [e-mail], Bergallo 
Patrizio <[e-mail]>
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: 
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 
WebSphere Voice Server Development 
http://www-306.ibm.com/software/pervasive/voice_server/
[e-mail]




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

To
"Bergallo Patrizio" <[e-mail]>, <[e-mail]>
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.
 
I can add this clarification/suggestion for implementers into the 
specification.
 
Thx,
 
Sarvi

From: Bergallo Patrizio [mailto:[e-mail]] 
Sent: Friday, April 14, 2006 1:44 AM
To: [e-mail]
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:[e-mail]] 
Sent: Friday, April 14, 2006 9:55 AM
To: Dave Burke
Cc: [e-mail]
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/
[e-mail]

 
...cut... 



_______________________________________________
Speechsc mailing list
[e-mail] 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:[e-mail]>[e-mail]. Thank you
<http://www.loquendo.com>www.loquendo.com
================================================
_______________________________________________
Speechsc mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/speechsc



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


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