Internet DRAFT - draft-hardie-vac-req

draft-hardie-vac-req



HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 00:17:32 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Sat, 02 Mar 1996 13:58:01 GMT
ETag: "304c95-30a4-313853e9"
Accept-Ranges: bytes
Content-Length: 12452
Connection: close
Content-Type: text/plain

INTERNET-DRAFT                                                E. Hardie
Expires April, 1996                                           NASA/NAIC
                                                         November, 1995

   Requirements and Scenarios for a Voluntary Access Control System
		    <draft-hardie-vac-req-01.txt>

   Status of this Memo

     This document is an Internet-Draft.  Internet-Drafts are working
     documents of the Internet Engineering Task Force (IETF), its
     areas, and its working groups.  Note that other groups may also
     distribute working documents as Internet-Drafts.  Distribution of
     this memo is unlimited.

     Internet-Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other
     documents at any time.  It is inappropriate to use
     Internet-Drafts as reference material or to cite them other than
     as ``work in progress.''

     To learn the current status of any Internet-Draft, please check
     the "1id-abstracts.txt" listing contained in the Internet-Drafts
     Shadow Directories on ds.internic.net (US East Coast),
     nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
     munnari.oz.au (Pacific Rim).
     
   Abstract

     This document specifies the requirements and fundamental scenarios
     for a Voluntary Access Control system, based on the content rating
     of Internet resources and subsequent filtering of which resources
     may be accessed.
     
   
   1. Introduction

     The availability on the Internet of a variety resources, intended
     for many different audiences, causes concern to some members of
     the Internet community and to other members of the societies in
     which the Internet is found.  This concern suggests the
     development of a method for creating and transmitting content
     information for Internet resources, so that users may create
     filters which eliminate material they would find offensive or
     inappropriate.

     In this document, the requirements are set out for a voluntary
     access control system.  It is presumed that such a system will
     be composed of several interlocking elements.  One element of 
     that system will be a label format for content information.  
     A second element will be a transport method or methods for 
     supplying that content information.  A third element will be
     a set of rules applied to the content information in order to
     filter access.  Requirements for the third element are described in 
     this document only functionally.  Examples within this draft may 
     refer to particular content ratings or rule sets, but these should
     not be taken as labels or rules which must be implemented for      

     conformance.  A very small number of labels may be reserved by
     VAC authors, but it is the intent of the author of this draft 
     that any system built according to the requirements described here 
     be both extensible and entirely value-neutral.


   1.1 Terminology
     
     Interactive Internet Resources:
     Internet resources in which a user chooses to participate in an
     interaction, with or without knowledge of the other participants.
     Examples include mailing lists to which users subscribe and chat 
     systems such as IRC.

     May:
     This word, or the adjective "optional", means that this item is
     one of an allowed set of alternatives.  An implementation which
     does not include this option MUST be prepared to interoperate with
     another implementation which does include the option.

     Must:      
     This word, or the adjective "required", means that the definition is
     an absolute requirement of the specification.

     Must not:  
     This phrase means that the definition is an absolute prohibition of
     the specification.

     Should:
     This word, or the adjective "recommended", means that there may
     exist valid reasons in particular circumstances to ignore this
     item, but the full implications must be understood and carefully
     weighed before choosing a different course.

     Transaction: 
     A complete VAC action, consisting of a request from the client 
     and a response from the server.

     User-retrieved Internet Resources:
     Internet resources or information collections made available by
     an information provider through protocols in which a user initiates
     the retrieval of items from the collection.  Examples of user
     initiated processes include ftp, gopher, and http.  


   1.2 Scope

     A VAC system must be able to handle labels applied to user-retrieved
     Internet Resources.  A VAC system may choose to apply labels to 
     Interactive Internet Resources. 


   2. Scenarios

     2.1 An adult wishes to limit a child's access to the material on
     the Internet, eliminating all access to all material having certain
     characteristics.

     2.2 Teachers wish to use structured browsing as a learning
     activity and would like to limit student access to Internet 
     resources that have been identified as appropriate to particular 
     topics.

     2.3 A browser user wishes to reduce time wasted in exploring
     sites which are low-quality and would like to have prior knowledge
     of which sites have been designated as well-designed or interesting.

     2.4 A trainer whishes to demonstrate the usefulness of the
     Internet to a group of novice users and would like to eliminate
     access to material having certain characteristics and to highlight
     material which has been designated as well-designed or interesting.

   3. Scenario Implications

     The scenarios listed above can be described as enabling a user
     to create virtual "blacklists", "whitelists", and "goldlists".  In
     2.1, the user wishes to create a virtual blacklist, eliminating all
     access to certain materials, but leaving open access to all other
     materials.  In 2.2, the reverse occurs; the user wishes to designate
     certain materials as appropriate and eliminate access to all other

     materials, thus creating a virtual whitelist.  In 2.3, the user may
     access any material, but will prefer certain materials which have
     been placed on a virtual goldlist.  In 2.4, a blacklist and goldlist
     are used in combination to create a particular view of Internet 
     resources.

     The goals of the four users in the scenarios above could be
     accomplished through actual lists.  Goldlists (usually described as
     "cool sites" or "hot lists"), in particular, have been a part of the
     World Wide Web almost since its inception.  Creating,
     maintaining, and transmitting these lists is, however, inefficient,
     and the lists easily become out of date.  A Voluntary Access Control
     system can accomplish the same goals as each of these list types
     through interaction of a rule set and a label.

   4. Label format requirements

     4.1 The label format must be unambiguous.  Labels must always be 
     made up of the same number of parts which occur in the same order.

     4.2 Label format must be applicable at multiple levels of granularity. 
     For user-retrieved internet resources, this means that the label format
     must support ratings for collections as well as resources.  

     4.3 Labels must be unordered.  If a client wishes to request content
     information embodied in several labels, the order of the label
     request or label response must not affect the labels' interpretation.

     4.4 Labels should be human-readable.  In order to make goldlists
     possible and to allow the user to understand the cause of any
     blacklisting, the client must be able to display the label to a user
     for interpretation.  This may be accomplished by transmitting a
     non-human readable short form if the server is certain that the 
     client can translate it into a human readable form.

     4.5 Labels should allow the easy application of rule sets.  Where
     numeric label characteristics can be used, they should be preferred;
     where numeric ranges are used, a specific range order (ascending or
     descending) should be established as a default.

     4.6 Labels should allow the application of complex rule sets.
     Non-numeric and non-range numeric labels must be allowed for label
     characteristics, in order to allow for the application of rule sets
     which cannot be easily written as numeric range boundaries.

     4.7 Certain labels should be reserved to preserve interoperability
     among implementations.  Labels for date-rated, rating-originator, 
     and a request for all the ratings available for a particular document
     or resource are among those which should be standardized.

   5. Transport requirements.

     5.1  The VAC transport protocol must be lightweight.  A successful
     VAC transaction should take place within a single network round 
     trip.

     5.2  The VAC transport protocol should allow for persistent
     connections.  Since some clients will browse through pages at a
     rapid rate, polling the same set of servers each time, persistent
     connections will help improve performance.

     5.3  In accordance with a layered network model, VAC should be
     implementable over a variety of connection schemes and underlying
     transport protocols; it is expected however, that it will initially
     be transported over TCP.
     
     
     5.4  The VAC transport protocol must support proxying.  

     5.5  Where proxies are used, VAC should distinguish between proxies
     which cache the ratings of other servers and proxies which 
     themselves filter sites which may be accessed.  Where proxies are
     used as filter points, progress messages should indicate clearly
     that the proxy has prevented access to a resource when such an 
     event occurs.

   6. Rule sets requirements

     6.1 Rule set syntax must support statements of inclusion,
     exclusion, and display.  To accomplish the goals set out in 2.1,
     for example, the rule set would exclude all sites which are
     labeled as having content the adult believes is inappropriate for
     that child.  In 2.2, the rule set will include only sites which
     the teachers have labeled as appropriate to the lesson.  In 2.3,
     the labels for particular sites or objects would be displayed
     along with the links to the objects, so that the user may choose
     those which appeal most.  In 2.4, a rule of exclusion is applied
     prior to displaying labels for available objects.  More complex
     rule sets are, of course, possible and encouraged.

   7. Authentication requirements

     7.1 VAC must support the authentication of the label server to the
     client.  Given that ratings servers will likely be subject to
     attempts at spoofing, authentication of the server to the client
     is essential.

     7.2 VAC should support the authentication of the client to the
     server. Since some ratings services will be commercial
     enterprises, client authentication should be supported.

     7.3 VAC should be compatible with multiple mechanisms for
     authentication, in order to accommodate variable site policies and 
     the vagaries of encryption regulations.

   8. Intellectual property requirements

     8.1 VAC may allow encryption of the rating.  Since commercial
     enterprises will invest time and capital in the creation of labels,
     encryption may be necessary to protect this intellectual capital.
     When available, VAC should use Internet-standard methods for session
     encryption and authentication.  Until such methods are standard, VAC
     may allow a client and server to encrypt the rating, using methods
     agreed on in out-of-band negotiations.

      
   Acknowledgments

     The author would like to acknowledge the useful discussions of
     members of the vac-wg@naic.nasa.gov mailing list and the
     attendees of the IETF  "Read the Label" BOF at the Stockholm
     IETF.     
    
   Security Considerations
     
     As noted in sections 7 and 8 above.

   Author's Addresses

     Edward Hardie -- hardie@nasa.gov
     Network Applications and Information Center
     NASA Ames Research Center
     Mail Stop 204-14
     Moffett Field, CA 94035-1000
     Tel: 1.415.604.0134
     Fax: 1.415.604.0978