W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2012

Re: New Version Notification for draft-tbray-http-legally-restricted-status-00.txt

From: John Sullivan <jsullivan@velocix.com>
Date: Fri, 15 Jun 2012 15:11:09 +0100
Message-ID: <4FDB427D.9000200@velocix.com>
To: Nicolas Mailhot <nicolas.mailhot@laposte.net>
CC: <ietf-http-wg@w3.org>, Julian Reschke <julian.reschke@gmx.de>, Mark Nottingham <mnot@mnot.net>, <tbray@textuality.com>, <w@1wt.eu>
Nicolas Mailhot wrote:
> And in case of blocking or censorship, transport set up does not stop at
> punting a metalanguage error to the human. In all but the most extreme cases
> it is possible to lift all or part of the blocking by providing some
> credentials or tokens somewhere, and to avoid breaking web apps that were
> mid-transaction when the block occurred, the web client must then retry the
> access that was blocked.

No, the expectation is that the block is permanent, the entity
implementing the block *wants* to (semi)permanently pollute that
URL, retries are unlikely to be useful.

The user *might* be able to get the block lifted by complaining to
the right place, but that's a longer process. In some cases the
local sysadmin might agree a particular URL is blocked in error
with an email round-trip, in some cases it might take societal
upheaval to get the blocking policy changed.

> That's error 511 design. The cons are that it is useless for dumb clients,
> there is no clear way to unlock except by parsing not-standardised

For 511/captive portal the situation is that the user probably can
rapidly resolve the block themselves, either by completing the attached
form, or by phoning/walking to reception etc, and then trying again.
The blocker doesn't want to break that access permanently, they just
want to get paid for it first, but I don't see how except in vanishingly
rare cases there could be fully automatic recovery, it's going to require
some form of user action.

John
-- 
Received on Friday, 15 June 2012 14:11:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 15 June 2012 14:11:52 GMT