Subject: [Speechsc] Some doubts on draft-ietf-speechsc-mrcpv2-09.txt

From: Rocky Wang <[email-masked]>
Date: Mon, 13 Feb 2006 15:38:41 +0800

Hello, all,
    I'm a newcomer of SPEECHSC work group and also MRCPv2 protocol. I
have read the draft (draft-ietf-speechsc-mrcpv2-09.txt) and have some
doubts want to get some clarification.
    1. In MRCP messages, including request, response and event packets,
there is a field called "message-length". I want to know why put it here
but not using some other technologies like TPKT to resolve such a
problem? I think there are some disadvantages in using of this appoaches
because the receiver of the message must do partial parsing then know
get it. Why not add a seperator between messages? In the seperator, you
can define a field "message-length" to take the length. Because it can
be encoding in binary mode, the receiver can extract such informations
easier.
    2. Why not make the 3 types of messages looks more uniform?
        request-line   =    mrcp-version SP message-length SP
method-name
                       SP request-id CRLF
        response-line  =    mrcp-version SP message-length SP request-id
                                    SP status-code SP request-state CRLF
        event-line       =  mrcp-version SP message-length SP event-name
                                    SP request-id SP request-state CRLF
        Because all the messages will take mrcp-version, message-length,
request-id and channel identifier, why not put them together in the
beginning of the message but define a different format for each type?
    3. Why select ABNF but not some binary message format? Forgive me
for such a stupid question but I don't think there are any advantage for
MRCP protocol.

Thanks and Best Regards,
Rocky Wang

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

---

From: "Shanmugham, Saravanan" <[email-masked]>
Date: Wed, 22 Feb 2006 17:55:56 -0800

Comments inline. 

     -----Original Message-----
     From: [email-masked] 
     [mailto:[email-masked]] On Behalf Of Rocky Wang
     Sent: Sunday, February 12, 2006 11:39 PM
     To: [email-masked]
     Subject: [Speechsc] Some doubts on 
     draft-ietf-speechsc-mrcpv2-09.txt
     
     Hello, all,
         I'm a newcomer of SPEECHSC work group and also MRCPv2 
     protocol. I have read the draft 
     (draft-ietf-speechsc-mrcpv2-09.txt) and have some doubts 
     want to get some clarification.
         1. In MRCP messages, including request, response and 
     event packets, there is a field called "message-length". I 
     want to know why put it here but not using some other 
     technologies like TPKT to resolve such a problem? I think 
     there are some disadvantages in using of this appoaches 
     because the receiver of the message must do partial 
     parsing then know get it. Why not add a seperator between 
     messages? In the seperator, you can define a field 
     "message-length" to take the length. Because it can be 
     encoding in binary mode, the receiver can extract such 
     informations easier.
Sarvi> This issue has been previously discussed on the alias and the
trade-offs evaluated. Please refer to one of the older threads on this
decision. Efficiency is one of the reasons the message-length is at a
fixed location(2nd token) from the beginning of the message.

         2. Why not make the 3 types of messages looks more uniform?
             request-line   =    mrcp-version SP message-length SP
     method-name
                            SP request-id CRLF
             response-line  =    mrcp-version SP message-length 
     SP request-id
                                         SP status-code SP 
     request-state CRLF
             event-line       =  mrcp-version SP message-length 
     SP event-name
                                         SP request-id SP 
     request-state CRLF
             Because all the messages will take mrcp-version, 
     message-length, request-id and channel identifier, why not 
     put them together in the beginning of the message but 
     define a different format for each type?

I guess there was no particular reason for this. MRCPv2 is derived
primarily from MRCPv1 and headers have been kept similar. Where ever
there are common fields they have been kept in the same order as the
other messages. Between the response and event messages There was some
care taken to make sure that we could differentiate between a response
and an event. 
Apart from that there was no particular reason for thhis choice of field
sequence.

         3. Why select ABNF but not some binary message format? 
     Forgive me for such a stupid question but I don't think 
     there are any advantage for MRCP protocol.
Again, the issue of binary Vs text protocol has come up and their
benefits discussed on the thread. Please refer to one of the older
threads on this topic.

Thanks,
Sarvi 
     
     Thanks and Best Regards,
     Rocky Wang