RE: [Speechsc] message-length clarification

[Brett Gavagni <[e-mail]>]

Sarvi,

As requested, we've identified at least one inefficient and redundant 
impact w.r.t message-length wording in the current draft (+1 byte 
calculation scenario).

I've received confirmation that the examples are incorrect w.r.t current 
message-length definition, and a "too late to make changes" response. 

I thought that I remembered reading from the mailing list that we were 
expecting at least one more draft to be published before getting to the 
RFC editor queue, and so why would we (as a community) not want to correct 
any identified problematic issues in advance? 

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 10:15 AM

To
"Carter, Jerry" <[e-mail]>, "Dave Burke" 
<[e-mail]>
cc
[e-mail]
Subject
RE: [Speechsc] message-length clarification






Jerry,
    I don't think the argument ever was that it was broken when we got
here. 

We got to the current header format after some long deliberation on the
best format for the parser and after weighing the cost difference for
the encoder in putting the length field where it is. The cost difference
for the encoder was found to be none or negligible compared to where it
is in HTTP/SIP while the advantage for the decoder was found to be
significant. The additional cost for the encoder is a decision of
whether to adjust the length by 1.

And hence the current choice. 

Have I missed something here.

I haven't heard an argument more significant than, its different from
SIP/HTTP so far.

Sarvi 

     -----Original Message-----
     From: Carter, Jerry [mailto:[e-mail]] 
     Sent: Thursday, April 13, 2006 6:13 PM
     To: Dave Burke
     Cc: [e-mail]
     Subject: RE: [Speechsc] message-length clarification
 
     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:[e-mail]]
     > Sent: Thursday, April 13, 2006 7:39 PM
     > To: Shanmugham, Saravanan; Brett Gavagni
     > Cc: [e-mail]
     > 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" <[e-mail]>
     > To: "Shanmugham, Saravanan" <[e-mail]>
     > Cc: <[e-mail]>
     > 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]
     > 
     > 
     > 
     > 
     > "Shanmugham, Saravanan" <[e-mail]>
     > 04/13/2006 04:21 PM
     > 
     > To
     > Brett Gavagni/West Palm Beach/IBM@IBMUS cc 
     <[e-mail]> 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:[e-mail]]
     >      Sent: Thursday, April 13, 2006 12:39 PM
     >      To: Shanmugham, Saravanan
     >      Cc: [e-mail]
     >      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/
     >      [phone] T/L (975)
     >      [e-mail]
     > 
     > 
     > 
     > 
     >      "Shanmugham, Saravanan" <[e-mail]>
     >      04/13/2006 02:25 PM
     > 
     >      To
     >      Brett Gavagni/West Palm Beach/IBM@IBMUS
     >      cc
     >      <[e-mail]>
     >      Subject
     >      RE: [Speechsc] message-length clarification
     > 
     > 
     > 
     > 
     > 
     > 
     >      See inline.
     > 
     >           -----Original Message-----
     >           From: Brett Gavagni [mailto:[e-mail]]
     >           Sent: Thursday, April 13, 2006 10:52 AM
     >           To: Shanmugham, Saravanan
     >           Cc: [e-mail]
     >           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/
     >           [e-mail]
     > 
     > 
     > 
     > 
     >           "Shanmugham, Saravanan" <[e-mail]>
     >           04/13/2006 12:59 PM
     > 
     >           To
     >           Brett Gavagni/West Palm Beach/IBM@IBMUS,
     >      <[e-mail]> 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:[e-mail]]
     >                Sent: Thursday, April 13, 2006 8:21 AM
     >                To: [e-mail]
     >                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/
     >                [e-mail]
     > 
     > 
     >                _______________________________________________
     >                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