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

> However, I am rather disturbed to see that the search for "the RIGHT
> way" is cut short just because politically correct people are in a
> hurry.

It's not cut short. This is an interim solution during which more 
advanced filtering can be developed. Since there's nothing out there at 
all I've heard of except SurfWatch, I don't see this as "cutting short" 
anything.

> When even authors of proposed standards aren't willing to
> assert theirs is a RIGHT way we have a problem . I'd like to be able
> to discuss proposed standards on their technical merit, without
> political accusations getting in the way.

Well, there are ways in which it is "right".  Clearly it's not perfect.

> I'd strongly urge this group to consider a resource's location and
> access policy as seperate bits of information.

If that's done, then this doesn't work for FTP.

> You might want to change a rating of a resource, without changing its
> location; either because someone has convinced you that your rating is
> too strict/liberal, or because the contents of the resouce
> change. Similarly you might like to change the location and not the
> access policy; I might for example want to add a rating to a resource
> where changing the URL is not possible or desired.

Then use a redirect. Why is changing the name of some file OK to redirect 
and changing the content of the file not OK to redirect? You could always 
use the dynamic URL mechanism if changing the names concerns you.

> What happens when another rating scheme becomes popular? Are we going
> to change all our URLs, or keep expanding them till we get
> .../KidCode=whatever/MyRating=foo/HisRating=bar/.. ?

Or you stop using KidCode when there are enough browsers that it doesn't 
matter. Or (in your proposed scheme) you leave the URL the same and add 
the new HTTP header that also restricts access.

> >From a webmaster's point of view I also find the KidCode proposal
> annoying: I am going to have to change all my URL's before kids will
> be able to see my server? Are all my URL's in printed publications
> going to be broken? Please.

Nope. Unrated URLs are up to the parent to decide what to do with.

> I'm not saying I've got the perfect answer. However, I think a KidCode
> HTTP header is a far more attractive option. 

So why haven't you proposed it and sold it to some browser vendors?  Why
say "You're wrong"  without saying "this is right"? Propose a standard,
write some code, lead, follow, get out of the way, or something.  :-)

> No this doesn't work for gopher and FTP, but I
> don't see that as a problem.

I guess actually working with WWW instead of just HTTP, I *do* see this 
as a problem.  I see plenty of ftp:// pointers on various web pages.

> Having said this, I have no particular objection to the classification
> proposed in the draft, and could well imagine this be used in a
> competing proposal with different technical implementation. Maybe the
> draft should even be split for this purpose?

Go for it.  We have absolutely no objections to another standard that's 
better and as easy to implement.

   --Darren.

Received on Monday, 19 June 1995 11:09:48 UTC