Subject: [Speechsc] Loquendo's comments on draft-ietf-speechsc-mrcpv2-06.txt

From: Baggia Paolo <[email-masked]>
Date: Fri, 25 Feb 2005 11:30:42 +0100

Dear Sarvi/Eric/SpeechSC people,

This is the second part of Loquendo's contribution and
unfortunatelly it is after the 06 is being published, but
we were not aware it was going to be released. I apologize.

I checked that all the points we mentioned are still
there in 06, especially for ABNF definition (see D. below).

E. and F. are trouble from our point of view.

Paolo

===========================================================

C. SRGS examples with minor troubles

- the Content-Type are fine: application/srgs+xml
  for XML format and application/srgs for ABNF format
- the file extension should be either .grxml or .gram
  everything is fine
- <grammar> required attributes described in
  http://www.w3.org/TR/2004/REC-speech-grammar-20040316/#S4.1
  they are "xml:lang", "version", but also "xmlns". 
  There are 11 SRGS <grammar> examples but only one
  declares the "xmlns" as required.
- In example at page 71

            <rule id="people1"> 
                    <token lexicon="en-US,fr-CA"> Robert </token> 
            </rule> 

  the "lexicon" attribute is wrong, maybe it was "xml:lang",
  but in that case I'm not sure a double value it is allowed.
  Please let me know what do you think on it. I read RFC3066,
  SRGS 1.0 and XML spec.
  The same error is repeated in page 74, 

- In the same example a "root" attribute would be fine, the
  spec leave it optional but it suggests to declare one,
  for instance root="request"

- In example at page 87. It is aligned with the XML example
  in the SRGS spec, Appendix J.1
  http://www.w3.org/TR/2004/REC-speech-grammar-20040316/#AppJ.1
  The only difference is that the content of the <tag> element
  was a link to Section 1.4 on Semantic Interpretation.

  One option is to eliminate the problem deleting from the
  example the <tag> ... </tag>.

  Another option is to cite the Semantic Interpretation spec
  and add few words on it. This spec is today Last Call WD
  (November 8) but it will become Candidate Rec in a few months.

--------------------------------------------------------------
D. Problems with the ABNF definitions

These comments may be very relevant for the consistency of the
draft in the ABNF definitions. We report many small errors or
missing definitions, but an in-depth and complete revision is
expected. There may be some more that we were not able to 
identify.

d.0) On Section 5 "MRCPv2 Specification"

- "header-extension" definition should be "extension-header"
  ==> DELETED FROM 06

- the definition of "message-length" in Section 5.1, but not into the
  Appendix A.1

- the major problem is that it is not clear from the definition
  what the number of bytes represent. In Section 5.2 it says:
  "The message-length field specifies the length of the message".
  Does the message include the "start-line"? Or it doesn't.
  For interoperability reasons, it should be very clear.
  ==> YOU CLARIFIED THIS ISSUE in Section 5.1

- by looking to some of the simple examples, last event of pag. 16:
  the first two lines include a white space before CRLF
MRCP/2.0 81 543257 200 IN-PROGRESS 
Channel-Identifier: 32AECB23433802@speechsynth 

<<<<
  the Message Length of 81 does not match with any possible
  combination:
  - with start-line:    87 octects

  They are only examples, but the definition is now very clear.

d.1) On generic-header (Section 6.1)

- Channel-Identifier generic header field is said thats consist of 2
  parts (separated by the '@' symbol). 
  "The first part is a 32 bit hexadecimal integer that is positive"
  but all the examples show a hexadecimal integer of 14 characters
  (i.e. 32AECB23433802) instead of 8. Perhaps it was meant to be
  "more than 32 bit hexadecimal" or the examples are wrong.

- set-cookie and set-cookie2: ABNF definition of "generic-header" 
  in pag. 22 includes them, but the definition in pag. 158 does not

- Accept-Charset is described in pag. 24, but it is not present in
  the definition of "generic-header" neither at pag. 22 and not at
  pag. 158

- Vendor-Specific-Parameters is defined in pag. 30 (6.1) as follows:
     vendor-specific     =    "Vendor-Specific-Parameters" ":" 
                              vendor-specific-av-pair  
                              *[";" vendor-specific-av-pair] CRLF  
     vendor-specific-av-pair = vendor-av-pair-name "="  
                              vendor-av-pair-value  

  the following three examples seem to contraddict the definition:
      Example:  
            com.cisco.paramxyz:256 
            com.cisco.paramabc:High 
            com.nuance.paramxyz:Low 

  There are two examples in Section 6.3 (pag. 31), the second is
  fine:
          Vendor-Specific-Parameters:com.mycorp.param1="Company Name"; 
                         com.mycorp.param2="[email-masked]" 

