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

(Apologies for replying to myself)

To put the point shorter, I think the core problem with "assign a generic
code, put human explanations in html or xml body" is that's a layering
violation for all applications that use http as transport.

Those applications (reasonably) expect being able to set up the transport at
the http level without ever having to parse metalanguage bodies. When you put
relevant transport information in metalanguage bodies, you break this
expectation.

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.

There are several possible designs. The full one in proposed yesterday. The
others are (if I've followed the discussion correctly) :

A.

1. Generic 'blocked by intermediary' code
2. All other information somewhere in a metalanguage body

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
metalanguage soup, the blocking cause is not explicit at the http level in
logs (you need to infer it from what emitted this error), it's a transport
layering violation, and in cases when your network equipment can not host a
full web site you have to stuff all the rationale in the error body, even if
most users don't need to read it twice, and it needlessly overloads the wire.

B. Same thing but with separate error code for each human reason for blocking

That's basically what Tim Bray is proposing with his separate censorship code.
It has the same drawbacks as the previous proposal, except that the blocking
cause is explicit at the http level. The other side of the coin is that you'll
have to define new codes for all human blocking rationales, which will lead to
code explosion and codes which are only supported by a limited set of web
clients

C.
1. Generic 'blocked by intermediary' code
2. Optional unlock location in header
3. Standard 'ok' code unlock location returns when it is safe to retry the
access that triggered 1.

Same thing as A. but solves the unlock problem and lets the unlock location
use https portal preventing spoofing. Blocking rationale is still nowhere and
you still have logging/debuging limitations

D.
Same thing as C. but with optional blocking rationale location

Lets you inform humans why they are blocked with rich content without
overloading the error body. Simplifies logging since you can correlate
blocking rationale location with blocking causes. Requires a separate
rationale location for each blocking reason (not nice in case of complex use
terms)

E.
Same thing as D. but with short blocking rationale in a separate header

Pro: solves all functional problems I see
Cons: heavy design, puts human text in headers

F.
Make all intermediaries explicit, proxy traffic hop from hop, communicate
blocking at the proxy protocol level)

(What Willy favoured for corporate proxies, I don't think it scales up to the
national censorship level, nor that it would be a good idea to go there)

I freely admit we could probably get by with C. only even though without D.
we'd probably continue to have frictions and E. would be heaven. I don't see
the point of B. except as a political point which has no place in a technical
standard.

Am I missing something obvious?
Is there one of those designs people would like me to try to formalize more or
are there good reasons to reject them all directly without bothering?

Best regards,

-- 
Nicolas Mailhot

Received on Friday, 15 June 2012 07:34:44 UTC