idnits 2.17.1 draft-sahib-451-new-protocol-elements-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 16, 2018) is 2083 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 197 -- Looks like a reference, but probably isn't: '2' on line 199 -- Looks like a reference, but probably isn't: '3' on line 201 == Unused Reference: 'RFC2277' is defined on line 158, but no explicit reference was found in the text == Unused Reference: 'RFC3986' is defined on line 162, but no explicit reference was found in the text == Unused Reference: 'RFC8280' is defined on line 175, but no explicit reference was found in the text == Unused Reference: 'RFC8288' is defined on line 179, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Sahib 3 Internet-Draft July 16, 2018 4 Intended status: Informational 5 Expires: January 17, 2019 7 New protocol elements for HTTP Status Code 451 8 draft-sahib-451-new-protocol-elements-02 10 Abstract 12 This document recommends additional protocol elements to Hypertext 13 Transfer Protocol (HTTP) status code 451 (defined by RFC7725). 15 Discussion of this document was conducted on the Human Rights 16 Protocol Considerations Research Group mailing list 17 https://www.irtf.org/mailman/listinfo/hrpc [1], briefly on the 18 HTTPBIS Working Group mailing list ietf-http-wg@w3.org [2] and on 19 https://lists.ghserv.net/mailman/listinfo/statuscode451 [3]. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 17, 2019. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. New Protocol Elements . . . . . . . . . . . . . . . . . . . . 2 57 2.1. Blocking Authority . . . . . . . . . . . . . . . . . . . 2 58 2.2. Geographical Scope of Block . . . . . . . . . . . . . . . 3 59 3. Security Considerations . . . . . . . . . . . . . . . . . . . 3 60 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 61 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 3 62 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 64 6.2. Informative References . . . . . . . . . . . . . . . . . 4 65 6.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 68 1. Introduction 70 [RFC7725] was standardized by the IETF in February 2016. It defined 71 HTTP status code 451 - to be used when "a server operator has 72 received a legal demand to deny access to a resource or to a set of 73 resources". 75 This document attempts to outline protocol recommendations that would 76 help make the status code more useful to users. 78 2. New Protocol Elements 80 2.1. Blocking Authority 82 In addition to the "blocked-by" header specified in [RFC7725], an 83 HTTP response with status code 451 would benefit from including 84 another "Link" HTTP header field [RFC5988] which has a "rel" 85 parameter whose value is "blocking-authority". It's important to 86 distinguish between the implementer of the block, and the authority 87 that mandated the block in the first place. This is because these 88 two organizations might not be the same - a government (the blocking 89 authority) could force an Internet Service Provider (the implementer 90 of the block) to deny access to a certain resource. There is 91 confusion amongst implementors of [RFC7725] about the meaning of the 92 term "blocked-by", perhaps in part because of the example given in 93 the RFC [ERRATA_ID-5181] - it would be useful to explicitly include 94 space for both, as both provide essential information about the legal 95 block. 97 2.2. Geographical Scope of Block 99 HTTP status code 451 is increasingly being used to deny access to 100 resources based on geographical IP. The response should contain a 101 provisional header with geographical scope of block. This scope 102 should correspond to comma-separated list of alpha-2 country codes 103 defined in [ISO.3166-1]. The rationale for keeping the geographical 104 scope to country-level granularity is that most blocks are mandated 105 by national governments [IMPL_REPORT], 106 [AUTOMATTIC_COUNTRY_BLOCK_LIST]. In addition, as the serving of this 107 status code is voluntary, there is value in not complicating the 108 specification. 110 3. Security Considerations 112 This document does not add additional security considerations to 113 [RFC7725]. 115 4. IANA Considerations 117 The Link Relation Type Registry should be updated with the following 118 entry: 120 - Relation Name: blocking-authority 122 - Description: Identifies the authority that has issued the block. 124 - Reference: this document 126 In addition, IANA should be updated with the following provisional 127 header: 129 - Header field name: geo-scope-block 131 - Applicable protocol: http 133 - Status: provisional 135 - Specification document(s): this document 137 Acknowledgements 139 Thanks to Alp Toker, Christine Runnegar, Niels ten Oever, Stephane 140 Bortzmeyer, Corinne Cath and many others on the HRPC mailing list 141 (linked above) for reviewing and brainstorming. 143 6. References 145 6.1. Normative References 147 [ERRATA_ID-5181] 148 Bortzmeyer, S., "[Technical Errata Reported] RFC7725 149 (5181)", 2017, 150 . 152 [ISO.3166-1] 153 International Organization for Standardization, "Codes for 154 the representation of names of countries and their 155 subdivisions - Part 1: Country code", ISO Standard 3166- 156 1:1997 , 1997. 158 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 159 Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277, 160 January 1998, . 162 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 163 Resource Identifier (URI): Generic Syntax", STD 66, 164 RFC 3986, DOI 10.17487/RFC3986, January 2005, 165 . 167 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, 168 DOI 10.17487/RFC5988, October 2010, 169 . 171 [RFC7725] Bray, T., "An HTTP Status Code to Report Legal Obstacles", 172 RFC 7725, DOI 10.17487/RFC7725, February 2016, 173 . 175 [RFC8280] ten Oever, N. and C. Cath, "Research into Human Rights 176 Protocol Considerations", RFC 8280, DOI 10.17487/RFC8280, 177 October 2017, . 179 [RFC8288] Nottingham, M., "Web Linking", RFC 8288, 180 DOI 10.17487/RFC8288, October 2017, 181 . 183 6.2. Informative References 185 [AUTOMATTIC_COUNTRY_BLOCK_LIST] 186 "Automattic - Country Block List", 2018, 187 . 189 [IMPL_REPORT] 190 Abraham, S., Canales, MP., Hall, J., Khrustaleva, O., ten 191 Oever, N., Runnegar, C., and S. Sahib, "Implementation 192 Report for HTTP Status Code 451", 2017, 193 . 195 6.3. URIs 197 [1] https://www.irtf.org/mailman/listinfo/hrpc 199 [2] mailto:ietf-http-wg@w3.org 201 [3] https://lists.ghserv.net/mailman/listinfo/statuscode451 203 Author's Address 205 Shivan Kaul Sahib 207 EMail: shivankaulsahib@gmail.com