d.2) On synthesizer-method (Section 8.2)

- in 8.1 and 8.2 (pag. 33) shows LOAD-LEXICON method, but 8.14 describes
  DEFINE-LEXICON method (pag. 53); LOAD-LEXICON method is referenced
  as column (G) in pag. 34-35

d.3) On synthesizer-header (Section 8.4)
  It is defined on pag. 39 as:
     fetch-timeout            =    "Fetch-Timeout" ":" 1*DIGIT CRLF 
  and it is defined on pag. 162 as:
       fetch-timeout    =    "Fetch-Timeout" ":" [1*DIGIT] CRLF  

d.4) On recognizer-header (Section 9.4)

- Fetch-Timeout: is defined as ("Fetch-Timeout" ":" 1*ALPHA CRLF) in pag. 65
  which differs from the definition ("Fetch-Timeout" ":" 1*DIGIT CRLF)
  in pag. 39 (for  8.4. Synthesizer Header Fields) and in pagg. 162 and 165.
  By the way is it possible to have to definitions of the same keyword
  in A.1 ABNF Message Definitions

- Cancel-If-Queue Recognizer header field in pag. 67 admits the queueing
  of RECOGNIZE methods and the Recognizer State Machine (page 55) reflects it,
  but RECOGNIZE description in pag. 89 (9.9) states: 
  "If the resource is in the recognizing state, the RECOGNIZE request 
   MUST respond with a failure status."
  We see a contraddiction and we think that the queueing of RECOGNIZE
  commands is a complex feature that may have consequences on the
  interoperability of MRCPv2 applications.

d.5) On recorder-method (Section 10.2)

- START-INPUT-TIMERS in "recorder-method" is shown in pag. 102 (10.2)
  but it is not shown in the ABNF Message Definitions at pag. 167

d.6) On recorder-header (Section 10.4)

- ver-buffer-utterance and start-input-timers header fields are shown in 
  "recorder-header" in pag. 103 (10.4), but not in pag. 167-168

- Trim-Length header field is only mentioned in STOP method (10.7, pag. 108),
  but never defined elsewhere

- Fetch-Timeout header field is not shown in "recorder-header", but it is
  in the "Header Field where" table in pag. 103 and it is not
  described in 10.4. It is also missing from "recorder-header"
  definition in pag. 167-168

d.7) On verification-method (Section 11.2)

- "verification-method" in pag. 112 (11.2) is called
  "verifier-method" in other places 

- GET-INTERMEDIATE-RESULT method in "verification-method" is shown 
  in pag. 112 (11.2), but it is not shown in the ABNF Message 
  Definitions at pag. 166 (in "verifier-method")

- STOP method (11.13) the default value if "Abort-Verification"
  header field is missing seems to be in contraddiction in second
  and third paragraph of Section 11.13

d.8) On verifier-event (section 11.3)

- "verification-event" in pag. 113 (11.3) is called
  "verifier-event" in pag. 166

d.9) On verifier-header (section 11.4)

- "verification-header" in pag. 113 (11.4) is called
  "verifier-header" in other places

- Fetch-Timeout header field is not shown in "verification-header",
  but it is in the "Header Field where" table in pag. 113 and it is 
  not described in 11.4. It is also missing from "verifier-header"
  definition in pag. 166

- Verification-Mode header field the description in pag. 115-116
  speaks of START-SESSION method only, but the table in pag. 114 
  includes also SET-PARAM and GET-PARAM methods

- Adapt-Model header field the description in pag. 116
  speaks of START-SESSION method only, but the table in pag. 114 
  includes also SET-PARAM and GET-PARAM methods

- Save-Waveform header field the description in pag. 118
  speaks of VERIFY method only, but the table in pag. 114 
  includes also SET-PARAM and GET-PARAM methods

- Ver-Buffer-Utterance header field the description in pag. 119
  speaks of VERIFY method only, but the table in pag. 114 
  includes also SET-PARAM and GET-PARAM methods

--------------------------------------------------------------
E. Not clear if it is possible to negotiate the format of
   recognition results

It seems that the only returned format is "NLSML", without
possibility to ask for a different output format.

--------------------------------------------------------------
F. LEXICON

The LOAD-LEXICON/DEFINE-LEXICON method is present 
in Section 8 "Speech Synthesizer Resource", but it is
missing from Section 9. Some recognition engine will
benefit of one or more general lexicons for ASR too.

--------------------------------------------------------------

Best regards,
Paolo Baggia, Loquendo
Patrizio Bergallo, Loquendo
Vittorio Manzone, Loquendo

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 
[email-masked]. Thank you
====================================================================

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