Subject: [Speechsc] message-length clarification

From: Brett Gavagni <[email-masked]>
Date: Thu, 13 Apr 2006 11:20:43 -0400

What is the reasoning for including the length of the start-line in the 
message-length value? 

Seems a bit inconsistent with other textual based protocols including: SIP 
2.0, HTTP 1.1, or even MRCPv1.

5.1.  Common Protocol Elements

   The message-length field specifies the length of the message,
   including the start-line, and MUST be the 2nd token from the
   beginning of the message.  This is to make the framing and parsing of
   the message simpler to do.  This field specifies the length of the
   message including data that may be encoded into the body of the
   message.

5.2.  Request
   The message-length field specifies the length of the message,
   including the start-line.

5.3.  Response
   The message-length field specifies the length of the message,
   including the start-line.

I hope that this is just a wording problem as even some of the examples 
don't have an accurate message-length value w.r.t draft-9 wording.

Shanmugham & Burnett      Expires June 10, 2006                [Page 99]

Internet-Draft                   MRCPv2                    December 2005

   S->C:MRCP/2.0 69 543259 200 COMPLETE
   Channel-Identifier:32AECB23433801@speechrecog
           Completion-Cause:000 success

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

Thanks,

Brett Gavagni 
WebSphere Voice Server Development 
http://www-306.ibm.com/software/pervasive/voice_server/
[email-masked]

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

---

From: "Carter, Jerry" <[email-masked]>
Date: Thu, 13 Apr 2006 21:13:24 -0400

Quite right.  The unanswered question whether there is any real utility to
having this information in the start-line.  I haven't heard any.  Certainly
HTTP and SIP seem to do quite fine without it.

I tend to agree with Brett that removing the length would not hurt the
specification in any way.  As for the "it was broken when we got here so we
can't fix it" argument for the status quo, I don't find that very
compelling.

-=- Jerry

