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

In message <AjrmBBH0Eyt5J4brpl@nsb.fv.com>, Nathaniel Borenstein writes:

> The KidCode-related discussion has taken place in SEVERAL forums.  I
> am posting this only to the rating@junction.net and
> www-talk@www10.w3.org mailing lists.

As the KidCode Internet Draft <URL: http://pubweb.nexor.co.uk/public/
internet-drafts/cgi-bin/search/form?query=kidcode&titlefield=on>
proposal places new uses on URL's, maybe the URI working group should
be aware of this too? I've cc'ed this, but please followup to www-talk.

> The KidCode proposal is a proposal for standardizing some URL naming
> conventions, not an assertion that this is the ONLY way to do it,
> the RIGHT way to do it, or anything like that.  As it happens, I
> believe that the URL approach is the QUICKEST way to get a 75%
> solution in place, and I believe that time is of the essence.

I agree it's a quick way in that the proposal is simple, and that no
server-side changes are required. You still need to change clients to
be KidCode aware, but if the US congress is anything to go by I expect
companies will be falling over eachother trying to prove just how much
they are against pornography.

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. 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.

I think the KidCode solution is technically the wrong way to do it,
because it changes the nature of a URL, which from the Web's
conception has been nothing more than a location, to include an access
policy.

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

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.

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/.. ?

Another aspect of this is that this proposal fits badly into the HTTP
protocol. We've been batteling for months to establish that the
Content-type header dictates the content type, not a '.ps' filename
extension. This is very similar.

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.

I'm not saying I've got the perfect answer. However, I think a KidCode
HTTP header is a far more attractive option. You can then change the
access policy separately from the location, and later use different
schemes if required. No this doesn't work for gopher and FTP, but I
don't see that as a problem. Each protocol may have its own mechanisms
for handling this in an appropriate way. If it can't handle it, then
tough, maybe it shouldn't be used for delivering material with these
requirements. Alternatively, maybe URC's or some variant provide a
good place for this.

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?

In summary: I think it's fundamentally wrong to force an access policy
into a URL. Use negotiation capabilities of protocols, then you don't
break URL's, ease maintenance, and have the flexibility to switch to
different schemes.

-- Martijn
__________
Internet: m.koster@nexor.co.uk
X-400: C=GB; A= ; P=Nexor; O=Nexor; S=koster; I=M
WWW: http://web.nexor.co.uk/mak/mak.html

Received on Monday, 19 June 1995 09:55:09 UTC