W3C home > Mailing lists > Public > www-talk@w3.org > May to June 1995

RE: Intelligent Rating Systems

From: <bede@scotty.mitre.org>
Date: Wed, 28 Jun 1995 17:22:02 -0400
Message-Id: <199506282122.RAA27811@scotty.mitre.org>
To: t-jont@microsoft.com
Cc: www-talk@www10.w3.org
   From: Jonathon Tidswell <t-jont@microsoft.com>
   Date: Wed, 28 Jun 95 13:43:52 TZ

   [ . . . ]

   Ive been following this discussion long enough to realise that MPAA and 
   PG13 are
   US film rating desriptors (authority and rating). They are consequently 
   totally inappropriate for my use as I wish Australian ratings (I am in 

This is exactly why I'd have an IANA-registered name to go with the
rating string -- you have a point of reference for getting the schema
information used in the rating string so you can decode it.  While
they're not carved in stone, the standard content-rating schemes
tend to be highly stable, so you'd never need to do this retrieval
more than about once a year.

I think the server has at least a "best-effort" responsibility to
ensure that documents get delivered with an explicit rating that makes
sense at the presumed destination --- that is, if there is a rating,
or enough information available at the server (e.g., in a content
descriptor) to derive one, and/or the client explicitly asked for a
rating, either in the protocol transaction or in an overarching
client/server subscription agreement.

We have a problem in that the Internet's geography doesn't match the
planet's political geography very well, if at all, which is why I
proposed letting the client negotiate the parameter.  For example,
let's assume the Australian MPAA equivalent is called the "AMPAA", so
your client would tell remote servers "Content-Rating: AMPAA *" or
something like that.  There might be defaults based on something
like the assumed mappings from domain names to countries, but there
are obvious problems with this idea (e.g., *.com multinational
companies, like Microsoft).

   Did you use a finalised rating rather than a content descriptor on
   purpose ?


   It seems to me that the information MPAA used to derive the rating 
   would be a more sensible/useful label. This allows US filters to add 
   rules that generate MPAA conforming ratings and other filters to 
   generate filters conforming to other rating systems.

I think this is something URCs are supposed to buy for you, and a lot
more.  I think URCs are a terrific idea, but it will take a while to
field them since, even if you ignore the fact they're not standardized
at this point, it looks like they'll need some external infrastructure
support we don't have right now.

How the MPAA arrives at its ratings doesn't seem to be quantifiable,
and to my knowledge the MPAA has never published either specifications
or justifications anyway.  There simply aren't any easy forumulae for
prurient interest or violence which define the MPAA boundary between
"R" and "PG-13", for example.  So-called "community standards" in the
US are almost invariably based on a summary opinion like an MPAA
rating, too, irrespective of the film's content, so quantifying
distinct community standards is a tough hike, too.

I think a content-rating as an HTTP header line is like a little
sticker on the outside of the document:  even politicians, the police
and Mom can understand the concept.  Giving the consumer a collection
of terms with which to derive a rating vector might be much better in
some ways, but I'll be damned if I can figure out how I'd explain it
to Mom and Senator Exon.

My feeling is that something like an MPAA rating would be one term in
the collection of terms you'd put in an embedded (?) content descriptor.
Clearly, you could have other MPAA-like terms, but you want an
(optional) sticker visible on the "outside" of the document (i.e., in
the HTTP headers) anyway.

None of this prevents a cautiously-configured client from asking for
an opinion in advance or for confirmation of a rating from a trusted
third party service.  However, I think the biggest subscribers to
ratings services might actually be document servers, since the extra
cost can be passed along to the client as something like a "validated-
adult-content-rating surcharge".  As a couple of guys have pointed
out, there's probably a market worth chasing for much more broadly-
defined rating services, since there's more to life than sex, bad
language and violence.  These extended services are where I think URCs
might see fullest use, too.

   [ . . . ]

   How am I supposed to use a rating string if I cannot decode it ?

In the scheme I'm proposing, it depends entirely on the local policy
and configuration.  Maybe you'd silently chuck the whole document
when a content rating is missing, undecipherable or garbled.  Maybe
you're configured to not care about ratings, so you display the
document.  Another approach might be to complain about it in a pop-up
and either let the user decide what to do next, or go to the rating
authority "out-of-band" and get a copy of their schema so their rating
strings don't become a recurring problem.  What you do with the
document in the meantime is strictly a local issue.

- Bede McCall   <bede@mitre.org>

  The MITRE Corporation            Tel: (617) 271-2839
  Bedford, Massachusetts           FAX: (617) 271-2423
Received on Wednesday, 28 June 1995 17:22:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 October 2010 18:14:17 GMT