CT - interacting with the user

[Jo Rabin-2]

Chaals

The requirement on the proxy only kicks in when they are doing things
that mean they are stepping out from behind the transparency you discuss.

So I'd prefer to remain silent on this. Many of the proxies we are
talking about in this case, do in fact communicate directly with the
user. I don't think we should mandate the nature of the communication.

Cheers


 From Chaals:

Proxies by their nature don't generally interact directly with the user. I
think it is worth explaining what we mean by "inform the user", "advise
the user", "allow the user to..." etc.

One approach is for the proxy to ship content explicitly to the user
(instead, presumably, of what the user actually asked for). Another is to
make flags available to the user agent which is accessing the proxy (e.g.
generating 300 responses, vary headers, or the like) which would allow the
UA to do whatever it normally does that allows the user to make choices.

This question is important because at the moment we seem to be implying
requirements on the proxy which either make assumptions about the UA, or
contradict the goal of letting the user simply go to the content they
asked for (which is the service proxies generally provide, trying to be if
not transparent in teh terms of the document then at least as invisible as
possible).

cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
      je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

[Charles McCathieNevile-2]

On Mon, 28 Sep 2009 12:37:54 +0200, Jo Rabin <jrabin@...> wrote:

> Chaals
>
> The requirement on the proxy only kicks in when they are doing things  
> that mean they are stepping out from behind the transparency you discuss.

No, the transparency I discuss is not the one mentioned in the spec, but
the fact that the user isn't generally in direct communication with the
proxy (the user agent is), but is getting presented something that
purports to be the content s/he is looking for, as transformed by the
proxy.

> So I'd prefer to remain silent on this. Many of the proxies we are  
> talking about in this case, do in fact communicate directly with the  
> user. I don't think we should mandate the nature of the communication.

Well, as I understand it we are mandating a set of interactions by
requiring the proxy to get some information from the user, or give the
user some information. Is it sufficient to deliver these in a terms of
service agreement, or do we mean that these should be live interactions
during the browser session?

And if we mean the latter, what are the minimum ways to satisfy this - is
it sufficient to add a link back to the proxy for warnings and
interactions somewhere after the bottom of the content the proxy is being
asked to present, or do these need to be visible warnings presented before
the page itself?

I agree that we should be very conservative in mandating interaction  
behaviour, but I think in the current draft we are simply underspecifying  
requirements, and since I believe that a terms of service agreement  
satisfies the current draft, but I believe that is not what the group has  
in mind, I think we need to get a bit more clarity on this.

cheers

Chaals

> Cheers
>
>
>  From Chaals:
>
> Proxies by their nature don't generally interact directly with the user.  
> I
> think it is worth explaining what we mean by "inform the user", "advise
> the user", "allow the user to..." etc.
>
> One approach is for the proxy to ship content explicitly to the user
> (instead, presumably, of what the user actually asked for). Another is to
> make flags available to the user agent which is accessing the proxy (e.g.
> generating 300 responses, vary headers, or the like) which would allow  
> the
> UA to do whatever it normally does that allows the user to make choices.
>
> This question is important because at the moment we seem to be implying
> requirements on the proxy which either make assumptions about the UA, or
> contradict the goal of letting the user simply go to the content they
> asked for (which is the service proxies generally provide, trying to be  
> if
> not transparent in teh terms of the document then at least as invisible  
> as
> possible).
>
> cheers
>
> Chaals
>

--
Charles McCathieNevile  Opera Software, Standards Group
       je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

[Jo Rabin-2]

OK. I had thought it would be hard to construe the document in such a
way that a terms of service agreement would suffice ... but even if that
is the case perhaps there is still scope for people doing so. So can you
please note specifically where you think this is the case and suggest
editorial remedies to make sure it is clear.

Jo

On 28/09/2009 13:02, Charles McCathieNevile wrote:

> On Mon, 28 Sep 2009 12:37:54 +0200, Jo Rabin <jrabin@...> wrote:
>
>> Chaals
>>
>> The requirement on the proxy only kicks in when they are doing things
>> that mean they are stepping out from behind the transparency you discuss.
>
> No, the transparency I discuss is not the one mentioned in the spec, but
> the fact that the user isn't generally in direct communication with the
> proxy (the user agent is), but is getting presented something that
> purports to be the content s/he is looking for, as transformed by the
> proxy.
>
>> So I'd prefer to remain silent on this. Many of the proxies we are
>> talking about in this case, do in fact communicate directly with the
>> user. I don't think we should mandate the nature of the communication.
>
> Well, as I understand it we are mandating a set of interactions by
> requiring the proxy to get some information from the user, or give the
> user some information. Is it sufficient to deliver these in a terms of
> service agreement, or do we mean that these should be live interactions
> during the browser session?
>
> And if we mean the latter, what are the minimum ways to satisfy this - is
> it sufficient to add a link back to the proxy for warnings and
> interactions somewhere after the bottom of the content the proxy is being
> asked to present, or do these need to be visible warnings presented before
> the page itself?
>
> I agree that we should be very conservative in mandating interaction
> behaviour, but I think in the current draft we are simply
> underspecifying requirements, and since I believe that a terms of
> service agreement satisfies the current draft, but I believe that is not
> what the group has in mind, I think we need to get a bit more clarity on
> this.
>
> cheers
>
> Chaals
>
>> Cheers
>>
>>
>>  From Chaals:
>>
>> Proxies by their nature don't generally interact directly with the
>> user. I
>> think it is worth explaining what we mean by "inform the user", "advise
>> the user", "allow the user to..." etc.
>>
>> One approach is for the proxy to ship content explicitly to the user
>> (instead, presumably, of what the user actually asked for). Another is to
>> make flags available to the user agent which is accessing the proxy (e.g.
>> generating 300 responses, vary headers, or the like) which would allow
>> the
>> UA to do whatever it normally does that allows the user to make choices.
>>
>> This question is important because at the moment we seem to be implying
>> requirements on the proxy which either make assumptions about the UA, or
>> contradict the goal of letting the user simply go to the content they
>> asked for (which is the service proxies generally provide, trying to
>> be if
>> not transparent in teh terms of the document then at least as
>> invisible as
>> possible).
>>
>> cheers
>>
>> Chaals
>>
>
>

[Charles McCathieNevile-2]

On Mon, 28 Sep 2009 14:11:55 +0200, Jo Rabin <jrabin@...> wrote:

> OK. I had thought it would be hard to construe the document in such a  
> way that a terms of service agreement would suffice ... but even if that  
> is the case perhaps there is still scope for people doing so. So can you  
> please note specifically where you think this is the case and suggest  
> editorial remedies to make sure it is clear.

As far as I can tell, the document makes no statements whatever about how  
to do this, so while it is drawing a legalistic bow of some length, the  
interpetation can be made to stand up against the requirements of the  
document.

To go a bit further, I am not convinced that we should be mandating what I  
suspect the group intuitively understands but has not expressed by "inform  
the user". In particular, any attempt to tell people whose business model  
is based on providing a particular rendering, what that rendering should  
include, has to be based on extremely solid requirements that are  
demonstrably necessary for the user.

Likewise, would "provide a website where the user can go and alter their  
preferences (and look up their use history)" meet the requirements? I  
certainly wouldn't want to mandate that as what must be done, but I  
suspect it would meet my test for "this is a reasonable approach".

Anyway, talk to you about this soon...

cheers

Chaals

> Jo
>
> On 28/09/2009 13:02, Charles McCathieNevile wrote:
>> On Mon, 28 Sep 2009 12:37:54 +0200, Jo Rabin <jrabin@...> wrote:
>>
>>> Chaals
>>>
>>> The requirement on the proxy only kicks in when they are doing things  
>>> that mean they are stepping out from behind the transparency you  
>>> discuss.
>>  No, the transparency I discuss is not the one mentioned in the spec,  
>> but
>> the fact that the user isn't generally in direct communication with the
>> proxy (the user agent is), but is getting presented something that
>> purports to be the content s/he is looking for, as transformed by the
>> proxy.
>>
>>> So I'd prefer to remain silent on this. Many of the proxies we are  
>>> talking about in this case, do in fact communicate directly with the  
>>> user. I don't think we should mandate the nature of the communication.
>>  Well, as I understand it we are mandating a set of interactions by
>> requiring the proxy to get some information from the user, or give the
>> user some information. Is it sufficient to deliver these in a terms of
>> service agreement, or do we mean that these should be live interactions
>> during the browser session?
>>  And if we mean the latter, what are the minimum ways to satisfy this -  
>> is
>> it sufficient to add a link back to the proxy for warnings and
>> interactions somewhere after the bottom of the content the proxy is  
>> being
>> asked to present, or do these need to be visible warnings presented  
>> before
>> the page itself?
>>  I agree that we should be very conservative in mandating interaction  
>> behaviour, but I think in the current draft we are simply  
>> underspecifying requirements, and since I believe that a terms of  
>> service agreement satisfies the current draft, but I believe that is  
>> not what the group has in mind, I think we need to get a bit more  
>> clarity on this.
>>  cheers
>>  Chaals
>>
>>> Cheers
>>>
>>>
>>>  From Chaals:
>>>
>>> Proxies by their nature don't generally interact directly with the  
>>> user. I
>>> think it is worth explaining what we mean by "inform the user", "advise
>>> the user", "allow the user to..." etc.
>>>
>>> One approach is for the proxy to ship content explicitly to the user
>>> (instead, presumably, of what the user actually asked for). Another is  
>>> to
>>> make flags available to the user agent which is accessing the proxy  
>>> (e.g.
>>> generating 300 responses, vary headers, or the like) which would allow  
>>> the
>>> UA to do whatever it normally does that allows the user to make  
>>> choices.
>>>
>>> This question is important because at the moment we seem to be implying
>>> requirements on the proxy which either make assumptions about the UA,  
>>> or
>>> contradict the goal of letting the user simply go to the content they
>>> asked for (which is the service proxies generally provide, trying to  
>>> be if
>>> not transparent in teh terms of the document then at least as  
>>> invisible as
>>> possible).
>>>
>>> cheers
>>>
>>> Chaals
>>>
>>

