New version of Problem Statement Document 1f (was RE: New version of Problem Statement Document 1e)

Hi Nigel

Thanks for your contribution

I think your suggested amplification is useful and think it should be
included in the document, which at present doesn't deal head on with
sites that return 200 while saying that the browser is not supported.

In view of what I think is the uncontentious nature of Nigel's
contribution I have included it in the latest version of the document.
We can fall back to the previous version if there are objections. To
repeat: I think we need to move on now, and would like this document
pushed through the process, the first step of which is to tell the BPWG
as a whole that we are done with it.

The new version is at [1]

[1]
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Probl
emStatement/071008


Ref the idea of inserting a link proposing that a transforming proxy is
able to try and get the page for the user - I believe this falls into
the realm of the Guidelines document, so we should keep you contribution
open under that heading. So far as the problem statement is concerned, I
believe that what you are referring to is mentioned as a requirement
under:

Requirement 9. Components must be able to solicit and advertise user
choice.

Jo

Incidentally: I didn't see you subscribed to this list under you name
which may be why you are having problems positng to it. Use the
following link to subscribe:
mailto:public-bpwg-ct-request@w3.org?subject=subscribe


> -----Original Message-----
> From: public-bpwg-ct-request@w3.org
[mailto:public-bpwg-ct-request@w3.org]
> On Behalf Of Jo Rabin
> Sent: 04 October 2007 19:14
> To: public-bpwg-ct@w3.org
> Cc: nigel@admob.com
> Subject: FW: New version of Problem Statement Document 1e
> 
> 
> 
> Comments from Nigel Choi attached:
> 
> 
> -----Original Message-----
> From: Nigel Choi [mailto:nigel@admob.com]
> Sent: 04 October 2007 18:16
> To: Jo Rabin
> Subject: Re: New version of Problem Statement Document 1e
> 
> Jo,
> 
> Thanks, that was good work. I have some comments. Instead of posting
> directly to the mailing list (which I had problems last time) could
you
> please kindly consider and forward.
> 
> My comment is about this statement in 2.1
> 
> "Some Web sites [Definition: mobile blocking], aware that access is
not
> from the expected desktop context, send an HTTP error status code
> indicating that they cannot present an acceptable experience for the
> user, thus preventing access from mobile users."
> 
> I'd expand that into (pardon my English, it's not my native tongue)
> 
> "Some Web sites [Definition: mobile blocking], aware that access is
not
> from the expected desktop context, send and HTTP error status code
> indicating that they cannot present an acceptable experience for the
> user, or a page that warns the user that their browser is not
supported.
> 
> These Web sites prevent access from mobile users."
> 
> What I am getting at is perhaps a new Requirement:
> 
> "Such mobile blocking notice should be made available to the end user,
> so they know that the original server is mobile blocking, and is given
a
> 
> choice to use the transformation proxy."
> 
> The transformation proxy can then advertise its ability to masquerade
as
> 
> a desktop browser, by inserting a link in the content or through other
> means where the user can configure the behavior. This way the end user
> is aware that the origin server is not capable of sending them an
> experience tailored to their device, but there is a content
> transformation proxy there to assist.
> 
> It looks like the assumption here is that mobile blocking is always
> undesired. In any case, I think it needs to be made clear that
sometimes
> 
> such mobile blocking behavior is consistent with the intent of the
> origin server. I'd argue that users should at least be made aware of
the
> 
> mobile blocking behavior of the original site, and should be given a
> choice.
> 
> Yes, I'm building an argument against masquerading the User-Agent by
> default, if all the complaints out there about Vodafone UK's and
> Novarra's practice is not proof enough.
> 
> Thanks,
> Nigel.

Received on Monday, 8 October 2007 09:10:42 UTC