# Re: Agent-mediated access, kidcode critiques, and community standards

Stephen D. Williams (sdw@lig.net)
Tue, 20 Jun 1995 19:34:06 -0400 (EDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Karen R. Sollins: "Re: date in URN"
- Previous message: Ted Hardie: "Re: Agent-mediated access, kidcode critiques, and community standards"
- In reply to: Ted Hardie: "Agent-mediated access, kidcode critiques, and community standards"
- Next in thread: Mark Madsen: "Re: Agent-mediated access (was Re: Criticism of Kidcode...)"

    Message-Id: <m0sOCo3-0009u7C@sdwsys>

    From: sdw@lig.net (Stephen D. Williams)

    Subject: Re: Agent-mediated access, kidcode critiques, and community standards

    To: hardie@merlot.arc.nasa.gov (Ted Hardie)

    Date: Tue, 20 Jun 1995 19:34:06 -0400 (EDT)

    In-Reply-To: <199506201827.LAA09250@merlot.arc.nasa.gov> from "Ted Hardie" at Jun 20, 95 11:27:50 am

>
...
> obstructionism. We are, at the base, discussing how the content of
> the Web will be understood and how we will interact with it in the
> future; these are concerns as important as they are immediate.

Exactly. We have an opportunity to add value to existing and future
data via metadata.

> For those who believe that there is an immediate need to
> establish a reasonable, voluntary labelling scheme, Martijn Koster and
> Ronald Daniel have made very cogent arguments about the need to keep
> access control, labelling, and subject description apart. Ronald

I agree, although I don't think the mechanism should be separate.
Only the values of the metadata and interpretation should differ.

> Daniel's discussion of URC indicates a working group which is dealing
> with this issue in a very cogent and complete manner. For those who
> need something more immediately, Martijn's work with Robot exclusion
> may provide a workable, ready-to-hand solution. According to the
> Robot exclusion standard, robots check for a file called "robots.txt"
> at any site they traverse; it lists user agent, then the partial URL

My take is that this could immediately take the form of .meta files.
/.meta for sitewide, /.../.meta for subtrees, and /.../filename.meta
for file specific. With the additional capability of embedding the
metadata as tags in formats amenable to it (ie. HTML). The .meta
files can be retrieved as simple files or automatically added to
MIME headers, etc. The use of the metadata can be multifaceted.

Only general arenas and syntaxes of metadata need to be created now,
and if done carefully will be extendable to adopt all the current and
future projects relating to metadata. (URC, OCLC, WWW.org, etc.)

...
> Ultimately, of course, it's a hack, and it would need to be
> replaced. Several interesting methods for replacing it have been
> discussed; I believe that the URC method with SOAPs covers the ground
> very well. I have also request to beta test the "Silk" URA, and I
> encourage others interested in this issue to do the same; if it can

Likewise...

I think that the important points are defining the metadata format
(meta meta data: <meta AUTHORITY FORMAT ...>), immediate methods of
access to metadata if it can be done in an upward compatible way
(naming conventions, proxy servers, trivially modified clients), and
persuit of very complete models of metadata, etc. access
(URN/URC/URA).

...
> which don't interest them. We should not be choosing for them what
> might interest them or what they should ignore, and interim solutions
> we may have that do that should make clear that even the author's
> opinion of a work should not be its sole reference for appropriate
> audience.
>
> Regards,
> Ted Hardie
> NASA NAIC

I don't believe that many have seen my earlier proposals, so I'll repost
here:

Return-Path: <sdw>
Subject: Re: New Internet Draft on protecting children AND free speech
To: droelke@spirit.aud.alcatel.com (Daniel R. Oelke)
Date: Fri, 9 Jun 1995 01:03:39 -0400 (EDT)
Cc: caci@media.mit.edu, www-talk@www10.w3.org, rating@junction.net,
dnew@sgf.fv.com, nsb@nsb.fv.com

> First all - I *have* read, digested, and thought about the KidCode
> proposal. Here are some points to ponder, both pro and con.

Likewise...

> 1) This is not a "bad" idea per say, but there are some
> realities that need to be applied to the idea of adding
> "KidCode" into the name of everything.
...
> 2) The rating authority section just touches on the idea.
...
> 3) It might get the U.S. government off the idea of needing
> censorship laws, but I doubt it. These are politicians who
...

Let me try to clarify the current proposed solutions, IMHO, so that we
can talk about pros and cons more clearly:

Index: Goals - Meta Info - Retrieval Method - Misc - One Design

Goals:
Prevent censorship (ie. via government laws, inuendo, etc.)
Lower risk to providers of access and information
Increase quality of information available
Insure longevity of openness of Internet communication
Make Internet access more 'safe' and controllable for minors

