RE: [Speechsc] message-length clarification

["Carter, Jerry" <[e-mail]>]

I believe that Dave Burke's order correctly captures the discussion.  There
was a preference for removing the message-length entirely.

> -----Original Message-----
> From: Burger, Eric [mailto:[e-mail]]
> Sent: Tuesday, April 18, 2006 5:52 PM
> To: Dave Burke; Corby Anderson; Brett Gavagni
> Cc: [e-mail]; Shanmugham, Saravanan; Bergallo Patrizio
> Subject: RE: [Speechsc] message-length clarification
> 
> 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

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