idnits 2.17.00 (12 Aug 2021) /tmp/idnits38801/draft-hardie-vac-req-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2022-05-14) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1.2 Scope' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 16 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 73: '...lude this option MUST be prepared to i...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 11 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT E. Hardie 2 Expires April, 1996 NASA/NAIC 3 November, 1995 5 Requirements and Scenarios for a Voluntary Access Control System 6 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its 12 areas, and its working groups. Note that other groups may also 13 distribute working documents as Internet-Drafts. Distribution of 14 this memo is unlimited. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use 19 Internet-Drafts as reference material or to cite them other than 20 as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check 23 the "1id-abstracts.txt" listing contained in the Internet-Drafts 24 Shadow Directories on ds.internic.net (US East Coast), 25 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 26 munnari.oz.au (Pacific Rim). 28 Abstract 30 This document specifies the requirements and fundamental scenarios 31 for a Voluntary Access Control system, based on the content rating 32 of Internet resources and subsequent filtering of which resources 33 may be accessed. 35 1. Introduction 37 The availability on the Internet of a variety resources, intended 38 for many different audiences, causes concern to some members of 39 the Internet community and to other members of the societies in 40 which the Internet is found. This concern suggests the 41 development of a method for creating and transmitting content 42 information for Internet resources, so that users may create 43 filters which eliminate material they would find offensive or 44 inappropriate. 46 In this document, the requirements are set out for a voluntary 47 access control system. It is presumed that such a system will 48 be composed of several interlocking elements. One element of 49 that system will be a label format for content information. 50 A second element will be a transport method or methods for 51 supplying that content information. A third element will be 52 a set of rules applied to the content information in order to 53 filter access. Requirements for the third element are described in 54 this document only functionally. Examples within this draft may 55 refer to particular content ratings or rule sets, but these should 56 not be taken as labels or rules which must be implemented for 57 conformance. A very small number of labels may be reserved by 58 VAC authors, but it is the intent of the author of this draft 59 that any system built according to the requirements described here 60 be both extensible and entirely value-neutral. 62 1.1 Terminology 64 Interactive Internet Resources: 65 Internet resources in which a user chooses to participate in an 66 interaction, with or without knowledge of the other participants. 67 Examples include mailing lists to which users subscribe and chat 68 systems such as IRC. 70 May: 71 This word, or the adjective "optional", means that this item is 72 one of an allowed set of alternatives. An implementation which 73 does not include this option MUST be prepared to interoperate with 74 another implementation which does include the option. 76 Must: 77 This word, or the adjective "required", means that the definition is 78 an absolute requirement of the specification. 80 Must not: 81 This phrase means that the definition is an absolute prohibition of 82 the specification. 84 Should: 85 This word, or the adjective "recommended", means that there may 86 exist valid reasons in particular circumstances to ignore this 87 item, but the full implications must be understood and carefully 88 weighed before choosing a different course. 90 Transaction: 91 A complete VAC action, consisting of a request from the client 92 and a response from the server. 94 User-retrieved Internet Resources: 95 Internet resources or information collections made available by 96 an information provider through protocols in which a user initiates 97 the retrieval of items from the collection. Examples of user 98 initiated processes include ftp, gopher, and http. 100 1.2 Scope 102 A VAC system must be able to handle labels applied to user-retrieved 103 Internet Resources. A VAC system may choose to apply labels to 104 Interactive Internet Resources. 106 2. Scenarios 108 2.1 An adult wishes to limit a child's access to the material on 109 the Internet, eliminating all access to all material having certain 110 characteristics. 112 2.2 Teachers wish to use structured browsing as a learning 113 activity and would like to limit student access to Internet 114 resources that have been identified as appropriate to particular 115 topics. 117 2.3 A browser user wishes to reduce time wasted in exploring 118 sites which are low-quality and would like to have prior knowledge 119 of which sites have been designated as well-designed or interesting. 121 2.4 A trainer whishes to demonstrate the usefulness of the 122 Internet to a group of novice users and would like to eliminate 123 access to material having certain characteristics and to highlight 124 material which has been designated as well-designed or interesting. 126 3. Scenario Implications 128 The scenarios listed above can be described as enabling a user 129 to create virtual "blacklists", "whitelists", and "goldlists". In 130 2.1, the user wishes to create a virtual blacklist, eliminating all 131 access to certain materials, but leaving open access to all other 132 materials. In 2.2, the reverse occurs; the user wishes to designate 133 certain materials as appropriate and eliminate access to all other 135 materials, thus creating a virtual whitelist. In 2.3, the user may 136 access any material, but will prefer certain materials which have 137 been placed on a virtual goldlist. In 2.4, a blacklist and goldlist 138 are used in combination to create a particular view of Internet 139 resources. 141 The goals of the four users in the scenarios above could be 142 accomplished through actual lists. Goldlists (usually described as 143 "cool sites" or "hot lists"), in particular, have been a part of the 144 World Wide Web almost since its inception. Creating, 145 maintaining, and transmitting these lists is, however, inefficient, 146 and the lists easily become out of date. A Voluntary Access Control 147 system can accomplish the same goals as each of these list types 148 through interaction of a rule set and a label. 150 4. Label format requirements 152 4.1 The label format must be unambiguous. Labels must always be 153 made up of the same number of parts which occur in the same order. 155 4.2 Label format must be applicable at multiple levels of granularity. 156 For user-retrieved internet resources, this means that the label format 157 must support ratings for collections as well as resources. 159 4.3 Labels must be unordered. If a client wishes to request content 160 information embodied in several labels, the order of the label 161 request or label response must not affect the labels' interpretation. 163 4.4 Labels should be human-readable. In order to make goldlists 164 possible and to allow the user to understand the cause of any 165 blacklisting, the client must be able to display the label to a user 166 for interpretation. This may be accomplished by transmitting a 167 non-human readable short form if the server is certain that the 168 client can translate it into a human readable form. 170 4.5 Labels should allow the easy application of rule sets. Where 171 numeric label characteristics can be used, they should be preferred; 172 where numeric ranges are used, a specific range order (ascending or 173 descending) should be established as a default. 175 4.6 Labels should allow the application of complex rule sets. 176 Non-numeric and non-range numeric labels must be allowed for label 177 characteristics, in order to allow for the application of rule sets 178 which cannot be easily written as numeric range boundaries. 180 4.7 Certain labels should be reserved to preserve interoperability 181 among implementations. Labels for date-rated, rating-originator, 182 and a request for all the ratings available for a particular document 183 or resource are among those which should be standardized. 185 5. Transport requirements. 187 5.1 The VAC transport protocol must be lightweight. A successful 188 VAC transaction should take place within a single network round 189 trip. 191 5.2 The VAC transport protocol should allow for persistent 192 connections. Since some clients will browse through pages at a 193 rapid rate, polling the same set of servers each time, persistent 194 connections will help improve performance. 196 5.3 In accordance with a layered network model, VAC should be 197 implementable over a variety of connection schemes and underlying 198 transport protocols; it is expected however, that it will initially 199 be transported over TCP. 201 5.4 The VAC transport protocol must support proxying. 203 5.5 Where proxies are used, VAC should distinguish between proxies 204 which cache the ratings of other servers and proxies which 205 themselves filter sites which may be accessed. Where proxies are 206 used as filter points, progress messages should indicate clearly 207 that the proxy has prevented access to a resource when such an 208 event occurs. 210 6. Rule sets requirements 212 6.1 Rule set syntax must support statements of inclusion, 213 exclusion, and display. To accomplish the goals set out in 2.1, 214 for example, the rule set would exclude all sites which are 215 labeled as having content the adult believes is inappropriate for 216 that child. In 2.2, the rule set will include only sites which 217 the teachers have labeled as appropriate to the lesson. In 2.3, 218 the labels for particular sites or objects would be displayed 219 along with the links to the objects, so that the user may choose 220 those which appeal most. In 2.4, a rule of exclusion is applied 221 prior to displaying labels for available objects. More complex 222 rule sets are, of course, possible and encouraged. 224 7. Authentication requirements 226 7.1 VAC must support the authentication of the label server to the 227 client. Given that ratings servers will likely be subject to 228 attempts at spoofing, authentication of the server to the client 229 is essential. 231 7.2 VAC should support the authentication of the client to the 232 server. Since some ratings services will be commercial 233 enterprises, client authentication should be supported. 235 7.3 VAC should be compatible with multiple mechanisms for 236 authentication, in order to accommodate variable site policies and 237 the vagaries of encryption regulations. 239 8. Intellectual property requirements 241 8.1 VAC may allow encryption of the rating. Since commercial 242 enterprises will invest time and capital in the creation of labels, 243 encryption may be necessary to protect this intellectual capital. 244 When available, VAC should use Internet-standard methods for session 245 encryption and authentication. Until such methods are standard, VAC 246 may allow a client and server to encrypt the rating, using methods 247 agreed on in out-of-band negotiations. 249 Acknowledgments 251 The author would like to acknowledge the useful discussions of 252 members of the vac-wg@naic.nasa.gov mailing list and the 253 attendees of the IETF "Read the Label" BOF at the Stockholm 254 IETF. 256 Security Considerations 258 As noted in sections 7 and 8 above. 260 Author's Addresses 262 Edward Hardie -- hardie@nasa.gov 263 Network Applications and Information Center 264 NASA Ames Research Center 265 Mail Stop 204-14 266 Moffett Field, CA 94035-1000 267 Tel: 1.415.604.0134 268 Fax: 1.415.604.0978