idnits 2.17.1 draft-doria-hrpc-proposal-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 9, 2015) is 3336 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'HRC2011' is defined on line 422, but no explicit reference was found in the text == Unused Reference: 'HRC2013' is defined on line 432, but no explicit reference was found in the text == Unused Reference: 'ICCPR' is defined on line 444, but no explicit reference was found in the text == Unused Reference: 'RFC2014' is defined on line 461, but no explicit reference was found in the text == Unused Reference: 'RFC2369' is defined on line 464, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 468, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 479, but no explicit reference was found in the text == Unused Reference: 'RFC3869' is defined on line 483, but no explicit reference was found in the text == Unused Reference: 'RFC4440' is defined on line 487, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 494, but no explicit reference was found in the text == Unused Reference: 'RFC5564' is defined on line 498, but no explicit reference was found in the text == Unused Reference: 'RFC7233' is defined on line 539, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7232 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7233 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7234 (Obsoleted by RFC 9111) -- Obsolete informational reference (is this intentional?): RFC 7235 (Obsoleted by RFC 9110) Summary: 0 errors (**), 0 flaws (~~), 14 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Human Rights Protocol Considerations A. Doria 3 Internet-Draft dotgay LLC 4 Intended status: Informational N. ten Oever 5 Expires: September 10, 2015 Article 19 6 J. Varon 7 March 9, 2015 9 Proposal for research on human rights protocol considerations 10 draft-doria-hrpc-proposal-01 12 Abstract 14 Work has been done on privacy issues that should be considered when 15 creating an Internet protocol. This draft suggests that similar 16 considerations may apply for other human rights such as freedom of 17 expression or freedom of association. A proposal is made for work in 18 the IRTF researching the possible connections between human rights 19 and Internet standards and protocols. The goal is to create an 20 informational RFC concerning human rights protocol considerations. 22 Discussion on this draft at: hrpc@article19.io 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 10, 2015. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 2. Research topic . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Protocol and Standard Examples . . . . . . . . . . . . . 4 62 2.1.1. Architecture . . . . . . . . . . . . . . . . . . . . 4 63 2.1.2. Transparency . . . . . . . . . . . . . . . . . . . . 5 64 2.1.3. HTTP . . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.1.4. Mailing lists . . . . . . . . . . . . . . . . . . . . 5 66 2.1.5. Real time communications . . . . . . . . . . . . . . 6 67 2.1.6. IDNs . . . . . . . . . . . . . . . . . . . . . . . . 6 68 3. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.1. Working Assumptions . . . . . . . . . . . . . . . . . . . 7 70 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 75 7.2. Informative References . . . . . . . . . . . . . . . . . 9 76 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 13 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 79 1. Introduction 81 The recognition that human rights have a role in Internet policies is 82 slowly becoming part of the general discourse. Several reports from 83 former United Nations (UN) Special Rapporteur on the promotion and 84 protection of the right to freedom of opinion and expression, Frank 85 La Rue, have made such relation explicit, which lead to the approval 86 of the landmark resolution "on the promotion, protection and 87 enjoyment of human rights on the Internet" [HRC2012] at the UN Human 88 Rights Council (HRC). More recently, to the resolution "The right to 89 privacy in the digital age" [UNGA2013] at the UN General Assembly. 90 The NETmundial outcome document [NETmundial] affirms that human 91 rights, as reflected in the Universal Declaration of Human Rights 92 [UDHR], should underpin Internet governance principles. 93 Nevertheless, a direct relation between Internet Standards and human 94 rights is still something to be explored and more clearly evidenced. 96 Concerns for freedom of expression and association were a strong part 97 of the world-view of the community involved in developing the first 98 Internet protocols. Apparently, by intention or by coincidence, the 99 Internet was designed with freedom and openness of communications as 100 core values. But as the scale and the industrialization of the 101 Internet has grown greatly, the influence of such world-views started 102 to compete with other values. The belief of the authors is that as 103 the Internet continues to grow, the linkage of Internet protocols to 104 human rights needs to become explicit, structured, and intentional. 106 Standards and protocols form the basis of the human rights enabling 107 infrastructure of the Internet. It needs to be determined whether 108 there is a causal relationship between Internet protocols and 109 standards, and human rights such as freedom of expression. To study 110 the relationship between the two one would need to carefully consider 111 structural and architectural considerations, as well as specific 112 protocols. The Internet Society paper "Human Rights and Internet 113 Protocols" [HRIP] "explores human rights and Internet protocols 114 comparing the processes for their making and the principles by which 115 they operate and concludes that there are some shared principles 116 between the two." Though that paper does not go into possible 117 reasons, dependencies or guidelines, it initiates the discussion. 118 More research is needed to map human rights concerns to protocol 119 elements and to frame possible approaches towards protocols that 120 satisfy the implications of human rights standards. 122 To move this debate further, a list has been created for discussion 123 of this draft: hrpc@article19.io and related ideas - information or 124 subscriptions at: https://lists.ghserv.net/mailman/listinfo/hrpc 126 1.1. Requirements Language 128 As this is an informational document describing a research effort, it 129 will not make use of requirements language as defined in RFC 2119 130 [RFC2119]. 132 2. Research topic 134 In a manner similar to the work done for RFC 6973 [RFC6973] on 135 Privacy Consideration Guidelines, the premise of this research is 136 that some standards and protocols can solidify, enable or threaten 137 user rights. 139 As stated in RFC 1958 [RFC1958], the Internet aims to be the global 140 network of networks that provides unfettered connectivity to all 141 users at all times and for any content. Open, secure and reliable 142 connectivity is essential for rights such as freedom of expression 143 and freedom of association, as defined in the Universal Declaration 144 of Human Rights [UDHR]. Therefore, considering connectivity as the 145 ultimate objective of the Internet, this makes a clear case that the 146 Internet is not only an enabler of human rights, but that human 147 rights lie at the basis of, and are ingrained in, the architecture of 148 the network. 150 An essential part of maintaining the Internet as a tool for 151 communication and connectivity is security. Indeed, "development of 152 security mechanisms is seen as a key factor in the future growth of 153 the Internet as a motor for international commerce and communication" 154 RFC 1984 [RFC1984] and according to the Danvers Doctrine RFC 3365 155 [RFC3365], there is an overwhelming consensus in the IETF that the 156 best security should be used and standardized. 158 In RFC 1984 [RFC1984], the Internet Architecture Board (IAB) and the 159 Internet Engineering Steering Group (IESG), the bodies which oversee 160 architecture and standards for the Internet, expressed: "concern by 161 the need for increased protection of international commercial 162 transactions on the Internet, and by the need to offer all Internet 163 users an adequate degree of privacy." Indeed, the IETF has been 164 doing a significant job in this area [RFC6973] [RFC7258], considering 165 privacy concerns as a subset of security concerns. [RFC6973] 167 Besides privacy, it should be possible to highlight other aspects of 168 connectivity embedded in standards and protocols that can have human 169 rights considerations, such as freedom of expression and the right to 170 association and assembly online. This research is working to develop 171 a methodology that enables us to extract these considerations. 173 2.1. Protocol and Standard Examples 175 Some initial topics that need exploration are indicated in this 176 section. Most of this work has yet to move beyond speculation and 177 casual conversation. Continuing releases of this draft will develop 178 these foundational discussions further, based on discussions to be 179 held on the hrpc@article19.io email list and the work of researchers 180 working on the project. 182 2.1.1. Architecture 184 RFC 1958 [RFC1958] mentions "the community believes that the goal 185 [of the Internet] is connectivity, the tool is the Internet 186 Protocol." It continues a bit further: "The current exponential 187 growth of the network seems to show that connectivity is its own 188 reward, and is more valuable than any individual application such as 189 mail or the World-Wide Web." This marks the intrinsic value of 190 connectivity, which is facilitated by the Internet, both in its 191 principle, and in practice. This shows that the underlying 192 principles of the Internet aim to preserve connectivity, which is 193 fundamental and similar to the part of Article 19 of the Universal 194 Declaration of Human Rights [UDHR], which defines a right to receive 195 and to impart information. 197 Article 19 198 Everyone has the right to freedom of opinion and expression; this 199 right includes freedom to hold opinions without interference and 200 to seek, receive and impart information and ideas through any 201 media and regardless of frontiers. 203 2.1.2. Transparency 205 Another part of Article 19 of the Universal Declaration of Human 206 Rights [UDHR] mentions that one has the right to hold opinions 207 _without interference_ (emphasis added). This same sentiment can be 208 found in IAB RFC4924 [RFC4924] - Reflection on Internet Transparency 209 where it states: "A network that does not filter or transform the 210 data that it carries may be said to be transparent" or "oblivious" to 211 the content of packets. Networks that provide oblivious transport 212 enable the deployment of new services without requiring changes to 213 the core. It is this flexibility that is perhaps both the Internet's 214 most essential characteristic as well as one of the most important 215 contributors to its success." 217 2.1.3. HTTP 219 Websites made it extremely easy for individuals to publish their 220 ideas, opinions and thoughts. Never before has the world seen an 221 infrastructure that made it this easy to share information and ideas 222 with such a large group of other people. The HTTP architecture and 223 standards, including RFC 7230 [RFC7230], RFC 7231 [RFC7231], RFC 7232 224 [RFC7232], RFC 7234 [RFC7234], RFC 7235 [RFC7235], RFC 7236 225 [RFC7236], and RFC 7327 [RFC7237], are essential for the publishing 226 of information. The HTTP protocol, therefore, forms an crucial 227 enabler for freedom of expression, but also for the right to freely 228 participate in the culture life of the community (Article 27) [UDHR], 229 to enjoy the arts and to share in scientific advancement and its 230 benefits. 232 2.1.4. Mailing lists 234 Collaboration and cooperation have been part of the Internet since 235 its early beginning, one of the instruments of facilitating working 236 together in groups are mailing lists (as described in RFC 2369 237 [RFC2919], RFC 2919 [RFC2919], and RFC 6783 [RFC6783]. Mailing lists 238 are critical instruments and enablers for group communication and 239 organization, and therefore form early artefacts of the 240 (standardized) ability of Internet standards to enable the right to 241 freedom of assembly and association. 243 2.1.5. Real time communications 245 Collaborations and cooperation via the Internet have take a large 246 step forward with the progress of chat and other other real time 247 communications protocols. The work on XMPP RFC 6162 [RFC6162] has 248 enabled new methods of global interactions, cooperation and human 249 right advocacy. The WebRTC work being done to standardize the API 250 and protocol elements to support real-time communications for 251 browsers, mobile applications and IoT by the World Wide Consortium 252 (W3C) and the IETF is another artefact enabling human rights globally 253 on the Internet. 255 2.1.6. IDNs 257 English has been the lingua franca of the Internet, but for many 258 Internet user English is not their first language. To have a true 259 global Internet, one that serves the whole world, it would need to 260 reflect the languages of these different communities. The 261 Internationalized Domain Names IDNA2008 (RFC 5890 [RFC5890], RFC 5891 262 [RFC5891], RFC 5892 [RFC5892], and RFC 5893 [RFC5893]), describes 263 standards for the use of a broad range of strings and characters 264 (some also written from right to left). This enables users who use 265 other characters than the standard LDH ascii typeset to have their 266 own URLs. This shows the ambition of the Internet community to 267 reflect the diversity of users and to be in line with Article 2 of 268 the Universal Declaration of Human Rights which clearly stipulates 269 that "everyone is entitles to all rights and freedoms [..], without 270 distinction of any kind, such as [..] language [..]."[UDHR] 272 3. Proposal 274 To start addressing the issue, a mapping exercise analyzing Internet 275 architecture and protocols features, vis-a-vis possible impact on 276 human rights needs is being undertaken. 278 As part of the research, interviews will be requested with the 279 current and past members of the Internet Architecture Board (IAB), 280 current and past members of the Internet Engineering Steering 281 Group(IESG) and chairs of selected working groups and RFC authors. 283 Mapping the relation between human rights and protocols and 284 architectures is a new research challenge, which requires a good 285 amount of cross organizational cooperation to develop a consistent 286 methodology. While the authors of this first draft are involved in 287 both human rights advocacy and research on Internet technologies - we 288 believe that bringing this work into the IRTF facilitates and 289 improves this work by bringing human rights experts together with the 290 community of researchers and developers of Internet standards and 291 technologies. 293 Assuming that the research produces useful results, the objective 294 will evolve into the creation of a set of recommended considerations 295 for the protection of applicable human rights. 297 3.1. Working Assumptions 299 In the analysis of existing RFCs central design and technical 300 concepts have been found which impact human rights. These concepts, 301 working assumptions, will form the lens for the analysis of RFCs and 302 will be further described vis a vis their impact on human rights. 304 The combination of content agnosticism, connectivity, security (as 305 defined in RFC 3365 [RFC3365] and privacy (as defined in RFC 6973 306 [RFC6973]) are the technical principles that underlay freedom of 307 expression on the Internet. 309 Privacy and security are defined, so here we focus on concepts that 310 have not been defined as considerations that are relevant for freedom 311 of expression. 313 This is a first list of concepts, which definitions should be 314 improved and further aligned with existing RFCs. 316 Connectivity: 317 The Internet is the tool for providing global connectivity that 318 conforms with RFC 1958 [RFC1958]. Therefore all protocols and 319 standards should aim to improve connectivity, and not to limit it. 321 Distributed: 322 To enable and strengthen connectivity, stability, and 323 sustainability of the network, protocols and standards should be 324 developed in a way that can be implemented in a distributed way. 325 If they are not instrumented in a distributed manner, other 326 'accountability mechanisms' should be in place. Accountability 327 mechanisms might include features such as access control, logging 328 and other protocol management. 330 Inter-operable: 331 Standards exist to design systems that allow for other systems to 332 interact freely and openly. 334 Reliable: 336 Reliability ensures that a protocol will execute its function 337 consistently and error resistant as described and function without 338 unexpected result. This includes factors such as throughput, 339 middle boxes, and delay/disruption tolerance. A system that is 340 reliable degenerates gracefully and will have a documented way to 341 announce degradation. It will also have mechanisms to recover 342 from failure. 344 Scalable: 345 Any solution should support growth of the network with more hosts, 346 users and traffic. And have clear definition of its scope and 347 ideally a proposition how it can be expanded in order to support 348 greater capacity. Any limits in scalability should be defined. 350 Stateless / state-full: 351 If possible protocols should be implemented stateless for 352 reliability and privacy considerations. If not, they should keep 353 as little state as possible. 355 Content agnostic: 356 Protocols should not treat packets/datagrams differently based on 357 their content. 359 Transparent: 360 Protocols should be transparent in what they can do and can not do 361 and how it is done. 363 Debugging: 364 A protocol should allow a user to troubleshoot and debug possible 365 causes of malfunction and loss of reliability. 367 Robust: 368 Protocols should be resistant to errors, and to involuntary, legal 369 or malicious attempts to disrupt its mode of operations. 370 Protocols should be developed in a way that there is no hidden 371 back doors or kill switches. There should also be a clear 372 description on how a protocol recovers from potential failures. 374 End user-centric / representing stakeholder rights: 375 As proposed in draft-nottingham-stakeholder-rights-00: 377 Protocols MUST document relevant primary stakeholders and their 378 interrelationships. [..] 380 End-user-facing application protocols MUST prioritise their 381 users higher than any other stakeholders. 383 Extensions to existing protocols MUST document how they 384 interact with the extended protocol's stakeholders. If the 385 extended protocol's stakeholders are not yet documented, the 386 extension MAY estimate its impact, in coordination with that 387 protocol's community and the IESG. 389 The burden of this documentation need not be high; if HTML can 390 do it in a paragraph, so can most protocols. While it might be 391 appropriate in a separate document (e.g., a requirements or use 392 cases draft) or the protocol specification itself, documenting 393 stakeholders in the WG charter has considerable benefits, since 394 it clarifies their relationships up-front. 396 4. Acknowledgements 398 This builds on work done by RFC 6973 [RFC6973]. 400 Thanks go to those who have discussed and edited the ideas in this 401 draft. Special thanks go to Joy Liddicoat as the co-author of 402 Human Rights and Internet Protocols [HRIP] 404 5. IANA Considerations 406 This memo includes no request to IANA. 408 6. Security Considerations 410 As this draft concerns a research proposal, there are no security 411 considerations. 413 7. References 415 7.1. Normative References 417 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 418 Requirement Levels", BCP 14, RFC 2119, March 1997. 420 7.2. Informative References 422 [HRC2011] Human Rights Council, , "Report of the Special Rapporteur 423 on the promotion and protection of the right to freedom of 424 opinion and expression, Human Rights Council, May 2011", 425 2011. 427 [HRC2012] General Assembly, UN., "Human Rights Council Resolution on 428 the promotion, protection and enjoyment of human rights on 429 the Internet", 2011, 430 . 432 [HRC2013] General Assembly, UN., "Report of the Special Rapporteur 433 on the promotion and protection of the right to freedom of 434 opinion and expression, Human Rights Council, April 2013", 435 2013. 437 [HRIP] Joy Liddicoat, JL. and AD. Avri Doria, "Human Rights and 438 Internet Protocols: Comparing Processes and Principles", 439 2012, 440 . 444 [ICCPR] General Assembly, UN., "International Covenant on Civil 445 and Political Rights", 1966, 446 . 449 [NETmundial] 450 NetMundial, , "NETmundial Multistakeholder Statement", 451 2014, . 454 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", 455 RFC 1958, June 1996. 457 [RFC1984] IAB, IESG, Carpenter, B., and F. Baker, "IAB and IESG 458 Statement on Cryptographic Technology and the Internet", 459 RFC 1984, August 1996. 461 [RFC2014] Weinrib, A. and J. Postel, "IRTF Research Group Guidelines 462 and Procedures", BCP 8, RFC 2014, October 1996. 464 [RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax 465 for Core Mail List Commands and their Transport through 466 Message Header Fields", RFC 2369, July 1998. 468 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 469 June 1999. 471 [RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field 472 and Namespace for the Identification of Mailing Lists", 473 RFC 2919, March 2001. 475 [RFC3365] Schiller, J., "Strong Security Requirements for Internet 476 Engineering Task Force Standard Protocols", BCP 61, RFC 477 3365, August 2002. 479 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 480 Text on Security Considerations", BCP 72, RFC 3552, July 481 2003. 483 [RFC3869] Atkinson, R., Floyd, S., and Internet Architecture Board, 484 "IAB Concerns and Recommendations Regarding Internet 485 Research and Evolution", RFC 3869, August 2004. 487 [RFC4440] Floyd, S., Paxson, V., Falk, A., and IAB, "IAB Thoughts on 488 the Role of the Internet Research Task Force (IRTF)", RFC 489 4440, March 2006. 491 [RFC4924] Aboba, B. and E. Davies, "Reflections on Internet 492 Transparency", RFC 4924, July 2007. 494 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 495 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 496 May 2008. 498 [RFC5564] El-Sherbiny, A., Farah, M., Oueichek, I., and A. Al-Zoman, 499 "Linguistic Guidelines for the Use of the Arabic Language 500 in Internet Domains", RFC 5564, February 2010. 502 [RFC5890] Klensin, J., "Internationalized Domain Names for 503 Applications (IDNA): Definitions and Document Framework", 504 RFC 5890, August 2010. 506 [RFC5891] Klensin, J., "Internationalized Domain Names in 507 Applications (IDNA): Protocol", RFC 5891, August 2010. 509 [RFC5892] Faltstrom, P., "The Unicode Code Points and 510 Internationalized Domain Names for Applications (IDNA)", 511 RFC 5892, August 2010. 513 [RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left Scripts for 514 Internationalized Domain Names for Applications (IDNA)", 515 RFC 5893, August 2010. 517 [RFC6162] Turner, S., "Elliptic Curve Algorithms for Cryptographic 518 Message Syntax (CMS) Asymmetric Key Package Content Type", 519 RFC 6162, April 2011. 521 [RFC6783] Levine, J. and R. Gellens, "Mailing Lists and Non-ASCII 522 Addresses", RFC 6783, November 2012. 524 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 525 Morris, J., Hansen, M., and R. Smith, "Privacy 526 Considerations for Internet Protocols", RFC 6973, July 527 2013. 529 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 530 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 531 2014. 533 [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 534 (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. 536 [RFC7232] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 537 (HTTP/1.1): Conditional Requests", RFC 7232, June 2014. 539 [RFC7233] Fielding, R., Lafon, Y., and J. Reschke, "Hypertext 540 Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, 541 June 2014. 543 [RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext 544 Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 545 2014. 547 [RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 548 (HTTP/1.1): Authentication", RFC 7235, June 2014. 550 [RFC7236] Reschke, J., "Initial Hypertext Transfer Protocol (HTTP) 551 Authentication Scheme Registrations", RFC 7236, June 2014. 553 [RFC7237] Reschke, J., "Initial Hypertext Transfer Protocol (HTTP) 554 Method Registrations", RFC 7237, June 2014. 556 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 557 Attack", BCP 188, RFC 7258, May 2014. 559 [UDHR] General Assembly, UN., "Universal Declaration of Human 560 Rights", 1948, . 564 [UNGA2013] 565 General Assembly, UN., "UN General Assembly Resolution 566 "The right to privacy in the digital age" (A/C.3/68/ 567 L.45)", 2013, 568 . 570 Appendix A. Additional Stuff 572 This is a place holder for an Appendix if it is needed. 574 Authors' Addresses 576 Avri Doria 577 dotgay LLC 578 Providence 579 USA 581 Email: avri@acm.org 583 Niels ten Oever 584 Article 19 585 Netherlands 587 Email: niels@article19.org 589 Joana Varon 590 Brazil 592 Email: joana@varonferraz.com