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" <gavagni@us.ibm.com>
To: "Shanmugham, Saravanan" <sarvi@cisco.com>
Cc: <speechsc@ietf.org>
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@us.ibm.com




"Shanmugham, Saravanan" <sarvi@cisco.com>
04/13/2006 04:21 PM

To
Brett Gavagni/West Palm Beach/IBM@IBMUS
cc
<speechsc@ietf.org>
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:gavagni@us.ibm.com]
     Sent: Thursday, April 13, 2006 12:39 PM
     To: Shanmugham, Saravanan
     Cc: speechsc@ietf.org
     Subject: RE: [Speechsc] message-length clarification

     My comments in-line.

     Thanks,

     Brett Gavagni
     WebSphere Voice Server Development
     http://www-306.ibm.com/software/pervasive/voice_server/
     (561) 862-2097 T/L (975)
     gavagni@us.ibm.com




     "Shanmugham, Saravanan" <sarvi@cisco.com>
     04/13/2006 02:25 PM

     To
     Brett Gavagni/West Palm Beach/IBM@IBMUS
     cc
     <speechsc@ietf.org>
     Subject
     RE: [Speechsc] message-length clarification






     See inline.

          -----Original Message-----
          From: Brett Gavagni [mailto:gavagni@us.ibm.com]
          Sent: Thursday, April 13, 2006 10:52 AM
          To: Shanmugham, Saravanan
          Cc: speechsc@ietf.org
          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
          WebSphere Voice Server Development
          http://www-306.ibm.com/software/pervasive/voice_server/
          (561) 862-2097 T/L (975)
          gavagni@us.ibm.com




          "Shanmugham, Saravanan" <sarvi@cisco.com>
          04/13/2006 12:59 PM

          To
          Brett Gavagni/West Palm Beach/IBM@IBMUS,
     <speechsc@ietf.org> 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:gavagni@us.ibm.com]
               Sent: Thursday, April 13, 2006 8:21 AM
               To: speechsc@ietf.org
               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.

               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/
               gavagni@us.ibm.com


               _______________________________________________
               Speechsc mailing list
               Speechsc@ietf.org
               https://www1.ietf.org/mailman/listinfo/speechsc






_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc


_______________________________________________
Speechsc mailing list
Speechsc@ietf.org
https://www1.ietf.org/mailman/listinfo/speechsc