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

Martijn Koster <m.koster@nexor.co.uk> said:
  > My suggestion of using a KidCode HTTP header didn't provoke much
  > response, while I think it has some advantages: the user gets the
  > choice, it scales, it can be added to exisiting code easily, scales,
  > doesn't require a third party infrastructure, and will be quite easy
  > to establish as a standard since it is a simple extension to http. It
  > can also easily coexist with community schemes.
  > 
  > I'd appreciate some feedback: is the lack of support for protocols
  > other than HTTP perceived to be a big problem? Will UR[CA]
  > infrastructure takes as much time to deploy as adding a header to
  > existing code? Is the rush for an interrim solution justified? Is an
  > HTTP header a good idea?

Okay, here's some feedback.  I prefer a KidCode header.  I think
building the information into the URL is a bad idea for all the reasons
stated previously.

A KidCode-capable client could block access to "unrated" documents that
have no KidCode header, or it could just call them "unrated" and
display them.  That could be a configurable option.

I still have fundamental problems with the notion that a server can
rate itself, nevermind censor itself.  A document I consider
inoffensive may prove to be offensive elsewhere.  I don't see where the
objective criteria are.  Consider nudity.  In some countries, a picture
showing an otherwise fully clothed woman's bare ankle or arm might be
considered nudity.  What constitutes nudity in the U.S.?  A rear view
of a naked woman?  (It's always women, isn't it!?) A front view of a
naked woman from just above the nipples?  (Can I say "nipples"?  Or is
that obscene?)

Dave Kristol

Received on Tuesday, 20 June 1995 18:31:54 UTC