Subject: RE: [Speechsc] Status & Completion Cause Codes

From: "Thomas Gal" <[email-masked]>
Date: Tue, 21 Sep 2004 13:36:00 -0700

Comments in-line 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Reifenrath, Klaus
> Sent: Wednesday, September 15, 2004 2:01 AM
> To: [email-masked]'
> Cc: [email-masked]'; [email-masked]'
> Subject: RE: [Speechsc] Status & Completion Cause Codes
> 
> Hi all,
> 
> error handling is an important issue. Only if MRCP server 
> return meaningful and well defined error codes MRCP clients 
> can handle error situations in a suitable way. Therefore I 
> like to keep this discussion thread alive! I like to get 
> feedback on my suggestion to follow the 2/4/5 convention for 
> the status code and the proposed new status codes.
> 
> Some more status codes that seem to be useful:
> 
> 503 Server Time-out
> The server did not receive a timely response from an external 
> server it accessed in attempting to process the request. 
> 

I'd rather see this a little better defined. What you describe seems more
like a network timeout in the context of the server which I agree with.
Server time-out to me implies that the server is overloaded and is
redjecting the request due to workload (maybe analagous to a router buffer)
but I think this would easily be handled with the SIP BUSY-HERE response?

> 504 Message Too Large
> The server was unable to process the request since the 
> message length exceeded its capabilities.
> 

This seems ambiguous, and more a limitation of the implementation. I think
this should be folded into a more generic error message. If this is a
problem for someones customers than this strikes me as something that is an
underlying limitation in something that MRCP is designed to abstract away,
and should be dealt with internally.

-Tom

> Klaus
> 
> -----Original Message-----
> From: Reifenrath, Klaus [mailto:[email-masked]]
> Sent: Montag, 16. August 2004 09:04
> To: [email-masked]'
> Cc: [email-masked]'; [email-masked]'
> Subject: FW: [Speechsc] Status & Completion Cause Codes
> 
> 
> Hi Eric,
> 
> I resend this mail, because I think the Status Codes needs to 
> be discussed together with the Completion Cause codes.
> 
> If we follow the 2/4/5 convention for the Status Code, the 
> 2/4 convention for the Completion Cause adds not much value, right?
> 
> Klaus 
> 
> -----Original Message-----
> From: Reifenrath, Klaus [mailto:[email-masked]]
> Sent: Freitag, 7. Mai 2004 13:56
> To: [email-masked]'
> Subject: [Speechsc] Status Codes
> 
> 
> SIP distinguishes between 4xx and 5xx error codes:
> 4xx: Client Error -- the request contains bad syntax or 
> cannot be fulfilled at this server;
> 5xx: Server Error -- the server failed to fulfil an 
> apparently valid request;
> 
> This seems to be useful also for MRCP.
> 
> I think the following status codes should be added to the spec:
> 
> 410 Unsupported Media Type
> The server is refusing to service the request because the 
> message body of the request is in a format not supported by 
> the requested resource for the requested method. 
> 
> Unfortunately there is currently no mechanism in place to 
> find out which media types are supported by a resource.
> 
> 411 Length Required
> The server refuses to accept the request without a defined 
> Content- Length. The client MAY repeat the request if it adds 
> a valid Content-Length header field containing the length of 
> the message-body in the request message.
> 
> 500 Server Internal Error (would replace 407) The server 
> encountered an unexpected condition that prevented it from 
> fulfilling the request. The client MAY display the specific 
> error condition, and MAY retry the request.
> 
> 501 Not Implemented
> The server does not support the functionality required to 
> fulfil the request. This is the appropriate response when the 
> resource does not recognize the request method and is not 
> capable of supporting it.
> 
> 502 Version Not Supported
> The server does not support, or refuses to support, the MRCP 
> protocol version that was used in the request message. The 
> server is indicating that it is unable or unwilling to 
> complete the request using the same major version as the 
> client, other than with this error message. 
> 
> What error code should be returned by a server if the client 
> tries to set an unsupported vendor specific parameter?
> 403 (unsupported parameter) seems not to be right, because 
> the MRCP parameter 'vendor-specific-parameter' is supported.
> 404 (illegal value for parameter) could be used, but is misleading
> 
> 
> Regards,
> Klaus
> 
> _______________________________________________
> Speechsc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speechsc
> 
> _______________________________________________
> Speechsc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speechsc
> 
> _______________________________________________
> Speechsc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speechsc
> 

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