RE: Intelligent Rating Systems

   Date: Sat, 24 Jun 1995 22:01:13 -0700 (PDT)
   From: Michael Dillon <michael@junction.net>

   [ . . . ]

   This is precisely why I am proposing that ratings be served up by a third 
   party, i.e. not the WWW author nor the WWW server operator. Any third 
   party who wishes can set up a ratings server and serve up ratings. In 

   [ . . . ]

I might be reading it all wrong, but this looks like a scheme which
would entail an awful lot of overhead.  Are you suggesting a scheme
where a client would be required to do two retrievals for every
document or object retrieved (one to an independent rating server and
a second one for the document)?  This also suggests that, as is the
case with commerce protocols like iKP and its ilk, we'd need a new and
distinct "content-rating" protocol.

I'll stick by the notion that rating information should come back to
the client from the server encoded in an HTTP header line.  The server's
rating could optionally be verified at its source, assuming it
contains enough information to identify the source.  This preserves
the option of checking a URL or URI with a third-party rating service
*before* retrieving the corresponding document from a server, but if
you're willing to trust a server's rating estimates the extra step
isn't necessary.

This leaves the initial responsibility for deriving and/or verifying a
rating vector with the server operator, and the server operator may
want to tailor rating vectors to target destinations.  Maybe this
tailored rating could just be another field in the encoding.

This doesn't preclude the client adding or substituting one or more
local rating vectors which contain extra terms for local or personal
opinions about URIs, servers and/or third-party rating services.
Local content-rating vectors might have extra terms like a
"Political Correctness Multiplier", for example.

How to derive and encode content ratings and the semantics of content
ratings shouldn't become embedded in a content-rating syntax, which
needs to be kept simple, securable and extensible.  For the sake of
the discussion, I'll suggest a strawman two- or three-field header
defined:

    Content-rating ::= "Content-Rating:" <rater> <rating-vector>

    <rater>  ::=  <null> | <IANA-registered-rater-name-string>
    <rating-vector>  ::=  <quoted-ASCII-string>

In this scheme, the HTTP client might receive a header like this:

    Content-Rating: MPAA "PG13+AC+AL"

The client might also *send* a header like this as part of a
negotiation, as is now the case with "Accept:" headers.  In the case
of a server, though, the server is claiming that the "MPAA" rated the
attached document "PG13+AC+AL".  The client is free to verify this
claim, possibly by using a "content-rating" protocol.

At the very least, we might want to give some concrete guidance about
what clients should do with the string "MPAA".   I seriously doubt the
value of trying to standardize either the semantics or syntax of a
contend rating vector like "PG13+AC+AL" since that's strictly the
MPAA's business, but you'd need to have a few default and generic
content ratings and semantics defined, so that header lines like

    Content-Rating: "U"

and absent header lines can be handled intelligently by the client.



- Bede McCall   <bede@mitre.org>

  The MITRE Corporation            Tel: (617) 271-2839
  Bedford, Massachusetts           FAX: (617) 271-2423

Received on Monday, 26 June 1995 20:06:43 UTC