Meta Information to be added:

Meta objects that contain implicitly or explicitly:

Authority, Viewpoint, indexes/content/attributes(ICA), ICA type

ICA info can be divided pretty broadly into factual info
and opinion/ratings with a fuzzy intersection.
(Librarians believe for instance that they can index
and categorize in an objective matter.)

Authority = Author, Other (commercial, group, gov's, schools)
Viewpoint = Author, US, Iran, High School, etc. (estimated
from the expertise of the Authority; ie. I would be
guessing about suitability for Iran with my current
hear-say knowledge. One of the attributes could
indicate veracity.)
Attributes (aka: content, indexes, ratings, etc.) = any kind
of system of meta information. Objective, factual
attributes being clearly defined measures (body count,
number of erogenous zones, mention of electron
microscopes). Subjective, opinion information (ie.
ratings) being suitability for ages, status,
societies, etc.
ICA Type = Attribute format/standard indicator. Could be
KidCode, URC's, LC, CC, etc.

There are lots of possible policy, usage, filtering,
deployment, etc. issues that are relavent.

Retrieval Method:

Technical details by which meta information and filtering
specs are fed to a meta-info comparator and a decision is made
about what action to take by a browser (or browser proxy).

Designs on the table (that I noticed):

Document Tags (html) (META or CONTENT tag, URC's, etc.)
Header Tags (rfc822/news version of Document Tags)
Mime Tags (either as header or as multi-part document doc)
Transaction (Radius?, html) server for retrieval clearing.
Note that this could include hierarchies a la DNS,
'feeds' a la Netnews(Usenet), subscription a la
mailling lists, etc. Could be positive and/or
negative.
Server subtree wide meta retrieval
Caching proxy with cached 'ratings' using any other method.
(Note that this allows implementation now without
changing browser. Also, for ppp, slip, etc. means
that retrictions couldn't be bypassed easily.)
URL encoding (KidCode.1)
URL Forms encoding (KidCode.2)

Misc:

Multiple methods and attribute standards will need to be
supported. Multiple simultaneous meta-information sources
needs to be supported by the browser/browser proxy.

Existing and emerging meta-information standards should
be adopted asap. (I have a growing list now.)

Mapping needs to be provided so that factual information can
be converted to ratings and so that minimal filtering
selections can be matched against multiple authorities and
attribute typings.

This effort should be used to allow better ways to find
info along with filtering out unwanted info.

All types of communication should be covered: all IP,
telnet, etc. (This is mostly said by mentioning URL's.)

Only the frame work needs to be standardized, although it
would be beneficial to have at least one sanctioned
attribute typing standard to start using for immediate
purposes.

News, as an example, could be done as Headers by Author, group
messages (similar to a control message in my original scheme)
and ratings servers by third parties, and groupwide default by
charter organizers.

My favorite deployment path and meta standard is:

Establish simple meta URL/www/html conventions (*.meta, plus
directory .meta and system //.meta data) for retrieval of meta
information pertaining to a document. Something easily cachable.

Assemble current meta-info standards and either extend or create
only what's missing.

Create one or more ratings server methods (http and radius possibly).

Modify www proxy/caching servers (cern_httpd, etc.). The advantage
to this is a) modified clients aren't required, b) covers multiple
protocols, c) when used as the only method to get through a firewall
is effective in preventing client side workarounds like reinstalling.

Classification of type of account/filtering profile could be done
based on both static information about the account, ip address, etc.
and also dynamically based on typing in a password to a
current-session adult access form.

Regarding c): I would be very upset if this were used to censor adults
and an proposing this only for the case where an ISP is selling
ppp/slip access to a minor or a family that wishes to ensure
restrictions on their account.

Then modify clients to allow personal filtering.

Comments Requested.
sdw

    --
    Stephen D. Williams 25Feb1965 VW,OH (FBI ID) sdw@lig.net http://www.lig.net/sdw
    Consultant, Vienna,VA Mar95- 703-918-1491W 43392 Wayside Cir.,Ashburn, VA 22011
    OO/Unix/Comm/NN       ICBM/GPS: 39 02 37N, 77 29 16W home, 38 54 04N, 77 15 56W
    Pres.: Concinnous Consulting,Inc.;SDW Systems;Local Internet Gateway Co.;28May95

- Next message: Karen R. Sollins: "Re: date in URN"
- Previous message: Ted Hardie: "Re: Agent-mediated access, kidcode critiques, and community standards"
- In reply to: Ted Hardie: "Agent-mediated access, kidcode critiques, and community standards"
- Next in thread: Mark Madsen: "Re: Agent-mediated access (was Re: Criticism of Kidcode...)"