RE: [Speechsc] message-length clarification

["Burger, Eric" <[e-mail]>]

Any takers?  I'm with option 2, as that leaves things as it and is
workable.

-----Original Message-----
From: Dave Burke [mailto:[e-mail]] 
Sent: Monday, April 17, 2006 12:57 PM
To: Corby Anderson; Brett Gavagni
Cc: [e-mail]; Shanmugham, Saravanan; Bergallo Patrizio
Subject: Re: [Speechsc] message-length clarification

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" <[e-mail]>
To: "Corby Anderson" <[e-mail]>
Cc: <[e-mail]>; "Shanmugham, Saravanan" <[e-mail]>;
"Bergallo Patrizio" <[e-mail]>
Sent: Monday, April 17, 2006 3:42 PM
Subject: Re: [Speechsc] message-length clarification


> 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
>


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

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