This document is part of the <a HREF="https://www.w3.org/"="">W3C</a> (<a HREF="https://www.w3.org/"="">http://www.w3.org/</a>)
<a HREF="https://www.w3.org/Metadata/"="">Metadata</a> activity.


A list of current W3C Recommendations and other technical documents
can be found at <a HREF="https://www.w3.org/TR"="">http://www.w3.org/TR</a>.
<br="">

This document assumes that the reader has a working knowledge of PICS-1.1.
All labels referred to here are assumed to be PICS-1.1 compliant labels.
See <a HREF="#References"="">references</a> [PicsServices] and [PicsLabels]
for details.

 ;1 (PicsRule-1.1 ; ;

 ;2 ; ; ; ; (

 ;3 ; ; ; ; Policy (RejectByURL ("http://*@www.grody.com:*/*" ;

 ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; "http://*@www.gross.net:*/*"))

 ;4 ; ; ; ; Policy (AcceptIf "otherwise")

 ;5 ; ; ; ; )

 ;6 )The numbers on the left are line numbers for ease of reference; they
aren't part of the actual rule.
This example forbids access to a specific set of URLs, without using
any PICS labels. Any URL that specifies the host www.grody.com or www.gross.net
will be blocked, regardless of the username, port number, or particular
file path that is specified in the URL; any other URLs are considered acceptable.

 ;1 (PicsRule-1.1

 ;2 ; ; ; ; (

 ;3 ; ; ; ; serviceinfo (

 ;4 ; ; ; ; ; ; ; ; "http://www.coolness.org/ratings/V1.html"

 ;5 ; ; ; ; ; ; ; ; shortname "Cool"

 ;6 ; ; ; ; ; ; ; ; bureauURL "http://labelbureau.coolness.org/Ratings"

 ;7 ; ; ; ; ; ; ; ; UseEmbedded "N"

 ;8 ; ; ; ; ; ; ; ; )

 ;9 ; ; ; ; Policy (RejectIf "((Cool.Coolness <;= 3) or (Cool.Graphics >= 3))")

10 ; ; ; ; Policy (AcceptIf "otherwise")

11 ; ; ; ; ) ;

12 )
This rule checks the rating given to documents according to the "Cool"
rating service ("http://www.coolness.org/ratings/V1.html"). Labels will
be fetched from the label bureau "http://labelbureau.coolness.org/Ratings".
Labels embedded in the document are ignored because the document authors
can't be trusted to assess their own coolness. ; Documents which are
not sufficiently cool or have too many graphics will be blocked. Everything
else, including unlabeled documents, will be allowed.

 ;1 (PicsRule-1.1

 ;2 ; ; ; ; (

 ;3 ; ; ; ; ServiceInfo (

 ;4 ; ; ; ; ; ; ; ; name "http://www.coolness.org/ratings/V1.html"

 ;5 ; ; ; ; ; ; ; ; shortname "Cool"

 ;6 ; ; ; ; ; ; ; ; bureauURL "http://labelbureau.coolness.org/Ratings"

 ;7 ; ; ; ; ; ; ; ; )

 ;8 ; ; ; ; Policy (RejectUnless "(Cool.Coolness)")

 ;9 ; ; ; ; Policy (AcceptIf "((Cool.Coolness > 3) and (Cool.Graphics <; 3))")

10 ; ; ; ; Policy (RejectIf "otherwise")

11 ; ; ; ; ) ;

12 )
This rule also checks the rating given to documents according to the "Cool"
rating service. In this case, because UseEmbedded is not specified, it
defaults to using embedded labels in addition to labels it fetches from
the label bureau. Line 8 says that documents will be blocked unless we
have a rating on the "Coolness" scale of the "Cool" rating system ("http://www.coolness.org").
Line 9 says that documents which are sufficiently cool, and don't have
too many graphics, will be passed. Line 10 says to block all other documents.

 ;1 (PicsRule-1.1

 ;2 ; ; ; ; (

 ;3 ; ; ; ; ; ; ; ; name ; ; ; (rulename "Example 4"

 ;4 ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; description "Example 4 from PICSRules spec; simply shows ;

 ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; how PICSRules rules are formed. This rule is ;

 ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; not actually intended for use by real users.") ;

 ;5 ; ; ; ; ; ; ; ; source (sourceURL ;

 ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; "http://www1.raleigh.ibm.com/pics/PICSRulz/Example1.html")

 ;6 ; ; ; ; ; ; ; ; ServiceInfo (name "http://www.coolness.org/ratings/V1.html"

 ;7 ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; shortname "Cool"

 ;8 ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; bureauURL "http://labelbureau.coolness.org/Ratings")

 ;9 ; ; ; ; ; ; ; ; ServiceInfo ("http://www.kid-protectors.org/ratingsv01.html"

10 ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; shortname "KP")

11 ; ; ; ; ; ; ; ; Policy (RejectByURL ("http://*@www.badnews.com:*/*" ;

 ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; "http://*@www.worsenews.com:*/*"

 ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; "*://*@18.0.0.0!8:*/*"))

12 ; ; ; ; ; ; ; ; Policy (AcceptByURL "http://*rated-g.org/movies*")

13 ; ; ; ; ; ; ; ; Policy (AcceptIf "(KP.educational = 1)" ;

 ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; Explanation "Always allow educational content.")

14 ; ; ; ; ; ; ; ; Policy (RejectIf "(KP.violence >= 3)" ;

 ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; Explanation "Blood's a %22scary%22 thing.")

15 ; ; ; ; ; ; ; ; Policy (RejectUnless "(Cool.Graphics <; 4)" )

16 ; ; ; ; ; ; ; ; Policy (AcceptIf "otherwise")

17 ; ; ; ; )

18 )
<b="">attrvalpair</b>:: <i="">attribute whitespace value</i> | <i="">value



</i><b="">attribute</b>:: <i="">alphanumstr</i> ;



<b="">value</b>:: <i="">quotedstring</i> |'(' <i="">attrvalpair+</i> ')'



<b="">quotedstring</b>:: '"'<i="">notdoublequotechar</i>*'"' | "'"<i="">notsinglequotechar</i>*"'"



<b="">alphanumstr</b>:: (<i="">alphanum </i>| '.')+



<b="">whitespace</b>:: ' ' | '\t' | '\r' | '\n' ;



<b="">alphanum</b>:: '0' - '9' | 'A' - 'Z' | 'a' - 'z'



<b="">notdoublequotechar </b>:: any Unicode character except "
<b="">notsinglequotechar </b>:: any Unicode character except '
The grammar uses " to quote strings, but ' may be used instead, provided
that the same character starts and ends the string:

As a shorthand in the rest of the BNF, we will use "double quotes" for
all quoted strings, with the understanding that single quotes are equally
valid as a delimiter. Also as a shorthand, we use <i="">notquotechar</i> to
mean any Unicode character other than the quoting delimiter (either " or
') ; used for the current string.


The other quoting character may appear within a string. In order to
accommodate the use of both single and double quotes inside strings, the
following escaping conventions apply:

Character string as represented in a PICS Rule | Parsed and decoded character string |
"string" | string |
'string' | string |
'This is "quoted" text.' ; | This is "quoted" text. |
"It's nice to quote." ; | It's nice to quote. |
"It%27s nice to %22quote.%22" | It's nice to "quote." |
"50%25 of test scores are above the median" | 50% of test scores are above the median |
"50% are below the median" | <;syntactically invalid string> |
Note that in order to properly interpret a PICSRules rule, the UTF-8
transformation is applied first, to convert the rule into a sequence of
Unicode characters. Each quoted string must then be passed through a converter
that unescapes quotes,
<br="">converting %22 to ", %27 to ', and %25 to %.


Note that all attribute names are case <b="">in</b>sensitive, while the
case of values MUST be preserved. However, individual clauses and/or attributes
MAY define their values to be case-insensitive.

The syntax of a comment is:

<b="">comment</b>:: '{' <i="">comment-text*</i> '}'

<b="">comment-text</b>:: any characters except '}'
Note that a result of the above syntax is that comments may not be nested.


Comments may appear anywhere in PICSRules rules. A user-agent MAY remove
the comments during lexical analysis of the rule; text within comments
MUST NOT influence the interpretation of the rule in any manner. Note also
that user-agents which generate or export PICSRules rules MAY choose to
strip out comments before generating, exporting, or transmitting them.

<b="">rule</b>:: '(' 'PicsRule-'<i="">verMajor</i>'.'<i="">verMinor</i> <i="">rule-body</i> ')'



<b="">verMajor</b> :: <i="">integer



</i><b="">verMinor</b> :: <i="">integer



</i><b="">rule-body</b> :: '(' <i="">rule-clauses</i> ')'



<b="">rule-clauses</b> :: <i="">rule-clause+



</i><b="">rule-clause</b> :: <i="">policy-clause</i> | ;

 ; ; ; ; ; ; ; ; ; ; ; ; ; ; <i="">name-clause</i> |

 ; ; ; ; ; ; ; ; ; ; ; ; ; ; <i="">source-clause</i> |

 ; ; ; ; ; ; ; ; ; ; ; ; ; ; <i="">service-clause</i> |

 ; ; ; ; ; ; ; ; ; ; ; ; ; ; <i="">opt-extension-clause</i> |

 ; ; ; ; ; ; ; ; ; ; ; ; ; ; <i="">req-extension-clause</i> |

 ; ; ; ; ; ; ; ; ; ; ; ; ; ; <i="">extension-aval



</i><b="">policy-clause</b> :: 'Policy' '(' <i="">policy-attribute+</i> ')'



<b="">policy-attribute</b> :: ['Explanation'] <i="">quotedstring</i> |

 ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; 'RejectByURL' <i="">URL-strings </i>|

<i=""> ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; </i>'AcceptByURL' <i="">URL-strings </i>|<i=""> ;

</i> ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; 'RejectIf' <i="">policy-string </i>|

 ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; 'RejectUnless' <i="">policy-string </i>|

 ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; 'AcceptIf' <i="">policy-string </i>|

 ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; 'AcceptUnless' <i="">policy-string </i>|

 ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; <i="">extension-aval</i>
<b="">URL-strings :: </b><i="">URL-string </i>|<i=""> </i>'(' ['patterns'] <i="">URL-string</i>+ ')'
<b="">URL-string :: </b>'"'<i="">URLpattern</i>'"'
<b="">policy-string ::</b><i=""> </i>'"'<i="">policy-expression</i>'"'



<b="">name-clause</b> :: 'name' '(' <i="">name-attribute+</i> ')'



<b="">name-attribute</b> :: ['Rulename'] <i="">quotedstring</i> |

 ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; 'Description' <i="">quotedstring</i> |

 ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; <i="">extension-aval



</i><b="">source-clause</b> :: 'source' '(' <i="">source-attribute+</i> ')'



<b="">source-attribute</b> :: ['SourceURL'] <i="">quotedURL</i> |

 ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; 'CreationTool' <i="">quotedstring</i> |

 ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; 'author' <i="">quoted-address</i> |

 ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; 'LastModified' <i="">quoted-date</i> |

 ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; <i="">extension-aval



</i><b="">service-clause</b> :: 'serviceinfo' '(' <i="">service-attribute+</i> ')'



<b="">service-attribute</b> :: ['Name'] <i="">quotedURL</i> |

 ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; 'shortname' <i="">quotedstring</i> |

 ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; 'BureauURL' <i="">quotedURL</i> |

 ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; 'UseEmbedded' <i="">yes-no</i> |

 ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; 'Ratfile' <i="">quotedstring</i> |

 ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; 'BureauUnavailable' <i="">pass-fail</i> |

 ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; <i="">extension-aval</i>
<b="">yes-no :: </b>'"'<i="">Y-N</i>'"'
<b="">Y-N</b> :: 'Y' | 'N'
<b="">pass-fail</b> :: '"'<i="">P-F</i>'"'
<b="">P-F</b> :: 'PASS' | 'FAIL'
<b="">opt-extension-clause</b> :: 'optextension' '(' <i="">extension-name+</i> ')'



<b="">extension-name</b> :: ['extension-name'] <i="">quotedURL</i> | 'shortname' <i="">quotedstring </i>|

 ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; <i="">extension-aval



</i><b="">req-extension-clause</b> :: 'reqextension' '(' <i="">extension-name+</i> ')'



<b="">extension-aval</b> :: <i="">attrvalpair</i>
<b="">quotedURL</b> :: '"'<i="">URL</i>'"'
<b="">URL</b> :: as defined in RFC-1738 for URLs.



<b="">quoted-address</b> :: '"'<i="">e-mail-address</i>'"'



<b="">e-mail-address</b> :: as defined in RFC-822 for addresses.
<b="">quoted-ISO-date ::</b> '"'YYYY'-'MM'-'DD'T'hh':'mmStz'"'

 ; ; ; ; based on the ISO 8601:1988 date and time standard, restricted

 ; ; ; ; to the specific form described here:

 ; ; ; ; <b="">YYYY ::</b> four-digit year

 ; ; ; ; <b="">MM ::</b> two-digit month (01=January, etc.)

 ; ; ; ; <b="">DD ::</b> two-digit day of month (01 through 31)

 ; ; ; ; <b="">hh ::</b> two digits of hour (00 through 23) (am/pm NOT allowed)

 ; ; ; ; <b="">mm ::</b> two digits of minute (00 through 59)

 ; ; ; ; <b="">S ; ::</b> sign of time zone offset from UTC ('+' or '-')

 ; ; ; ; <b="">tz ::</b> four digit amount of offset from UTC

 ; ; ; ; ; ; ; ; ; ; (e.g., 1512 means 15 hours and 12 minutes)

 ; ; ; ; For example, "1994-11-05T08:15-0500" is a valid <i="">quoted-ISO-date

</i> ; ; ; ; denoting November 5, 1994, 8:15 am, US Eastern Standard Time

 ; ; ; ; <b="">Note:</b> The ISO standard allows considerably greater

 ; ; ; ; flexibility than that described here. ; PICS requires <i="">precisely

</i> ; ; ; ; the syntax described here -- neither the time nor the time zone may

 ; ; ; ; be omitted, none of the alternate formats are permitted, and

 ; ; ; ; the punctuation must be as specified here.
<b="">Note:</b> The PICS-1.1 label format spec inadvertently used a date format ;

that was slightly incompatible with the ISO date format. In particular, ;

that spec required '.' instead of '-' as the separator between year and ;

month, and between month and day. This spec corrects that error, so that

it is incompatible with the PICS-1.1 label spec's date format, but ;

compatible with the ISO date format.
The <b="">serviceinfo </b>clause or clauses specify how to find labels
associated with a given URL (from one or more label bureaus or embedded
in the document). The <b="">Policy </b>clause or clauses determine whether
an accept or reject answer is returned. Extension clauses (either required
or optional) may cause additional labels to be collected or discarded,
or otherwise change the meaning of a rule. The semantics of a rule are
defined based on a user agent making a ; best-effort attempt to retrieve
labels from all the specified sources and using all the retrieved labels
in evaluating policy clauses. A user agent may, however, perform optimizations,
such as consulting a local source (a cache or a CD-ROM) that provides the
same labels as those provided at a specified URL, or not collecting labels
at all when those labels could not possibly change the rule's result.


<a HREF="#OrderOfOperations"="">Later in this document,</a> we suggest
that implementors adopt a particular <a HREF="#OrderOfOperations"="">evaluation
order.</a> Implementors should be very careful about any deviations from
this suggested evalution order. Note that it is possible to write rules
that are non-monotonic in the receipt of labels: as more labels are received,
the result could flip from accept to reject and back again. In some situations, ;
however, it may be possible to infer that additional labels can not alter
the result of a rule: for example, the first policy clause may specify
that a particular URL is to be accepted, based solely on its URL, regardless
of any labels that are available. As an optimization, a user agent may
use the policy clause(s) to determine an answer even before labels are
available from all of the sources specifies in the serviceinfo clause(s),
but implementors should be careful to do this only in those situations
where the additional labels, even if they were available, could not change
the results of the evaluation.

Attribute in clause | Satisfied by ; | Action |
RejectByURL | URL matches any of the patterns specified | Block document |
AcceptByURL | URL matches any of the patterns specified | Pass document |
RejectIf | <i="">expression</i> = <b=""><i="">true</i></b> ; | Block document |
AcceptIf | <i="">expression</i> = <b=""><i="">true</i></b> ; | Pass document |
RejectUnless | <i="">expression</i> = <b=""><i="">false</i></b> ; | Block document |
AcceptUnless | <i="">expression</i> = <b=""><i="">false</i></b> ; | Pass document |
<b="">URLpattern :: </b><i="">internet-pattern</i> | <i="">other-pattern</i>
<b="">internet-pattern :: </b><i="">internet-scheme</i> '://' ;

 ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; [<i="">user</i> '@'] <i="">hostoraddr</i> [':' <i="">port</i>] ['/' <i="">pathmatch</i>]
<b="">internet-scheme :: </b>'*' | 'ftp' | 'http' | 'gopher' | 'nntp' |

 ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; 'irc' | 'prospero' | 'telnet'
<b="">user ::</b> ['*' | '%*'] <i="">notquotechar</i>* ['*' | '%*']



<b="">hostoraddr ::</b> ['*' | '%*'] <i="">host </i>| <i="">ipwild </i>['!' <i="">bitlength</i>]



<b="">ipwild ::</b> <i="">ipcomponent </i>'.' <i="">ipcomponent </i>'.' <i="">ipcomponent </i>'.' <i="">ipcomponent</i>
<b="">ipcomponent :: </b>integer between '0' and '255' inclusive
<b="">bitlength ::</b> integer between '0' and '32' inclusive



<b="">host ::</b> substring of a fully qualified domain name as described ;

 ; ; ; ; ; ; ; in Section 3.5 of [RFC1034]
<b="">port ::</b> '*' | <i="">integerorwild </i>[ '-' <i="">integerorwild </i>]
<b="">pathmatch :: </b>['*' | '%*'] <i="">notquotechar</i>* ['*' | '%*']
<b="">integerorwild :: </b><i="">digit+</i> | '*'
<b="">digit :: </b>'0' - '9'



<b="">other-pattern :: </b><i="">scheme : </i>['*' | '%*'] <i="">notquotechar</i>* ['*' | '%*']
<b="">scheme :: </b>'*' | <i="">schemechar</i>+
<b="">schemechar :: </b>'a' - 'z' | 'A' - 'Z' | <i="">digit</i> | '+' | '.' | '-' ;

 ; ; ; ; ; ; ; ; ; ; ; ; ; (as specified in [RFC1738])
A RejectbyURL policy clause causes the overall rule to "reject" if the
URL match evaluates to TRUE. Similarly, an AcceptbyURL policy clause causes
the overall rule to "accept" if the URL match evaluates to TRUE. In either
case, the explanation associated with policy clause is returned. If a list
of URL patterns is provided, the URL match evaluates to TRUE if any one
of the patterns matches. If the URL match evaluates to FALSE, the policy
clause is ignored and evaluation continues with the next policy clause.


When comparing a URLpattern to a URL, the rule interpreter MUST NOT
unencode the URL (e.g., do not convert %2F ; to ; /). If the pattern
can be interpreted as an internet-pattern, then the pattern is divided
into its component parts and the URL matches the pattern if a match occurs
on every component that is included in the pattern.

<b="">WARNING: </b>if a component is not specified in the pattern, the
pattern matches only URLs that omit the pattern. It is necessary to specify
'*' for pattern components if the intention is to ignore that component
of URLs. For example, to block access to all URLs contain the string "buy"
in the pathname, the correct pattern is "*://*@*:*/*buy*". While it might
seems natural to write the pattern "*://*/*buy*" or even "*buy*", the first
would match only URLs that omit the username and port number, and the second
is simply not a valid pattern.


If the pattern can not be interpreted as an Internet scheme, it is divided
into a scheme name and a scheme-specific part. '*' for the scheme name
matches any URL's scheme; otherwise exact string matching is required;
this comparison is case-insensitive. '*' at the beginning or end of the
scheme-specific part of the pattern matches any number of characters in
the URL string. '%*' at the beginning or end of the pattern matches the
single character '*' in the URL string. Characters in the middle of the
scheme-specific part of the pattern must match exactly the characters in
the URL string; this comparison is case-sensitive.
<br=""> ;
<br=""><b="">NOTE:</b> It is not possible to write a URLpattern that matches
exactly the URL string characters '%*'. This is not a limitation of the
pattern matching language, however, because, in a valid URL, the '%' character
must be followed by two hex digits. Thus, there are no URL strings containing
the character sequence '%*'.

Unfortunately, the alternative matching rule, of always unencoding URLs
before comparing to the pattern, can cause ambiguities. For example, in
HTTP, ? is reserved as the query string delimiter; any naturally occurring
? is encoded as %3F. After unencoding it would no longer be possible to
distinguish a query string delimiter from a naturally occurring ?. We felt
it was better to make the pattern matching precise, at the expense of missing
some synonyms.


Another, similar limitation is that IP addresses in URLs are not converted
into host names for comparison to rule patterns. This means that host name-based
patterns will miss matching against certain synonymous IP-address based
URLs. The pattern "http://*.mit.edu" will match against fewer URLs than
the pattern "http://18.0.0.0!8". The latter pattern will match against
web site ending in mit.edu, because they all will resolve to ip addresses
beginning with 18. The reason that URLs containing IP addresses will not
match against patterns that specify domain names is that performing a reverse
lookup of the IP address in the URL is too expensive an operation to perform
routinely. Hence, whenever it is practical to do so, rules may want to
specify IP address matching rather than host name maching; beware, however,
that this may require updating of the rule whenever a host name switches
to a different IP address.

<b="">policy-expression</b> :: <i="">simple-expression</i> | ;

<i=""> ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; or-expression</i> | ;

<i=""> ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; and-expression</i> | ;

<i=""> ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; degenerate-expression



</i><b="">simple-expression</b> :: '(' <i="">service</i> ['.' <i="">category</i> [<i="">op</i> <i="">constant</i> ] ] ')'



<b="">service</b> :: <i="">any <b="">shortname</b> defined in a serviceinfo clause within this rule</i>
<b="">category</b> :: <i="">transmit-name-char</i>+ ['/' <i="">category</i>]

 ; ; ; Note: as in the [<a HREF="#References"="">PicsLabels</a>] spec, if the rating service defines ;

 ; ; ; hierarchically nested categories, the outermost category name goes ;

 ; ; ; at the left, followed by a slash, then the next category name, etc.
<b="">transmit-name-char ::</b> <i="">alphanumpm </i>| '.' | '$' | ',' | ';' | ':' ;

 ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; | '&;' | '=' | '?' | '!' | '*' | '~' | '@'

 ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; | '#' | '_' | '%' <i="">hex hex



</i><b="">alphanumpm :: </b>'A' | ... | 'Z' | 'a' | ... | 'z' | '0' | ... | '9' | '+' | '-'
<b="">hex ::</b> '0' | ... | '9' | 'A' | ... | 'F' | 'a' | .... | 'f'
<b="">op</b> :: '>' | '<;' | '=' | '>=' | '<;='



<b="">constant</b> :: [<i="">sign</i>] <i="">alphanum</i>* ['.' <i="">alphanum</i>*]



<b="">or-expression</b> :: '(' <i="">policy-expression</i> [<i="">or policy-expression]+</i> ')'



<b="">or</b> :: 'or' ;



<b="">and-expression</b> :: '(' <i="">policy-expression</i> [<i="">and policy-expression]+</i> ')'



<b="">and</b> :: 'and' ;



<b="">sign</b> :: '-'



<b="">degenerate-expression</b> :: 'otherwise'
When evaluating a clause, the user-agent may use zero, one, or more labels
from a given rating service (for more details, see the control
flow section). A simple-expression evaluates to true if any
available label from the specified service satisfies the condition of the
expression. Intuitively, a rule evaluator will try to prove that an expression
is satisfied, using any available labels as evidence.


We must deal with the situation where a simple-expression calls for
a value from a label, and either no label is available, or the available
labels do not have values for the specified category. In those situations,
the simple-expression evaluates to <b=""><i="">false</i></b>. This leads to an
intuitive semantics: if a simple-expression has no associated label available,
that expression cannot contribute evidence toward proving the claim made
by the expression.


Simple-expressions, as defined above, can use any types of operators
on any types of data. More specifically, the semantics of expression evaluation
are as follows:

The careful reader will also note the lack of the Boolean not
operator, as well as the lack of universally quantified operators such
as max, min, and forall. These omissions are
deliberate, and for similar reasons to the omission of !=. Given
that the available labels may provide either no values or multiple values
for particular categories, rules become very difficult for people to understand
when such operators are allowed in an unrestricted way. We have restricted
the use of negation and universal quantification to appear only at the
top-level, using the attributes AcceptIf, AcceptUnless, RejectIf, and
RejectUnless, as described below. Our restricted language still has
full expressiveness, however, by taking advantage of the fact that "forall
x, g(x) holds" is mathematically equivalent to "there does not exist x
such that g(x) does not hold". For example, suppose one wants to accept
any URL so long as all the labels agree on an s-value equal to three.
The policy clause would be:

Policy (AcceptUnless "(Service.s <; 3) or (Service.s > 3)" ).
 ;

Here's a simple example of a PICSRules rule that uses an optional extension:

 ;1 (PicsRule-1.1

 ;2 ; ; ; ; (

 ;3 ; ; ; ; ; ; ; ; ServiceInfo (

 ;4 ; ; ; ; ; ; ; ; ; ; ; ; "http://www.coolness.org/ratings/V1.html"

 ;5 ; ; ; ; ; ; ; ; ; ; ; ; shortname "Cool" ;

 ;6 ; ; ; ; ; ; ; ; ; ; ; ; bureauURL "http://labelbureau.coolness.org/Ratings"

 ;7 ; ; ; ; ; ; ; ; ; ; ; ; )

 ;8 ; ; ; ; ; ; ; ; Policy (AcceptIf "((Cool.Coolness <; 3) or (Cool.Graphics <; 3))" )

 ;9 ; ; ; ; ; ; ; ; Policy (RejectIf "otherwise")

10 ; ; ; ; ; ; ; ; optextension (

 ; ; ; ; ; ; ; ; ; ; ; ; ; ; "http://www.si.umich.edu/~presnick/pics/extensions/PRsample.htm" ;

11 ; ; ; ; ; ; ; ; ; ; ; ; shortname "extension1")

12 ; ; ; ; ; ; ; ; extension1.SampleAttribute (

13 ; ; ; ; ; ; ; ; ; ; ; ; UseExpired "YES" ;

14 ; ; ; ; ; ; ; ; ; ; ; ; GroupFile "/etc/ics.grp"

15 ; ; ; ; ; ; ; ; ; ; ; ; )

16 ; ; ; ; )

17 )
This example makes use of an optional extension named "http://www.si.umich.edu/~presnick/pics/extensions/PRsample.htm".
That extension defines the keyword SampleAttribute . User-agents
which don't understand this extension can simply ignore the extension1.SampleAttribute
clause and its attribute-value pairs (lines 12-14).


Note that there is only one "level" to <i="">declaring</i> extensions,
but attribute-value pairs defined by extensions may appear anywhere within
a PICSRules rule. That is, all extensions should declare themselves with
an <b="">optextension</b> or <b="">reqextension</b> clause within a <b="">rule-clause</b>,
but the attributes defined by an extension may appear nested several layers
down within a rule.

Scott Berkun, Microsoft

Jonathan Brezin, IBM

Yang-hua Chu, MIT

Lorrie Cranor, AT&;T

Jon Doyle, MIT

Ghirardelli Chocolate Co.

Brian LaMacchia, AT&;T

Breen Liblong, NetShepherd

Jim Miller, W3C

Mary Ellen Rosen, IBM

Rick Schenk, IBM

Bob Schloss, IBM

David Shapiro, MIT

Ray Soular, SafeSurf