Re: Criticism of Kidcode (was Re: KidCode: Next steps )

I agree with many of Martijn's objections to the way the KidCode proposal
mixes location, access control, and subject description information. URCs
are intended to convey exactly this variety of information. In fact, the
URC Scenarios and Requirements draft (draft-ietf-uri-urc-scenarios-01,
<URL:http://www.acl.lanl.gov/URI/Scenarios/>) talks about the notion of
Seals Of APproval (SOAPs) that are conceptually similar to KidCode.

The current draft URC specification (draft-ietf-uri-urc-sgml-00,
<URL:http://www.acl.lanl.gov/URI/URCspec/>) allows subject (and other)
elements to be specialized to indicate that the subject description follows
a particular controlled vocabulary. This might be Library of Congress
Subject Headings, or it could be a KidCode rating system like:

<subject scheme="KidCode">12.profanity.violence.sex.religion</subject>

When following a link, a Kidcode compatible browser would fetch a
URC for the resource and scan it to see if it contained any KidCode
subject elements. If so, the value of those elements would be compared
to the current limits set by some browser preferences dialog. If the
material exceeds those limits, the browser tells the user to wait a
few years, or get an adult to run the browsing session.

Note the paragraph above says that the browser would fetch "a" URC for a
resource, not "the" URC. The URC spec is explicitly based on the notion that
multiple URCs for resources will be provided. The Library of Congress and the
Online Computer Library Center are places that would try to provide URCs for
as much stuff as they could. Schools, service-providers, ... can also provide
URCs. Since the draft spec uses HTTP for talking with URC resolvers, schools
could set up caching proxy servers to provide URCs containing their access
restriction information. This allows local school districts to use the
publisher's description, or to provide their own if they wish to override
the publisher's.

Note that the scenario above assumes the kid has a URN to the resource.
If the kid has a URL, how can we prevent the filtering process from being
short-circuited? The draft spec provides a URL to URN reverse lookup
mechanism that could be pressed into service to prevent such an obvious
attack. This also allows FTP and other URLs to be accomodated without
forcing them to change their software or naming system. Of course, it
would have a performance impact on all direct URL accesses.
 
I think that the URC mechanism is the right way to implement something
like KidCode. (Of course, as primary author of the URC spec I would say
that, wouldn't I? :-) Seriously, I do think that it is the right technical
approach. However, there is no way to ignore the fact that URNs and URCs
are not deployed yet. Sentiment in the URI group to get URNs settled is
running pretty high, so I think it is probably more effective to work on
KidCode in the expectation that URNs and URCs will be ready soon, than to
try to mandate how all publishers have to make their URLs. Anyway, I am
not so sure the KidCode syntax is going to work well on Windows-based
servers where an 8.3 name constraint has to be met.

I have to revise the SOAP portion of the requirements draft anyway, so I
will recast it to be more, dare I say, explicit about KidCode uses.  ;-)
When that is done I will send the fragment to the URI and WWW talk lists.
That should be Thursday or so.

Regards,





-- 
Ron Daniel Jr.                email: rdaniel@acl.lanl.gov
Advanced Computing Lab        voice: (505) 665-0597
MS B-287  TA-3  Bldg. 2011      fax: (505) 665-4939
Los Alamos National Lab        http://www.acl.lanl.gov/~rdaniel/
Los Alamos, NM,  87545    tautology: "Conformity is very popular"

Received on Monday, 19 June 1995 17:25:27 UTC