- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 31 Aug 2015 08:41:13 +0200
- To: Tim Bray <tbray@textuality.com>, Mark Nottingham <mnot@mnot.net>
- Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, HTTP Working Group <ietf-http-wg@w3.org>, Wendy Seltzer <wseltzer@w3.org>, Niels ten Oever <niels@article19.org>, Daniel Kahn Gillmor <dkg@fifthhorseman.net>, Joseph Lorenzo Hall <joe@cdt.org>
On 2015-08-30 19:07, Tim Bray wrote: > I made a quickie cut of draft-ietf-httpbis-legally-restricted-status-02 > at https://www.tbray.org/tmp/451-02.html > > The only difference is the new section 4 “Identifying Blocking > Entities”, https://www.tbray.org/tmp/451-02.html#rfc.section.4 and a > header registration in IANA considerations. > ... Which is: > 4. Identifying Blocking Entities > > As noted above, when an attempt to access a resource fails with status 451, the entity blocking acces may or may not be the origin server. There are a variety of entities in the resource-access path which could choose to deny access, for example ISPs, cache providers, and DNS servers. > > It is useful, when legal blockages occur, to be able to identify the entities actually implementing the blocking. > > For this purpose, this specification registers the "Blocked-by" HTTP header, whose value identifies the blocking entity. When an entity blocks access to a resource and returns status 451, it SHOULD include a "Blocked-by" header identifying itself. > > The value of the "Blocked-by" header is a single URI-reference. When it has the form of a relative reference [RFC3986] the final value is computed by resolving it against the effective request URI. I think this is the right direction; the alternative of course would be a link relation... Editorial nitpicking: - s/acces/access/ - avoid lowercase RFC2219 keywords (use "might"?) - s/HTTP header/HTTP header field/ - s/URI-reference/URI-reference (Section 4.1 of [RFC3986])/ - s/relative reference [3986]/relative reference (Section 4.2 of [RFC3986])/ - s/effective request URI/effective request URI (Section 5.5 of [RFC7230])/ Best regards, Julian
Received on Monday, 31 August 2015 06:42:09 UTC