Re: HTTP Futures

David Koblas (
Thu, 1 Dec 1994 03:06:29 +0100

[David Koblas asked me to forward his reply to this list. His forwarding
request is tacked onto the end of this note. --Marc Hedlund]

> Seems like these schemes would only be workable if an "unrated" page was
> assumed to be unacceptable and was "blocked" (which it sounds like Brian
> intended). I wouldn't expect the playboy people, for instance, to
> willingly rate their pages unless pressured/forced to do so. (Perhaps
> that's a bad example, since a corporation is associated with that site.
> I wouldn't expect some individual maintaining a pornographic/erotic web
> site to use MPAA ratings, and pressuring an individual to do so would be
> much more difficult.)

I would expect that Playboy would adopt a "guide" system, since if it is
easy and _free_ for them to do it and prevents unecessary legal action,
it pays off.

* There was a recent case in which a BBS system in Californa
distributed pornography to somebody in Lousiana (?). That
person took the BBS systems owners to court and won their
lawsuit regarding trafficing in indecent material.

Technically the playboy server is doing this today and they are an
easy (big) target. It is very difficult to target when half of the posting orgiate in Finalnd.

> Another solution might be to have a centralized "rating server" (or
> several) which a browser might consult before retrieving any page. In
> this model an author would not have to agree to be rated. Such a
> browser, however, would require two connections for each retrieval, one
> to the rating server and one to the origin server.

Having a centralized rating server is a problem. Since it requires
somebody to maintain it (read: money has to change hands). Setting
up such a server is interesting, but then there are issues about
browsing it, availability, etc...

I think that if any system is truely defined, it should include the
ability to check a "key" against a server. Thus when your client
receives a KEY it can query the MPAA server to see if it is valid.

> + [more from Brian]
> | While I personally abhor the thought of prohibiting the flow of
> | information, I am pointing out that it could be technologically
> | accomplished rather elegantly.
> +---
> It's hard to express how abhorrent I find the rating server idea; and I
> don't think the other schemes are much better. I agree that it could be
> accomplished. However, if a browser either rejected all unrated pages or
> consulted some central morals committee before retrieving any page, the
> effect on the flow of information would likely be quite drastic. I
> don't know that any such solution would be "elegant."

I don't classify this as "prohibiting the flow of information", but rather
as providing a mechanism to classify. When city hall and the library
install public access terminals to show they are taking part in the
"Information Superhighway" the last thing that they want is "dirty pictures"
up on their screens, it makes for bad press.

I think it should be possible to both _self_rate_ pages and have hooks
for _official_ratings_. We don't want to make it difficult for people
to read you resume (sorry, but it's unrated thus must be "hard core").
At the same time we need to think about making it possible to say
that this content has certain "properties" that some people find find
offensive (be it imagry, language, or content).

Most of these issues are not issues for most of us (or even me), but
I personally would enjoy figuring out how there could be Internet
access in every school. Lets figure out how to make this happen before
some organization figures out how to become a big brother organization
and reads/censors information before it is delivered to people.


ps. What is it going to take to make things happen, our industry is growing
commercial very quickly. Good ideas are going to take _much_ longer for
wide spread deployment. We've yet to see the "Language: en-us" header
ever get implemented.

========forwarding request follows==========

Return-Path: <>
Received: by (/\==/\ Smail3.1.28.1 #28.15)
id <>; Wed, 30 Nov 94 17:21 GMT
Received: by (/\==/\ Smail3.1.28.1 #28.15)
id <>; Wed, 30 Nov 94 17:21 GMT
Received: by point (5.0/SMI-SVR4)
id AA06678; Wed, 30 Nov 1994 17:20:32 +0800
From: (David Koblas)
Message-Id: <9412010120.AA06678@point>
Subject: Re: HTTP Futures
Date: Wed, 30 Nov 1994 17:20:32 -3200 (PST)
In-Reply-To: <>
from "Marc H." at Dec 1, 94 01:29:02 am
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 114

Can you forward that message I just sent to you to www-talk.

Somedays I just hate elm...