> -----Original Message-----
> From: Dave Burke [mailto:[email-masked]]
> Sent: Thursday, April 13, 2006 7:39 PM
> To: Shanmugham, Saravanan; Brett Gavagni
> Cc: [email-masked]
> 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" <[email-masked]>
> To: "Shanmugham, Saravanan" <[email-masked]>
> Cc: <[email-masked]>
> 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
> "Shanmugham, Saravanan" <[email-masked]>
> 04/13/2006 04:21 PM
> 
> To
> Brett Gavagni/West Palm Beach/IBM@IBMUS
> cc
> <[email-masked]>
> Subject
> RE: [Speechsc] message-length clarification
> 
> 
> 
> 
> 
> 
> Hi Bret,
>     We are at a stage in the spec development, where we would like to
> restrict changes to  clarifications and significant issues that would
> impede implementation or usage of the protocol
> 
> 1. The point that the message length in the examples are not accurate,
> is true. But that will be true irrrespective of whether the length field
> includes the header or not. That is because, they were never accurately
> calculated in the first place. And this has been discussed before and I
> do't think there is any plan to fix this.
> 
> 2. On the topic of message length inlcuding or excluding the header
> line, I have not heard a strong enough argument to warant a change in
> the document this late in the specification.
> 
> 3. Same thing with the position of Version number in the header line.
> 
> So unless I hear very strong objections to the above conclusions on this
> issues from  more folks, I would like to leave the deinfition of the
> headers as is, with may be clarification that the message length in the
> examples should not be assumed to be accurate.
> 
> Thanks,
> Sarvi
> 
> 
>      -----Original Message-----
>      From: Brett Gavagni [mailto:[email-masked]]
>      Sent: Thursday, April 13, 2006 12:39 PM
>      To: Shanmugham, Saravanan
>      Cc: [email-masked]
>      Subject: RE: [Speechsc] message-length clarification
> 
>      My comments in-line.
> 
>      Thanks,
> 
>      Brett Gavagni
>      (561) 862-2097 T/L (975)
>      "Shanmugham, Saravanan" <[email-masked]>
>      04/13/2006 02:25 PM
> 
>      To
>      Brett Gavagni/West Palm Beach/IBM@IBMUS
>      cc
>      <[email-masked]>
>      Subject
>      RE: [Speechsc] message-length clarification
> 
> 
> 
> 
> 
> 
>      See inline.
> 
>           -----Original Message-----
>           From: Brett Gavagni [mailto:[email-masked]]
>           Sent: Thursday, April 13, 2006 10:52 AM
>           To: Shanmugham, Saravanan
>           Cc: [email-masked]
>           Subject: RE: [Speechsc] message-length clarification
> 
>           Yes, there are efficiency issues with the way that the
>           message-length is defined today in MRCPv2.
> 
>           An example is when a server needs to send a message to the
>           client. The server would need to calculate the size of the
>           MRCP message, and then modify the start-line
>      message-length token.
> 
>      Sarvi>> I don't see the issue here. You need calculate the message
>      length and put in the header whether the length includes
>      the header-line or not. I am not convinced this is
>      significant enough o warrant a change this alte in the spec.
> 
>      Brett>> Agree that the server will always need to calculate the
>      message-length.
>      I'm arguing that the current wording in draft-9 w.r.t.
>      message-length shouldn't include the size of the
>      start-line. As I indicated in earlier in this thread,
>      there are multiple examples throughout draft-9 which do
>      NOT reflect the wording that the start-line should be
>      included in the message-length.
> 
>      Neither one of the examples below have a message-length
>      token value in the
> 
>      start-line that reflects the wording requiring the size of
>      the start-line length in the message-length. The client
>      message is >124 including the start_line, and server
>      message is >47 including the start-line.
> 
>      6.1.1.  SET-PARAMS
> 
>         C->S:  MRCP/2.0 124 SET-PARAMS 543256
>                Channel-Identifier:32AECB23433802@speechsynth
>                Voice-gender:female
>                Voice-variant:3
> 
>         S->C:  MRCP/2.0 47 543256 200 COMPLETE
>                Channel-Identifier:32AECB23433802@speechsynth
> 
>      I don't think that the examples are incorrect, but rather
>      the wording in the draft is counter productive.
> 
>      Sarvi>> Also the length field was added earlier and at a specific
>      location after the version information, so as to make the
>      parsing of the message efficient. This way the moment the
>      parse reads the first 2 tokens, it has the MRCP version
>      number and the message to look forward to allowing for an
>      efficient parser implementation. Which was one the reasons
>      we went for the current definition of the header line.
> 
> 
>           Is there any compelling reason why the message-length
>           should include the length of the start-line?
> 
>           I would also be curious as for the reasoning related to
>           the general deviation in the request-line and event-line
>           start-line definition from MRCPv1. The MRCPv1 ABNF syntax
>           was similar to what is defined for SIP and HTTP 1.1 w.r.t.
>           to token order.
> 
>           Why does the MCRPv2 request-line and the event-line
>           start-line have mrcp-version for the first token (which is
>           what I would expect for the status-line)?
>      Sarvi>> The reason for having version and length
>      information earlier on
>      is described above.
> 
>      Brett>> IMO, deviating from HTTP-like similarities will hinder NOT
>      Brett>> enhance
> 
>      interoperability. For example, MRCPv2 could've been
>      defined in ASN.1 if HTTP-like similarities weren't a
>      beneficial proponent for MRCPv2 embracement/adoption. =)
> 
>      Thx,
>      Sarvi
> 
>           MRCPv2
>              start-line       =    request-line / status-line /
>      event-line
> 
>              request-line   =    mrcp-version SP message-length SP
>           method-name SP
>           request-id CRLF
> 
>              event-line       =    mrcp-version SP message-length SP
>           event-name SP
>           request-id SP request-state CRLF
> 
>           The following protocols are very similar syntactically
>           w.r.t. the request-line start-line.
> 
>           RFC 2616 - HTTP 1.1
>              Request-Line   = Method SP Request-URI SP HTTP-Version CRLF
> 
>           RFC 3261 - SIP  2.0
>              Request-Line   =  Method SP Request-URI SP SIP-Version CRLF
> 
>           mrcp-07 - MRCPv1
>               request-line   =  method-name SP request-id SP
>           mrcp-version CRLF
> 
>               event-line     =    event-name SP request-id SP
>           request-state SP
>           mrcp-version CRLF
> 
>           Thanks,
> 
>           Brett Gavagni
>           (561) 862-2097 T/L (975)
>           "Shanmugham, Saravanan" <[email-masked]>
>           04/13/2006 12:59 PM
> 
>           To
>           Brett Gavagni/West Palm Beach/IBM@IBMUS,
>      <[email-masked]> cc
> 
>           Subject
>           RE: [Speechsc] message-length clarification
> 
> 
> 
> 
> 
> 
>           Do you see any specific implementation or efficiency issue
>           with the way it is defined today.
> 
> 
>           Sarvi
> 
>                -----Original Message-----
>                From: Brett Gavagni [mailto:[email-masked]]
>                Sent: Thursday, April 13, 2006 8:21 AM
>                To: [email-masked]
>                Subject: [Speechsc] message-length clarification
> 
>                What is the reasoning for including the length of the
>                start-line in the message-length value?
> 
>                Seems a bit inconsistent with other textual based
>                protocols including: SIP 2.0, HTTP 1.1, or even MRCPv1.
> 
>                   beginning of the message.  This is to make
>      the framing
>                and parsing of
>                I hope that this is just a wording problem as
>      even some of
>                the examples don't have an accurate message-length value
>                w.r.t draft-9 wording.
> 
>                Propose to modify the wording that
>      message-length does NOT
>                include the start-line as an issue to track for the
>           next draft.
> 
>                Thanks,
> 
>                Brett Gavagni