--
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

[Jo Rabin-2]

 > suspect it would meet my test for "this is a reasonable approach".
 >
no, far from it, the man on the Clapham omnibus would not think this
reasonable, as he struggles to use the Transport for London Web site
that has been mysteriously mis-rendered as a result of a transforming
proxy ...

 > Anyway, talk to you about this soon...
lookin fwd to it


Jo
On 29/09/2009 14:18, Charles McCathieNevile wrote:

> On Mon, 28 Sep 2009 14:11:55 +0200, Jo Rabin <jrabin@...> wrote:
>
>> OK. I had thought it would be hard to construe the document in such a
>> way that a terms of service agreement would suffice ... but even if
>> that is the case perhaps there is still scope for people doing so. So
>> can you please note specifically where you think this is the case and
>> suggest editorial remedies to make sure it is clear.
>
> As far as I can tell, the document makes no statements whatever about
> how to do this, so while it is drawing a legalistic bow of some length,
> the interpetation can be made to stand up against the requirements of
> the document.
>
> To go a bit further, I am not convinced that we should be mandating what
> I suspect the group intuitively understands but has not expressed by
> "inform the user". In particular, any attempt to tell people whose
> business model is based on providing a particular rendering, what that
> rendering should include, has to be based on extremely solid
> requirements that are demonstrably necessary for the user.
>
> Likewise, would "provide a website where the user can go and alter their
> preferences (and look up their use history)" meet the requirements? I
> certainly wouldn't want to mandate that as what must be done, but I
> suspect it would meet my test for "this is a reasonable approach".
>
> Anyway, talk to you about this soon...
>
> cheers
>
> Chaals
>
>> Jo
>>
>> On 28/09/2009 13:02, Charles McCathieNevile wrote:
>>> On Mon, 28 Sep 2009 12:37:54 +0200, Jo Rabin <jrabin@...> wrote:
>>>
>>>> Chaals
>>>>
>>>> The requirement on the proxy only kicks in when they are doing
>>>> things that mean they are stepping out from behind the transparency
>>>> you discuss.
>>>  No, the transparency I discuss is not the one mentioned in the spec,
>>> but
>>> the fact that the user isn't generally in direct communication with the
>>> proxy (the user agent is), but is getting presented something that
>>> purports to be the content s/he is looking for, as transformed by the
>>> proxy.
>>>
>>>> So I'd prefer to remain silent on this. Many of the proxies we are
>>>> talking about in this case, do in fact communicate directly with the
>>>> user. I don't think we should mandate the nature of the communication.
>>>  Well, as I understand it we are mandating a set of interactions by
>>> requiring the proxy to get some information from the user, or give the
>>> user some information. Is it sufficient to deliver these in a terms of
>>> service agreement, or do we mean that these should be live interactions
>>> during the browser session?
>>>  And if we mean the latter, what are the minimum ways to satisfy this
>>> - is
>>> it sufficient to add a link back to the proxy for warnings and
>>> interactions somewhere after the bottom of the content the proxy is
>>> being
>>> asked to present, or do these need to be visible warnings presented
>>> before
>>> the page itself?
>>>  I agree that we should be very conservative in mandating interaction
>>> behaviour, but I think in the current draft we are simply
>>> underspecifying requirements, and since I believe that a terms of
>>> service agreement satisfies the current draft, but I believe that is
>>> not what the group has in mind, I think we need to get a bit more
>>> clarity on this.
>>>  cheers
>>>  Chaals
>>>
>>>> Cheers
>>>>
>>>>
>>>>  From Chaals:
>>>>
>>>> Proxies by their nature don't generally interact directly with the
>>>> user. I
>>>> think it is worth explaining what we mean by "inform the user", "advise
>>>> the user", "allow the user to..." etc.
>>>>
>>>> One approach is for the proxy to ship content explicitly to the user
>>>> (instead, presumably, of what the user actually asked for). Another
>>>> is to
>>>> make flags available to the user agent which is accessing the proxy
>>>> (e.g.
>>>> generating 300 responses, vary headers, or the like) which would
>>>> allow the
>>>> UA to do whatever it normally does that allows the user to make
>>>> choices.
>>>>
>>>> This question is important because at the moment we seem to be implying
>>>> requirements on the proxy which either make assumptions about the
>>>> UA, or
>>>> contradict the goal of letting the user simply go to the content they
>>>> asked for (which is the service proxies generally provide, trying to
>>>> be if
>>>> not transparent in teh terms of the document then at least as
>>>> invisible as
>>>> possible).
>>>>
>>>> cheers
>>>>
>>>> Chaals
>>>>
>>>
>
>