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/
gavagni at us.ibm.com
Corby Anderson <corby at tellme.com>
04/14/2006 08:26 PM
To
Brett Gavagni/West Palm Beach/IBM at IBMUS
cc
"Shanmugham, Saravanan" <sarvi at cisco.com>, speechsc at ietf.org, Bergallo
Patrizio <patrizio.bergallo at loquendo.com>
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/
gavagni at us.ibm.com
"Shanmugham, Saravanan" <sarvi at cisco.com>
04/14/2006 02:06 PM
To
"Bergallo Patrizio" <patrizio.bergallo at loquendo.com>, <speechsc at ietf.org>
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:patrizio.bergallo at loquendo.com]
Sent: Friday, April 14, 2006 1:44 AM
To: speechsc at ietf.org
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:pete at tech-know-ware.com]
Sent: Friday, April 14, 2006 9:55 AM
To: Dave Burke
Cc: speechsc at ietf.org
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/
gavagni at us.ibm.com
...cut...
_______________________________________________
Speechsc mailing list
Speechsc at ietf.org 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:webmaster at telecomitalia.it>webmaster at telecomitalia.it. Thank you
<http://www.loquendo.com>www.loquendo.com
================================================
_______________________________________________
Speechsc mailing list
Speechsc at ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc
_______________________________________________
Speechsc mailing list
Speechsc at ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc
_______________________________________________
Speechsc mailing list
Speechsc at ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc