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

From: "Saravanan Shanmugham \(sarvi\)" <[email-masked]>
Date: Fri, 16 Jun 2006 10:01:08 -0700

The general principle across all method requests is that the
Active-Request-Id-List header in the response to that method request
MUST contain the list of all pending/in-progress request-ids that were
affected by this method request.

Hence for STOP command's response, would return only those request-ids
that were stopped by that STOP method. If certain request were
idle/completed or stopped earlier, their request ids will not be on this
return list. 

A client would keep track of methods that had responded with a PENDING
or IN-PROGRESS state and later expect a *-COMPLETE. Note that this
request-id list information in the STOP response is also used by the
client, to stop expecting *-COMPLETE event in future.

In regards with the original request for clarification, the STOP
response  Active-Request-Id-List being empty is already clear in the
document. I agree we can further clarify that it MUST respond with 200
OK in this case. 

Thanks,
Sarvi  

     -----Original Message-----
     From: Dan Burnett [mailto:[email-masked]] 
     Sent: Tuesday, June 13, 2006 3:44 AM
     To: Dave Burke; [email-masked]
     Subject: Re: [speechsc] CONTROL/STOP requests in idle state
     
     The thread on this was fairly clear, but I have a question 
     about the Active-Request-Id-List.  Do you really want it 
     to be left out?
     
     In the more general case, where one STOP request is 
     applied to a list of requests via the 
     Active-Request-Id-List, what should be returned in the 
     response's Active-Request-Id-List if, say, some of the 
     requests were stopped and one or more were already idle?
     
     -- dan
     
     --- Dave Burke <[email-masked]> wrote:
     
     > 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
     > 

     __________________________________________________
     Do You Yahoo!?
     Tired of spam?  Yahoo! Mail has the best spam protection 
     around http://mail.yahoo.com 
     
     _______________________________________________
     Speechsc mailing list
     [email-masked]
     https://www1.ietf.org/mailman/listinfo/speechsc

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

---

From: "Saravanan Shanmugham \(sarvi\)" <[email-masked]>
Date: Fri, 16 Jun 2006 10:08:35 -0700

In the scenario described below, a SPEAK request was IN-PROGRESS
(irrespective of whether it was paused or active. Hence the 200 OK
reponse to the RESUME method MUST carry a Active-Request-Id-List header
with the request-id of the SPEAK request IN-PROGRESS as that was the one
affected.

Whether SPEAK was already PAUSED/ACTIVE, the RESUME method made sure it
was ACTIVE when its done, hence affecting the SPEAK reuqets in-progress.

I think the confusion is in "If a SPEAK request was active the " which
should read "If a SPEAK request was IN-PROGRESS".

Sarvi

     -----Original Message-----
     From: Dan Burnett [mailto:[email-masked]] 
     Sent: Wednesday, June 14, 2006 3:48 AM
     To: Dave Burke; [email-masked]
     Subject: Re: [speechsc] CONTROL/STOP requests in idle state
     
     I tend to agree with you.  What do you think of this text 
     in RESUME (sec. 8.10)?
     
     'If a RESUME request is issued on a session with an active 
     SPEAK request that is speaking (i.e., not
     paused) the server SHOULD respond with a status of 200 
     "Success". If a SPEAK request was active the server MUST 
     return an active-request-id-list header with the 
     request-id of the SPEAK request that was resumed.'
     
     This can be interpreted in a way that matches your 
     understanding, below, but it can also be interpreted as 
     the opposite, i.e. that because the target state was 
     achieved the request-id must be included.
     How do you interpret this method's behavior?
     
     -- dan
     
     --- Dave Burke <[email-masked]> wrote:
     
     > Here's my take / understanding:
     > 
     > In a response, the Active-Request-Id-List indicates the requests 
     > affected by the request. If a STOP request is applied to several 
     > requests and some of those were idle (hence not 
     affected), then those 
     > idle requests do not appear in the 
     Active-Request-Id-List header field 
     > value in the response. In the special case that no requests were 
     > affected, we're saying that an empty list manifests as 
     an omitted 
     > Active-Request-Id-List header field in the response.
     > 
     > Dave
     > 
     > 
     > ----- Original Message -----
     > From: "Dan Burnett" <[email-masked]>
     > To: "Dave Burke" <[email-masked]>; <[email-masked]>
     > Sent: Tuesday, June 13, 2006 11:43 AM
     > > The thread on this was fairly clear, but I have a 
     question about the 
     > > Active-Request-Id-List.  Do you really want it to be left out?
     > >
     Active-Request-Id-List, what 
     > > should be returned in
     > the
     > >> 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
     > > Tired of spam?  Yahoo! Mail has the best spam
     > protection around
     > > http://mail.yahoo.com
     > > 
     > 
     >