---

From: "Bergallo Patrizio" <[email-masked]>
Date: Fri, 14 Apr 2006 10:43:34 +0200

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. 

> From: Pete Cordell [mailto:[email-masked]] 
> Sent: Friday, April 14, 2006 9:55 AM
> To: Dave Burke
> Cc: [email-masked]
> 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) 
> =============================================
> 
> From: "Dave Burke" <[email-masked]>
> To: "Shanmugham, Saravanan" <[email-masked]>; "Brett Gavagni" 
> <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, April 14, 2006 12:39 AM
> > This is because the message-length also includes the number 
> of bytes 
> > that
> > 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
> >
> > For example, if N=97 then M=2 and N+M=99=message-length. 
> However, if 
> > N=98
> > 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 
> > start-line in entirety, as it is at least redundant and 
> deviating from 
> > the HTTP-like conventions leveraged throughout the spec.
> >
> > Thanks,
> >
> > Brett Gavagni
> ...cut... 
> [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
================================================

---

From: "Carter, Jerry" <[email-masked]>
Date: Wed, 19 Apr 2006 10:19:34 -0400

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

> From: Burger, Eric [mailto:[email-masked]]
> Sent: Tuesday, April 18, 2006 5:52 PM
> To: Dave Burke; Corby Anderson; Brett Gavagni
> Cc: [email-masked]; Shanmugham, Saravanan; Bergallo Patrizio
> Any takers?  I'm with option 2, as that leaves things as it and is
> workable.
> 
> Sent: Monday, April 17, 2006 12:57 PM
> To: Corby Anderson; Brett Gavagni
> Cc: [email-masked]; Shanmugham, Saravanan; Bergallo Patrizio
> 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
> 
> To: "Corby Anderson" <[email-masked]>
> Cc: <[email-masked]>; "Shanmugham, Saravanan" <[email-masked]>;
> "Bergallo Patrizio" <[email-masked]>
> Sent: Monday, April 17, 2006 3:42 PM
> > 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
> > "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:
> > 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
> > 04/14/2006 02:06 PM
> > "Bergallo Patrizio" <[email-masked]>,
> <[email-masked]>
> > cc
> >
> > Subject
> > 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]
> > From: "Dave Burke"
> > To: "Shanmugham, Saravanan" ; "Brett Gavagni"
> >
> > Cc:
> > specify the message-length in the header. The algorithm for
> >
> > determining
> >
> > From: "Brett Gavagni"
> > To: "Shanmugham, Saravanan"
> > Cc:
> > 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

---

From: "Reifenrath, Klaus, VF-Group" <[email-masked]>
Date: Wed, 19 Apr 2006 17:21:54 +0200

I am very much in favor to remove the message length from the startline, because it is not very useful. 
 
For a similar discussion (that took place quite some time ago!) please see http://www1.ietf.org/mail-archive/web/speechsc/current/msg00690.html.
If we change the startline please let us revisit this as well!
 
Regards,
Klaus

________________________________

	From: Baggia Paolo [mailto:[email-masked]] 
	Sent: Mittwoch, 19. April 2006 16:36
	To: Carter, Jerry; [email-masked]
	Cc: Bergallo Patrizio
	Subject: R: [Speechsc] message-length clarification

	Jerry,
	
	with reference to Eric Burger's e-mail
	"[Speechsc] Finishing in Our Lifetime", in our opinion,
	this issue is not a Priority 1 or Priority 2 one.
	
	Our preference is to be conservative as much as is 
	possible, so we prefer to leave the current behaviour. 
	We can live with #2 (zero-padding).
	
	The worst is #1 "remove message-length".
	
	Paolo&Patrizio
	
	-----Messaggio originale-----
	Da: Carter, Jerry [mailto:[email-masked]] 
	Inviato: mercoledì 19 aprile 2006 16.20
	A: [email-masked]
	Oggetto: RE: [Speechsc] message-length clarification

	> To: "Corby Anderson" 
	> Cc: ; "Shanmugham, Saravanan" ;
	> "Bergallo Patrizio" 
	> > "Shanmugham, Saravanan" , [email-masked], Bergallo
	> > Patrizio 
	> > Subject
	> > "Shanmugham, Saravanan" 
	> > "Bergallo Patrizio" ,
	> > [email-masked]. Thank
	> you
	> > www.loquendo.com

	
	<mailto:[email-masked]>[email-masked]. Thank you