Re: "Protocol" requirement - Session

On 12/14/2010 04:02 AM, Bjorn Bringert wrote:
> 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.

Yeah, I think we should try pretty hard to use same session management
mechanisms as what is being used in the web right now.



-Olli



>
> 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
>>
>>
>>
>
>
>

Received on Thursday, 16 December 2010 17:00:18 UTC