Subject: RE: [Speechsc] message-length clarification

From: "Shanmugham, Saravanan" <[email-masked]>
Date: Thu, 13 Apr 2006 13:21:42 -0700

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
     WebSphere Voice Server Development
     http://www-306.ibm.com/software/pervasive/voice_server/
     (561) 862-2097 T/L (975)
     [email-masked]

     
     "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
          WebSphere Voice Server Development
          http://www-306.ibm.com/software/pervasive/voice_server/
          (561) 862-2097 T/L (975)
          [email-masked]

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

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

---

From: Brett Gavagni <[email-masked]>
Date: Thu, 13 Apr 2006 16:52:27 -0400

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 

04/13/2006 04:21 PM

To

Hi Bret, 

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

 
 
     To

 
     See inline. 
 
          -----Original Message-----

 

 
 
     6.1.1.  SET-PARAMS

 

 

 
 
     Thx,
     Sarvi
 
          MRCPv2

 
 
          RFC 2616 - HTTP 1.1
 
          RFC 3261 - SIP  2.0
 
          mrcp-07 - MRCPv1 

          Thanks,
 
          Brett Gavagni

 
 
          To
 
          Subject

 

          Sarvi
 
               -----Original Message-----

 

               5.2.  Request

               5.3.  Response

                
               Internet-Draft                   MRCPv2 
               December 2005

 
               Thanks,
 
               Brett Gavagni

---

From: "Dave Burke" <[email-masked]>
Date: Thu, 13 Apr 2006 16:39:13 -0700

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,

Thanks,

Brett Gavagni

To

Hi Bret,

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

     To

     See inline.

          -----Original Message-----

     6.1.1.  SET-PARAMS

     Thx,
     Sarvi

          MRCPv2

          RFC 2616 - HTTP 1.1

          RFC 3261 - SIP  2.0

          mrcp-07 - MRCPv1

          Thanks,

          Brett Gavagni

          To

          Subject

          Sarvi

               -----Original Message-----

               5.2.  Request

               5.3.  Response

               Internet-Draft                   MRCPv2
               December 2005

               Thanks,

               Brett Gavagni

---

From: "Pete Cordell" <[email-masked]>
Date: Fri, 14 Apr 2006 08:55:28 +0100

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" <[email-masked]>
To: "Shanmugham, Saravanan" <[email-masked]>; "Brett Gavagni" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Friday, April 14, 2006 12:39 AM
Subject: Re: [Speechsc] message-length clarification

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