RE: "Protocol" requirement - Session

Maybe I've misunderstood.  Does the document.cookie API support setting cookies, or just reading them?



-----Original Message-----
From: Robert Brown [mailto:Robert.Brown@microsoft.com] 
Sent: Tuesday, December 14, 2010 9:26 AM
To: Young, Milan; Bjorn Bringert
Cc: public-xg-htmlspeech@w3.org
Subject: RE: "Protocol" requirement - Session

I assume you mean this one:
> 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.

In this case, isn't the "task" just something that's defined by the application?  This seems very similar to when a web site remembers my recently browsed items, shopping cart, etc.  Why wouldn't a cookie be sufficient?

-----Original Message-----
From: Young, Milan [mailto:Milan.Young@nuance.com] 
Sent: Tuesday, December 14, 2010 9:19 AM
To: Bjorn Bringert
Cc: Robert Brown; public-xg-htmlspeech@w3.org
Subject: RE: "Protocol" requirement - Session

I agree that document.cookie is sufficient to handle the second use case, but not the first.  We need either direct communication or support from the UA to mark the beginning and end of the task.

Thanks

-----Original Message-----
From: Bjorn Bringert [mailto:bringert@google.com]
Sent: Tuesday, December 14, 2010 4:02 AM
To: Young, Milan
Cc: Robert Brown; public-xg-htmlspeech@w3.org
Subject: Re: "Protocol" requirement - Session

There is already a JavaScript API for cookies (document.cookie). I think that cookies should be sufficient, and if there is some use case that you can't handle with cookies or other existing mechanisms for client-side persistence, we'll have to punt on that use case.
Introducing new mechanisms that can be used to track users is very unlikely to be accepted by browser vendors.

A device ID is not only a privacy no-no, it's also not really what you want for user adaptation, since a device may have multiple users and a user may have multiple devices.

/Bjorn

On Tue, Dec 14, 2010 at 4:10 AM, Young, Milan <Milan.Young@nuance.com> wrote:
> 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
>
>
>



--
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 17:36:31 UTC