From: "Ronald E. Daniel" <email@example.com> Message-Id: <9506191526.ZM1210@idaknow.acl.lanl.gov> Date: Mon, 19 Jun 1995 15:26:28 -0600 In-Reply-To: Martijn Koster <firstname.lastname@example.org> To: Martijn Koster <email@example.com>, Nathaniel Borenstein <firstname.lastname@example.org> Subject: Re: Criticism of Kidcode (was Re: KidCode: Next steps ) Cc: email@example.com, firstname.lastname@example.org, email@example.com 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: firstname.lastname@example.org 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"