Subject: RE: [speechsc] CONTROL/STOP requests in idle state

From: "Shanmugham, Saravanan" <[email-masked]>
Date: Mon, 1 May 2006 13:45:49 -0700

hmm.. Interesting. :-)
 
We should ideally try to keep this behaviour consistent across all
resources. 
 
So, I propose we extend this clarification across all resources.
recognizer, recorder, verification etc. 
 
Also, any reason, why this should succeed with a 200 OK and not return a
402 failure.
 
I am comparing a STOP/CONTROL to how we treat PAUSE/RESUME methods.
There we seem to return 402 if there was no SPEAK request active, and
200 OK if a SPEAK was active(paused or not paused). 
 
Though we could, based on this claim that STOP should return 402. But I
am not going to go that route.
 
Instead, I am interpreting it as, meaning, if the command/method was
able to achieve its target intended state, we should return 200 OK or
else return 402.
 
That leads me to saythat , the STOP method, when there is no request
active DOES leave the resource in the intended target state, so
returning a 200 OK seems inline with that thinking.  And this logic
applies to pretty much all resources.
 
But CONTROL on the other hand DOES NOT, achieve its goal when there is
no SPEAK request active. So I propose it should return 402 just like
PAUSE/RESUME. 

Thx,
Sarvi

________________________________

	From: Dave Burke [mailto:[email-masked]] 
	Sent: Monday, May 01, 2006 6:32 AM
	To: [email-masked]
	Subject: [speechsc] CONTROL/STOP requests in idle state

	Would be nice to clarify that a CONTROL or STOP request which
doesn't "catch" an IN-PROGRESS SPEAK request still returns a response
with status code 200 albeit without a Active-Request-Id-List. I could
easily imagine an implementor mistakenly assume a 402 Method not valid
in this state should be returned.
	 
	Dave

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

---

From: "Dave Burke" <[email-masked]>
Date: Mon, 1 May 2006 22:30:08 +0100

Works for me. 

Dave
  ----- Original Message ----- 
  From: Shanmugham, Saravanan 
  To: Dave Burke ; [email-masked] 
  Sent: Monday, May 01, 2006 9:45 PM
  Subject: RE: [speechsc] CONTROL/STOP requests in idle state

  hmm.. Interesting. :-)

  We should ideally try to keep this behaviour consistent across all resources. 

  So, I propose we extend this clarification across all resources. recognizer, recorder, verification etc. 

  Also, any reason, why this should succeed with a 200 OK and not return a 402 failure.

  I am comparing a STOP/CONTROL to how we treat PAUSE/RESUME methods. There we seem to return 402 if there was no SPEAK request active, and 200 OK if a SPEAK was active(paused or not paused). 

  Though we could, based on this claim that STOP should return 402. But I am not going to go that route.

  Instead, I am interpreting it as, meaning, if the command/method was able to achieve its target intended state, we should return 200 OK or else return 402.

  That leads me to saythat , the STOP method, when there is no request active DOES leave the resource in the intended target state, so returning a 200 OK seems inline with that thinking.  And this logic applies to pretty much all resources.

  But CONTROL on the other hand DOES NOT, achieve its goal when there is no SPEAK request active. So I propose it should return 402 just like PAUSE/RESUME. 

  Thx,
  Sarvi

----------------------------------------------------------------------------
    From: Dave Burke [mailto:[email-masked]] 
    Sent: Monday, May 01, 2006 6:32 AM
    To: [email-masked]
    Subject: [speechsc] CONTROL/STOP requests in idle state

    Would be nice to clarify that a CONTROL or STOP request which doesn't "catch" an IN-PROGRESS SPEAK request still returns a response with status code 200 albeit without a Active-Request-Id-List. I could easily imagine an implementor mistakenly assume a 402 Method not valid in this state should be returned.

    Dave

---

From: Brett Gavagni <[email-masked]>
Date: Mon, 1 May 2006 17:37:06 -0400

That sounds reasonable, and good catch for consistency across the 
resources.

Thanks,

Brett Gavagni 
WebSphere Voice Server Development 
http://www-306.ibm.com/software/pervasive/voice_server/ 
[email-masked]

"Dave Burke" <[email-masked]> 
05/01/2006 05:30 PM

To
"Shanmugham, Saravanan" <[email-masked]>, <[email-masked]>
cc

Subject
Re: [speechsc] CONTROL/STOP requests in idle state

Works for me. 
 
Dave
----- Original Message ----- 
From: Shanmugham, Saravanan 
To: Dave Burke ; [email-masked] 
Sent: Monday, May 01, 2006 9:45 PM
Subject: RE: [speechsc] CONTROL/STOP requests in idle state

hmm.. Interesting. :-)

 
 
I am comparing a STOP/CONTROL to how we treat PAUSE/RESUME methods. There 
we seem to return 402 if there was no SPEAK request active, and 200 OK if 
a SPEAK was active(paused or not paused). 
 
Though we could, based on this claim that STOP should return 402. But I am 
not going to go that route.
 
Instead, I am interpreting it as, meaning, if the command/method was able 
to achieve its target intended state, we should return 200 OK or else 
return 402.
 
That leads me to saythat , the STOP method, when there is no request 
active DOES leave the resource in the intended target state, so returning 
a 200 OK seems inline with that thinking.  And this logic applies to 
pretty much all resources.
 
But CONTROL on the other hand DOES NOT, achieve its goal when there is no 
SPEAK request active. So I propose it should return 402 just like 
PAUSE/RESUME. 

Thx,
Sarvi

Would be nice to clarify that a CONTROL or STOP request which doesn't 
"catch" an IN-PROGRESS SPEAK request still returns a response with status 
code 200 albeit without a Active-Request-Id-List. I could easily imagine 
an implementor mistakenly assume a 402 Method not valid in this state 
should be returned.
 
Dave_______________________________________________
Speechsc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speechsc

---

From: Jerry Carter <[email-masked]>
Date: Mon, 1 May 2006 18:00:47 -0400

Sounds good.

On May 1, 2006, at 4:45 PM, Shanmugham, Saravanan wrote:

> So, I propose we extend this clarification across all 
> resources. recognizer, recorder, verification etc. 
>  
>> "catch" an IN-PROGRESS SPEAK request still returns a response with 
>> status code 200 albeit without a Active-Request-Id-List. I could 
>> easily imagine an implementor mistakenly assume a 402 Method not 
>> valid in this state should be returned.
>>