Subject: [Speechsc] Handling grammar definition errors

From: "Carter, Jerry" <[email-masked]>
Date: Mon, 8 May 2006 10:39:32 -0400

It is worthwhile to review the reporting and handling of invalid grammars.
Consider a recognize containing two invalid URIs and referencing two invalid
grammars.  The message and responses might look something like this:

   C->S:MRCP/2.0 RECOGNIZE 543260

   Channel-Identifier:32AECB23433801@speechrecog

   Content-Type:text/uri-list

   Content-Length:???

   session:http://www.example.com/bad_uri_404.gxml

   session:http://www.example.com/bad_uri_408.gxml

   session:http://www.example.com/bad_grammar1.gxml

   session:http://www.example.com/bad_grammar2.gxml

   S->C:MRCP/2.0 543260 407 IN-PROGRESS

   Channel-Identifier:32AECB23433801@speechrecog

   Completion-Cause:009 uri resolution problem

   Failed-URI-Cause:404

   Failed-URI:http://www.example.com/bad_uri_404.gxml

   S->C:MRCP/2.0 543260 407 IN-PROGRESS

   Channel-Identifier:32AECB23433801@speechrecog

   Completion-Cause:009 uri resolution problem

   Failed-URI-Cause:408

   Failed-URI:http://www.example.com/bad_uri_408.gxml

   S->C:MRCP/2.0 543260 407 COMPLETE

   Channel-Identifier:32AECB23433801@speechrecog

   Completion-Cause:005 grammar violates schema

   Failed-URI:http://www.example.com/bad_grammar1.gxml

   Failed-URI:http://www.example.com/bad_grammar2.gxml

(1) Is there any benefit to having separate 'Failed-URI-Cause' and
'Failed-URI' messages?  These should be combined.  Then, the messages for
the first two errors could also be merged.

   S->C:MRCP/2.0 543260 407 IN-PROGRESS

   Channel-Identifier:32AECB23433801@speechrecog

   Completion-Cause:009 uri resolution problem

   Failed-URI:http://www.example.com/bad_uri_404.gxml 404

   Failed-URI:http://www.example.com/bad_uri_408.gxml 408

(2) The specification does not dictate today whether a client must process
all the grammars before RECOGNIZE / DEFINE-GRAMMAR are complete.  The MRCP
specification should say this: RECOGNIZE MAY terminate after the first error
but DEFINE-GRAMMAR SHOULD attempt to process the entire list of grammars.

(3) What is the difference between 004 (grammar-load-failure) and 005
(grammar-compilation-failure)?  Would a client ever care?  If the answer is
no, then 004 should be retained and 005 eliminated since load is required
and compilation is an implementation detail.

(4) More failure examples in the specification would be helpful.

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

---

From: "Shanmugham, Saravanan" <[email-masked]>
Date: Wed, 10 May 2006 12:01:28 -0700

comments inline

________________________________

	From: Carter, Jerry [mailto:[email-masked]] 
	Sent: Monday, May 08, 2006 7:40 AM
	To: [email-masked]
	Subject: [Speechsc] Handling grammar definition errors

	It is worthwhile to review the reporting and handling of invalid
grammars.  Consider a recognize containing two invalid URIs and
referencing two invalid grammars.  The message and responses might look
something like this:

	   Content-Length:???

	   Failed-URI-Cause:404

	   Failed-URI-Cause:408

	Sarvi>> The above messaging is not supported today. A 407 means
there was a failure and should be return request-state COMPLETE. There
will no more messages or events. 

	(1) Is there any benefit to having separate 'Failed-URI-Cause'
and 'Failed-URI' messages?  These should be combined.  Then, the
messages for the first two errors could also be merged.

	 
	[Sarvi>>]  As of today in a failure response there can be one
Failed URI and an associated Failed URI-Cause. If we want to support
more then one such URI, we need to club the failure cause together with
the uri as consecutive headers and then allow for more than one set of
these. 

	If we want to support more detailed failure information, I like
Dave Oran's suggestion on the topic of SPEAK requests on a different
thread.

	Anyway, for the current spec though the first URI failure and
its cause is what is specified here.

	(2) The specification does not dictate today whether a client
must process all the grammars before RECOGNIZE / DEFINE-GRAMMAR are
complete.  The MRCP specification should say this: RECOGNIZE MAY
terminate after the first error but DEFINE-GRAMMAR SHOULD attempt to
process the entire list of grammars.
	[Sarvi>>] I believe the DEFINE-GRAMMAR should load and compile
grammar before returning a COMPLETE response. Now, I don't believe we
need to specify whether the recognizer should load the entire grammar
and compile even if there are URI failures.  It should be fine if the
recognizer stops its load/compile opertion at the first sign of error
and return that URI and cuase code. When we do support more failed uri
headers or the detailed error block suggested by Dave, the recognizer is
free to do what ur suggesting. There is no point enforcing it now.

	I believe the RECOGNIZE should load and compile grammar before
returning a response. If it was successful it would be 200 and later
come back with a RECOGNITON-COMPLETE event. Else it would be failure
response.

	If the above is not apparent in the document, it will be
clarified.  

	(3) What is the difference between 004 (grammar-load-failure)
and 005 (grammar-compilation-failure)?  Would a client ever care?  If
the answer is no, then 004 should be retained and 005 eliminated since
load is required and compilation is an implementation detail.
	[Sarvi>>] My understading was that depedning on the
recognizer/vendor there is a differntiation between compile
failure(005). and failure to be load a previously compiled grammar into
the recognizer(004). I would suggest leaving it as is, unless I hear
more feed back saying that this causing problems.

	Time permitting.

	Thx,

	Sarvi