RE: "Protocol" requirement - Session

Just like the traditional web, the definition of session depends on what you want to do with it.  A pair of speech use cases to consider:

1) Tying together multiple speech fragments into a single logical task.  This is similar to the IVR notion of speech, and also to something like finding your bank account balance on the traditional HTML web.  When the task is complete, so is the session.

2) Adapting the channel.  Session doesn't end unless requested by the user.


If the web application is communicating directly with the SS, it could completely handle the first session type.  But if the UA needs to intervene, then we'd need some sort of start and stop session command.  It would also be nice if the UA implicitly added some session token in the requests, but not strictly necessary because the app could do this with parameters.

But to handle the second, we'll require support from the UA.  I don't know much about today's visual browsers, but if the app had programmatic read access to the cookie cache, that would probably suffice.  Ideally we have some sort of device ID, but my guess is that privacy concerns have ruled that out.

I think it's pretty clear we need to rework this requirement.  But I think I'll wait until everyone has a chance to comment on the discussion so far.

Thanks



-----Original Message-----
From: Robert Brown [mailto:Robert.Brown@microsoft.com] 
Sent: Monday, December 13, 2010 4:48 PM
To: Young, Milan; Bjorn Bringert
Cc: public-xg-htmlspeech@w3.org
Subject: RE: "Protocol" requirement - Session

I'm fuzzy on what "session" might mean.  In an IVR app it's kinda obvious -usually the duration of the call, or perhaps of a particular service request that spans calls.

But in the public web, it's unclear.  For example...

1:
I open a web site in my browser and it's speech enabled.  My "session" exists for the entire duration of me using that site.  I close the browser and reopen it next week - same user, same device - and I'm still in the same session, right?

2:
I open two different sites on the same device.  Both sites happen to use the same speech service at the back end.  They're different sites, so they're different sessions, right?  The back end is accumulating acoustic adaptation data for the user across both sessions, but contextual data is being kept separate.

-----Original Message-----
From: public-xg-htmlspeech-request@w3.org [mailto:public-xg-htmlspeech-request@w3.org] On Behalf Of Young, Milan
Sent: Monday, December 13, 2010 11:05 AM
To: Bjorn Bringert
Cc: public-xg-htmlspeech@w3.org
Subject: RE: "Protocol" requirement - Session

Session doesn't make a lot of sense to me unless there is a start and a stop.  So if you disagree on this point, we have more to discuss.

Regarding possible implementation, cookies can be unset.

 
-----Original Message-----
From: Bjorn Bringert [mailto:bringert@google.com]
Sent: Monday, December 13, 2010 2:07 AM
To: Young, Milan
Cc: public-xg-htmlspeech@w3.org
Subject: Re: "Protocol" requirement - Session

This seems reasonable to me, as long as it doesn't imply that there is a requirement for web apps or UAs to close the sessions. HTTP cookies does not have such a mechanism.

/Bjorn

On Fri, Dec 10, 2010 at 7:44 PM, Young, Milan <Milan.Young@nuance.com> wrote:
> Summary - Web application and speech services must have a means of 
> binding session information to communications.
>
>
>
> Description - This requirement applies to both local and remote services.
> HTTP cookies is an example of such a feature.  This requirement is 
> needed, for example, to support features like channel adaptation.
>
>



--
Bjorn Bringert
Google UK Limited, Registered Office: Belgrave House, 76 Buckingham Palace Road, London, SW1W 9TQ Registered in England Number: 3977902

Received on Tuesday, 14 December 2010 04:19:27 UTC