Note:This paragraph is informative. This document is currently not maintained. PICS has been superseded by the Protocol for Web Description Resources (POWDER). W3C encourages authors and implementors to refer to POWDER (or its successor) rather than PICS when developing systems to describe Web content or agents to act on those descriptions. A brief document outlining the advantages offered by POWDER compared with PICS is available separately. The 31 October 1996 PICS Recommendation remains available on the W3C Web site.
This document has been reviewed by W3C members and other interested parties and has been endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited as a normative reference from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.
A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/pub/WWW/TR/.
This document has been prepared for the technical subcommittee of PICS (Platform for Internet Content Selection). It defines a general format for labels and three methods by which these labels may be transmitted:
Table of Contents
Semantics of PICS Labels and Label Lists
Embedding Labels in HyperText Markup Language (HTML)
Using HTTP to Request Labels With A Document
Appendix A: An Algorithm for Locating a Label Bureau
Appendix B: Sample Label Bureau Queries and Responses
This document has been prepared for the technical subcommittee of PICS (Platform for Internet Content Selection). It defines a general format for labels and three methods by which these labels may be transmitted:
A label consists of a service identifier, label options, and a rating. The service identifier is the URL chosen by the rating service (see Rating Services and Rating Systems) as its unique identifier. Label options give additional properties of the document being rated as well as properties of the rating itself, such as the time the document was rated. The rating itself is a set of attribute-value pairs that describe a document along one or more dimensions. One or more labels may be distributed together as a list. The general form for a label list (formatted for presentation, and not showing error status codes) is:
(PICS-1.1
<service url> [option...]
labels [option...] ratings (<category> <value> ...)
[option...] ratings (<category> <value> ...)
...
<service url> [option...]
labels [option...] ratings (<category> <value> ...)
[option...] ratings (<category> <value> ...)
...
...)
A specific label applies to a single document. If the document is in HTML format, it may refer to other documents, either by external reference (for example, using the <A href=...> tag) or by requesting that they be displayed in-line (for example, using the <img ...> or <object ...> tag). A label applies to the given document only, not to the referenced documents.
A generic label (identified by the use of the generic option) applies to any document whose URL begins with a specific string of characters (specified using the for option). A generic label does not have the expected semantics of a "default" label that can be overridden by more specific labels. While a specific label does override a generic label when a client has access to both, the two labels may be distributed separately, and thus a client may have access to only the generic label. A server can keep track of defaults and overrides and generate a specific label based on a default that is not overridden in its local database. However, a generic label for a site or directory should only be distributed if it applies to all the documents in that site or directory.
A rating service may provide a generic label for any or all prefixes of a given URL, but should provide only one specific label for that URL. When the specific label for a document can be found, it should be used in preference to any generic label. Lacking a specific label, any generic label may be substituted, but preference should be given to the generic label which has the longest string. Some PICS client software may impose restrictions on the use of generic labels. For example, a client may choose to ignore a generic label that applies to a node in the URL tree more than two levels above the node where the document is located.
Label options can be divided into three groups. Options from the first group supply information about the document to which the label applies. Options from the second group supply information about the label itself. The last group provides miscellaneous information.
For example, a label list for two documents, using the example rating system from PICS Rating Services and Rating Systems, might be as follows (in all examples, the spacing and indentation is provided for readability; the specification treats multiple white space characters as if they were compressed into a single space):
(PICS-1.1 "http://www.gcf.org/v2.5"
by "John Doe"
labels on "1994.11.05T08:15-0500"
until "1995.12.31T23:59-0000"
for "http://w3.org/PICS/Overview.html"
ratings (suds 0.5 density 0 color/hue 1)
for "http://w3.org/PICS/Underview.html"
by "Jane Doe"
ratings (subject 2 density 1 color/hue 1))
The same label list may be transmitted more compactly by converting all of the line breaks and subsequent indentation characters into a single space, and by replacing the word "labels" with "l", "ratings" with "r" and long option names with their abbreviations. It may be compressed for transmission purposes even further by removing all of the optional information to a separate document and referencing that document by a URL:
(PICS-1.1 "http://www.gcf.org/v2.5" l
full "http://www.gcf.org/labels/13242123"
r (suds 0.5 density 0 color/hue 1)
full "http://www.gcf.org/labels/123412278"
r (subject 2 density 1 color/hue 1))
Finally, the optional information may be omitted entirely, reducing the information content of the labels but making the transmission even smaller. The resulting label list would then be:
(PICS-1.1 "http://www.gcf.org/v2.5"
l r (suds 0.5 density 0 color/hue 1)
r (subject 2 density 1 color/hue 1))
The following grammar, in modified BNF, describes the syntax of labels. The methods by which labels are embedded in specific protocols are detailed below.
Notes:
labellist :: '(' version service-info+ ')'
version :: 'PICS-1.1'
service-info :: 'error' '(no-ratings' explanation* ')'
| serviceID service-error | serviceID option* labelword label*
serviceID :: quotedURL
labelword :: 'labels' | 'l'
label :: label-error | single-label | '(' single-label* ')'
single-label :: option* ratingword '(' rating+ ')'
ratingword :: 'ratings' | 'r'
quotedURL :: '"' URL '"' as described and extended in
Rating Services and Rating Systems.
option :: labeloption | documentoption | otheroption
labeloption ::
'by' quotedname
| 'generic' boolean | 'gen' boolean
| 'for' quotedURL
| 'on' quoted-ISO-date
| 'signature-RSA-MD5' "base64-string"
| 'until' quoted-ISO-date | 'exp' quoted-ISO-date
documentoption ::
'at' quoted-ISO-date
| 'MIC-md5' "base64-string" | 'md5' "base64-string"
otheroption ::
'comment' quotedname
| 'complete-label' quotedURL | 'full' quotedURL
| 'extension' '(' mand/opt quotedURL data* ')'
mand/opt :: 'optional' | 'mandatory'
data :: quoted-ISO-date | quotedURL
| number | quotedname | '(' data* ')'
quoted-ISO-date :: '"'YYYY'.'MM'.'DD'T'hh':'mmStz'"'
based on the ISO 8601:1988 date and time standard, restricted
to the specific form described here:
YYYY :: four-digit year
MM :: two-digit month (01=January, etc.)
DD :: two-digit day of month (01 through 31)
hh :: two digits of hour (00 through 23) (am/pm NOT allowed)
mm :: two digits of minute (00 through 60)
S :: sign of time zone offset from UTC ('+' or '-')
tz :: 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 quoted-ISO-date
denoting November 5, 1994, 8:15 am, US Eastern Standard Time
Note: The ISO standard allows considerably greater
flexibility than that described here. PICS requires precisely
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.
rating :: transmit-name number | transmit-name '(' multi-value* ')'
multi-value :: number | number ':' number
transmit-name :: transmit-name-char+ ['/' transmit-name]
number :: [sign]unsignedint['.' [unsignedint]]
sign :: '+' | '-'
unsignedint :: [0-9]+
quotedname :: '"' urlchar-or-space+ '"'
alphanumpm :: 'A' | ... | 'Z' | 'a' | ... | 'z' | '0' | ... | '9' | sign
transmit-name-char :: alphanumpm | '.' | '$' | ',' | ';' | ':'
| '&' | '=' | '?' | '!' | '*' | '~' | '@'
| '#' | '_' | '%' hex hex
Note: Use the "%" escape technique (% followed by the two
hex digits that represent the character in the ASCII character
set) to insert single or double quotation marks or parentheses.
urlchar :: transmit-name-char | '(' | ')'
hex :: '0' | ... | '9' | 'A' | ... | 'F' | 'a' | ... | 'f'
urlchar-or-space :: urlchar | ' '
base64-string :: as defined in RFC-1521.
service-error :: 'error' '(' 'request-denied' explanation* ')'
| 'error' 'service-unavailable'
label-error :: 'error' '(' 'request-denied' [quotedURL explanation*] ')'
| 'error' '(' 'not-labeled' quotedURL* ')'
explanation :: quotedname
A labellist is used to transmit a set of PICS labels. The format specified here is intended to be registered with IANA as the MIME type "application/pics-labels." It allows for transmission of both labels and reasons why labels are not available, and is the format used when labels must be conveyed in a document, along with a document, or from a PICS label bureau. The labellist will always be surrounded by parentheses and begin with the PICS version number (1.1 in this specification).
A label list either specifies that there are no labels available at all (e.g., "error (no-ratings ...)") or is separated into sections of labels, one section for each rating service. The URL of each service must be specified (the serviceID). This is either followed by an error message indicating why no labels are available from that service (service-error) or an overall set of optional information (option*) followed by the keyword "labels" (or "l") and the labels from the service. The optional information provided here applies to every label from the service, unless overridden in the specific label itself.
A label encompasses three separate cases. The first is an error that applies to retrieving the label for a particular URL (label-error). The second, and most common, is a single-label consisting of options (which override those specified with the service), the marker word "ratings" (or "r") and the ratings themselves (a list of category names and values). Finally, in the special case where the ratings for an entire tree of documents have been requested, any number of single-labels can be transmitted, enclosed in parentheses. This case is described in more detail in the section on "Requesting Labels Separately."
A label may apply to a specific URL, or it may be generic. A generic label
implicitly rates every URL for which the specified one is a prefix. For example,
a generic label for the URL "http://w3.org" implicitly rates every document
available at that site. A specific (non-generic) label for the same URL,
"http://w3.org", does not give any implicit ratings: it merely rates the
organization's home page that is fetched by the command "GET /"
sent by HTTP to the host w3.org. A generic label must
include the "for" option specifying the URL to which it applies.
As mentioned above, a generic label should be supplied only if it can be
legitimately applied to all documents with URLs that begin with
the string specified in the label's for option.
When a multi-value is provided, any combination of numbers and ranges of numbers may be specified, with the endpoints of a range separated by a ":". Thus, in the labellist
(PICS-1.1 "http://www.gcf.org/v2.5" l r (suds 0.5 density 0 color/hue 1 subject (0.5:1.5 2)))
all subject values between 0.5 and 1.5 (including both endpoints) apply to the item, as does the subject value 2. Given the example service description in Rating Services and Rating Systems, two document subjects apply, "water" (subject value 1) and "soapdish" (subject value 2.) The third, "soap," has subject value 0, so it does not apply.
Many protocols, such as Internet electronic mail, the HyperText Transfer Protocol, and USENET News, use US-ASCII headers as described in RFC-822. For use in such protocols, we define a new header, PICS-Label, used to contain the labels described in this document. The syntax is:
PICS-Label: <labellist>
where labellist is described according to the syntax above. Continuation lines beginning with whitespace may be used following the specification given in RFC-822.
Labels may be embedded in HTML files as meta-information, using the META element defined in the HTML specification. This embedding uses the HTTP header equivalence mechanism:
<META http-equiv="PICS-Label" content='labellist'>
Note that the content attribute uses single quotes, because the PICS label syntax uses double quotes. Any of the following characters appearing within the content must be escaped using SGML entities:
' ' /* single quote */
& & /* ampersand */
> > /* greater than */
See the HTML 2.0 Proposed Standard.
A label that is embedded in a document may omit the "for" option, which would normally specify a URL to which the label applies. A specific (non-generic) label embedded in a document applies to that document, regardless of what URL is used to locate the document. A generic label, when embedded in a document that can be retrieved via a "home" URL (i.e., a URL path ending in /), applies to all URLs that include the home URL as a prefix.
For example, if a client is interested in a label for the document "http://www.greatdocs.com/foo/bar/bat.htm", it can first check whether the document has a specific label embedded in it. If not, the client can ask for the document "http://www.greatdocs.com/foo/bar/". The server sends back the home document for foo/bar, which may be foo/bar/index.html, foo/bar/home.html, or something else, depending on the server. If that document contains an embedded generic label, then the client may interpret it as applying to the document bat.htm. If the client does not find a generic label there, it may check further up the hierarchy, in "http://www.greatdoc.com/foo/" or even at "http://www.greatdocs.com/".
Web site operators who wish to provide specific labels for their html documents are encouraged to embed them in the documents. Those who wish to provide generic labels for their sites or subparts of their sites are encouraged to include them in the home documents at as many levels of the document naming hierarchy as they think are appropriate. They are also encouraged to use the more elegant and functional method, described in the next section, of sending labels in the http header stream, whenever tools are available for doing so.
We specify a simple extension to HTTP that allows a client to request that one or more labels be included in a header along with the document. We deal here only with the HTTP protocol; we hope that other protocols will be similarly extended. HTTP servers should include PICS label headers only if requested to do so by the client, and should only include the labels from services requested by the client. As with labels embedded in documents, the client may assume that a label returned in the http header stream applies to the document requested, regardless of the URL specified in the "for" option of the label.
Client sends to HTTP server www.greatdocs.com, a PICS-enabled server:
GET /foo.html HTTP/1.0
Protocol-Request: {PICS-1.1 {params full
{services "http://www.gcf.org/v2.5"}}}
Server responds to client:
HTTP/1.0 200 OK
Date: Thu, 30 Jun 1995 17:51:47 GMT
Last-modified: Thursday, 29-Jun-95 17:51:47 GMT
Protocol: {PICS-1.1 {headers PICS-Label}}
PICS-Label:
(PICS-1.1 "http://www.gcf.org/v2.5" labels
on "1994.11.05T08:15-0500"
exp "1995.12.31T23:59-0000"
for "http://www.greatdocs.com/foo.html"
by "George Sanderson, Jr."
ratings (suds 0.5 density 0 color/hue 1))
Content-type: text/html
...contents of foo.html...
The client requests the document foo.html. In addition, the client requests the full label of the document from the rating service "http://www.gcf.org/v2.5". The server responds by sending back the label, in the PICS-Label header, as well as the document. The format of the PICS-Label header field (a labellist) allows the server to respond either with a label or an explanation of why the label is not available, since it would be inappropriate for the server to generate an HTTP error status if the document is available but (some of) the labels are not.
Following the usual HTTP distinction between HEAD and GET, a client that wishes to examine a rating before retrieving the full document can substitute the word HEAD for GET in the request. The server responds with exactly the headers shown above, but does not send back the document foo.html.
The following grammar, in modified BNF, describes the syntax of the additional header line to be included in an HTTP request for a document and associated labels.
request-header ::
'Protocol-Request: {PICS-1.1 {params ' [completeness]
extension*
services '}}'
completeness :: 'minimal' | 'short' | 'full' | 'signed'
extension :: '{' token-or-quoted-string+ '}'
where the first token-or-quoted-string is not 'services'.
token-or-quoted-string :: token | quotedname
token :: alphanumpm+
services :: '{' 'services' quotedURL+ '}'
A request for a minimal label asks that all options be omitted, unless a generic label is returned, in which case the generic and for options must also be included in the label. A short label includes everything that is included in a minimal label, plus additional options that the server deems appropriate. A request for a full label asks that as much information as possible should be sent back in the label, either directly or through the use of a complete-label (or full) option, but no signature-RSA-MD5 option is needed.
A request for signed labels asks that all the information in a full label should be sent, along with a digital signature on the label itself. In a signed label the information must be transmitted directly as part of the label (and included in the computation of the signature); the complete-label (or full) option may be sent, but it would be redundant. Details of signing labels are included in the section MICs and Digital Signature.
It is acceptable for a server to ignore the completeness, either by delivering more or fewer options than requested. If the completeness is omitted, it should be treated as though minimal had been supplied. For future extensibility, any alphanumeric string may be used for a value of the completeness option. Servers which receive a value of completeness that they do not recognize must treat it as though minimal had been specified.
The extensions are for future extensions to the protocol; any extensions which are not understood by the server must be ignored by it. It is recommended that experimental extensions use a URL, which dereferences to a description of the extension, as the initial token-or-quoted-string.
Each quotedURL in a service specifies a rating service from which the client is requesting a label for the document. There may be as many repetitions of the quotedURL part of the service as desired, so it is possible to request labels from any number of rating services in a single HTTP request.
Two additional headers are specified:
protocol-header :: 'Protocol: {PICS-1.1 {headers PICS-Label}}'
label-header :: 'PICS-Label: ' labellist
PICS labels can also be retrieved separately from the documents to which they refer. To request labels in this way, a client contacts a label bureau. A label bureau is an HTTP server that understands a particular query syntax, defined below. It can provide labels for documents that reside on other servers, and, indeed, for documents available through protocols other than HTTP. It is anticipated that there will be "well-known" label bureaus which dispense (possibly for a fee) labels created by many rating services.
Rating services are also encouraged to act as label bureaus, providing on-line access to their own labels. By default, the URL that identifies a rating service also identifies its label bureau. If a client requests the URL that identifies a rating service, a human-readable description of the service is returned, as specified in Rating Services and Rating Systems. If, on the other hand, a client requests the same URL and includes query parameters as defined below, it should be interpreted as a request for labels. A rating service, however, is not required to act as a label bureau, and it may choose a different URL (perhaps even on a different HTTP server) to act as its label bureau.
(For more complex queries and responses, see Appendix B.)
Imagine a rating service, identified by the URL http://www.labels.org/Ratings, which decides to run a label bureau to dispense (at least) its own labels for documents. The following sample request, made to the HTTP server www.labels.org, is illustrative (line breaks are inserted for presentation purposes only):
GET /Ratings?opt=generic&
u="http%3A%2F%2Fwww.questionable.org%2Fimages"&
s="http%3A%2F%2Fwww.gcf.org%2Fv2.5"
HTTP/1.0
The query asks the label bureau http://www.labels.org/Ratings to send a single label that applies to everything in the images hierarchy at site www.questionable.org. The desired label should have been created by the service http://www.gcf.org/v2.5. Notice the use of %3A to represent a ":" and %2F for "/." This is required for encoding characters within a URL. See RFC-1738.
The label bureau responds by sending back a document of type "application/pics-labels." The labels should be as complete as possible, either by including as many options as possible or by supplying the complete-label (or full) option.
The following grammar, in modified BNF, describes the syntax of GET and POST requests to a label bureau. The use of the POST request is specified only for backward compatibility with HTTP servers that cannot handle a long GET query. Its use, while described in the HTML 2.0 specification (for use in submitting forms, see section 8.2.1 and 8.2.3), is deprecated.
request :: get | post
get :: 'get' url-fragment '?' [opt] [format]
extension* url+ service+
post :: 'post' url-fragment crlf crlf formencodeddata
url-fragment :: the part of the original URL after the host
name, as specified in HTTP 1.0.
crlf :: carriage return (hex D) followed by line feed (hex A)
opt :: 'opt=' option
option :: 'generic' | 'normal' | 'tree' | 'generic+tree'
format :: [and] 'format=' form
form :: 'minimal' | 'short' | 'full' | 'signed'
extension :: token '=' token-or-quoted-string
where the token is not one of opt, format,
u, or s; and token-or-quoted-string follows
the quoting conventions specified in RFC-1738
token-or-quoted-string :: token | quotedname
token :: alphanumpm+
url :: [and] 'u=' encodedURL
service :: [and] 's=' encodedURL
boolean :: 't' | 'f' | 'true' | 'false'
and :: '&' this must be included unless it immediately
follows the ? in the query.
encodedURL :: a quoted URL. Following RFC-1738, quotation and some
special characters inside the URL are encoded using "%xx" notation.
Alphabetic characters, digits, and the special characters
$_-.+!*'(), need not be quoted, but other characters must be.
This does imply that the colon (:) must be encoded as %3A
and slash (/) as %2F.
formencodeddata :: The query as specified for get but encoded into
MIME type application/x-www-form-encoded as described in
sections 8.2.1 and 8.2.3 of HTML 2.0.
This specification includes two independent security features, each intended to prevent a different problem that can arise in a PICS system. They may be used independently or together. Both features rely on patented cryptographic technology whose use is subject to a variety of legal restrictions (including possible U.S. export controls). The PICS technical committee cannot provide any information about the exact legal status of the code or algorithms.
Within the United States, RSA Laboratories (100 Marine Parkway, Redwood City, CA, 94065-1031) distributes a source code kit called RSAREF which provides all of the code required to implement the cryptographic components of the PICS spec. The president of RSA Data Security, Inc., Mr. Jim Bidzos, has advised us that RSAREF will be made available at no cost for use in implementing the PICS specifications. Questions about the legal status, etc., should be directed to Mr. Bidzos.
The first problem arises when a document has been examined and a label generated, and then the document is modified without updating the label. While this can happen legitimately (as when Time-Warner updates the page containing the current issue of Time Magazine and believes that the label is still valid) it can also happen as a result of tampering with the document by an unauthorized party. PICS labels contain three option fields intended to help deter this kind of problem:
The second problem is that of tampering with or forging labels. Here the problem is that the end user needs some way of being reassured that the label they receive was created by the rating service they expected and that it has not been altered since it was created. PICS addresses this problem by allowing labels to be "digitally signed". A digital signature, while not currently legally recognized, is a cryptographic technique to provide exactly this assurance. The RSA signature technique works as follows:
The problem of distributing these keys (and invalidating them in case the service's key is compromised) is an active area of commercial competition. Since there is no clearly established solution available today, PICS assumes that each service will distribute the public keys in some way it chooses. It also assumes that no keys will ever have to be invalidated. While this is clearly not a perfect solution, it seems to be the limit of what can be done today without committing to specific proprietary technology.
There is one additional problem with the digital signature solution outlined above. If a rating service allows other people to generate labels under its name (for example, a service that supports self-ratings by content producers) then the labels may need to be signed by both the service and the content producer. This can be done (each signs the label without the other's signature), but it becomes quite difficult to distribute the public keys needed to verify the signature. The PICS specification does not propose a solution to this problem (it, too, is part of active commercial competition).
Comments and suggestions from the following people are gratefully acknowledged:
Bob Atkinson, Microsoft Anselm Baird-Smith, W3C Brenda Baker, Lucent Scott Berkun, Microsoft Tim Berners-Lee, W3C Roxana Bradescu, AT&T Daniel W. Connolly, W3C Roy Fielding, W3C Jay Friedland, SurfWatch Henrik Frystyk Nielsen, W3C Philip Gladstone, Raptor Systems Michael Gordon, Prodigy Wayne Gramlich, Sun Woodson Hobbs, NewView David Karger, MIT Rohit Khare, W3C Charlie Kim, Apple John C. Klensin, MCI Breen Liblong, IFSI Ann McCurdy, Microsoft Rich Petke, CompuServe Eric Prud'hommeaux, W3C Dave Raggett, W3C Gordon Ross, NetNanny Bob Schloss, IBM David Singer, IBM Ray Soular, SafeSurf Michael Smith, Prodigy Marcy Swenson, Providence Systems Jason Thomas, MIT
As the use of PICS grows, we must consider its impact on overall network performance. In general, the PICS techniques for transmitting labels in or with documents add only a very small amount of traffic to the net, since the additional PICS headers will ordinarily contain only a few hundred bytes of data and the documents themselves are more likely to be several thousand bytes of data. Furthermore, since the labels come from the same source as the document itself there is no network hot spot created by PICS (although popular servers may themselves already be such hot spots).
Label bureaus, however, are a new component proposed by PICS. And if a single label bureau becomes popular then there is a significant risk of it becoming a hot spot and hence a performance bottleneck for the PICS system. The Internet is in need of a good solution to this problem, and there is work (both underway and proposed) that may solve the problem in the long term.
In the short term, however, there is no truly good solution. The following suggestion comes from Prof. David Karger at MIT. It is a variant on several well-known algorithms for distributing load in a system.
First, we assume that popular label bureaus will be able to establish a number of mirror sites around the network. This is already common practice, and we have no suggestions for the details of determining the sites or keeping them updated as new labels are generated. Our algorithm simply assumes that they exist and are equivalent, and that the network's Domain Name System (DNS) has records which map the single well-defined name for the label bureau to multiple Internet addresses, in the usual manner.
When client software starts, it should attempt to resolve the name of the label bureau it wishes to use (we assume one label bureau, but the algorithm extends in an obvious manner to multiple bureaus) through DNS. If it receives more than one host address, it saves the entire list and chooses two at random, labeling one the "primary" and the other the "secondary" bureau. Alternatively, these may be configuration parameters of the client software that are then validated when the software starts. It also divides 60 minutes by the total number of address it can find for the label bureau, sets a timer to this value, and remembers this as the "threshold" value.
Every time the client wishes to contact the label bureau it does the following. If the timer is below the threshold, the primary bureau address is used. Otherwise, the query is sent to both the primary and the secondary label bureau address. When the first answer arrives the connection to both label bureaus is closed down. The bureau which answered first becomes the primary bureau. In any case, a new secondary bureau address is chosen at random and the timer is reset to the threshold value.
A simple variant on this algorithm will probably become feasible in the near future. When the HTTP protocol is updated to allow "keep alive" connections to a server, the PICS client should keep its connection to the primary label bureau alive as long as possible. Then, instead of simply accepting the first response and considering the responder as the primary, a more careful measurement must be made. The time required to send the query and receive the response must be measured, rather than the total transaction time: connection setup costs can be quite high, and would distort the measurement if one compared the round trip time to the primary bureau through an existing connection to the time to establish the connection to the secondary bureau plus the round trip time.
The following queries and responses illustrate many of the features of client interactions with label bureaus that dispense labels separately from documents. All four queries request labels for the same three documents, provided by the same three services. They differ only in the query mode (Generic, Normal, Tree, Generic+Tree).
Labels are requested for the following URLs:
Labels are requested from the following services:
The server has the following relevant labels:
The query responses have been pretty-printed for readability. Comment lines, beginning with ';' have been added to explain the responses. Query requests have been split onto multiple lines for display purposes; they are actually sent as single (very long) lines.
This request is for full generic labels that apply to the three documents.
Client sends request to server:
GET /ratings?opt=generic&format=full& u="http%3A%2F%2Fwww.w3.org%2Fpub%2FWWW%2F+&" u="http%3A%2F%2Fwww.w3.org%2Fpub%2FWWW%2FTheProject.html&" u="http%3A%2F%2Fwww.w3.org%2Funknown&" s="http%3A%2F%2Fwww.ages.org%2Four-service%2Fv1.0%2F&" s="http%3A%2F%2Fwww.rsac.org%2Fv1.0&" s="http%3A%2F%2Funknown.com" HTTP/1.0
Server responds to client:
HTTP/1.0 200 OK
Content-Length: 550
Content-Type: application/pics-labels
Server: Jigsaw 0/0
Date: 15 Apr 1996 18:20:47 GMT
(PICS-1.1
"http://www.ages.org/our-service/v1.0/" ;first service
labels
for "http://www.w3.org/pub/WWW/"
generic true
by "[email protected]"
ratings (age 11) ;end of first label, since 'ratings' is always
;last part of a label. The same generic label
;applies also to any URL beginning
;http://www.w3.org/pub/WWW/TheProject.html
for "http://www.w3.org/pub/WWW/"
generic true
by "[email protected]"
ratings (age 11) ;end of second label
error (not-labeled "http://www.w3.org/unknown")
;no label available for third document
;three labels requested, so end of first service
"http://www.rsac.org/v1.0"
labels
for "http://www.w3.org/pub/WWW"
generic true
by "[email protected]"
ratings (v 0 s 0 n 0 l 0)
for "http://www.w3.org/pub/WWW"
generic true
by "[email protected]"
ratings (v 0 s 0 n 0 l 0)
error (not-labeled "http://www.w3.org/unknown")
;;no labels for third service
error (no-ratings "unknown service"))
This query requests full specific labels for each of the documents.
Client sends request to server:
GET /ratings?opt=normal&format=full& u="http%3A%2F%2Fwww.w3.org%2Fpub%2FWWW%2F+&" u="http%3A%2F%2Fwww.w3.org%2Fpub%2FWWW%2FTheProject.html&" u="http%3A%2F%2Fwww.w3.org%2Funknown&" s="http%3A%2F%2Fwww.ages.org%2Four-service%2Fv1.0%2F&" s="http%3A%2F%2Fwww.rsac.org%2Fv1.0&" s="http%3A%2F%2Funknown.com" HTTP/1.0
Server responds to client:
HTTP/1.0 200 OK Content-Length: 569 Content-Type: application/pics-labels Server: Jigsaw 0/0 Date: 15 Apr 1996 18:20:54 GMT (PICS-1.1 "http://www.ages.org/our-service/v1.0/" labels ;;no specific label available, so generic label returned for "http://www.w3.org/pub/WWW/" generic true by "[email protected]" ratings (age 11) ;;no specific label available, so generic label returned for "http://www.w3.org/pub/WWW/" generic true by "[email protected]" ratings (age 11) error (not-labeled "http://www.w3.org/unknown") "http://www.rsac.org/v1.0" labels ;;no specific label available, so generic label returned for "http://www.w3.org/pub/WWW" generic true by "[email protected]" ratings (v 0 s 0 n 0 l 0) ;;here a specific label is returned. for "http://www.w3.org/pub/WWW/TheProject.html" generic false by "[email protected]" ratings (v 0 s 0 n 0 l 0) error (not-labeled "http://www.w3.org/unknown") error (no-ratings "unknown service"))
This request is for full specific labels for all URLs that have the requested URLs as a prefix. This label bureau responds to tree queries by sending only labels for documents in the current directory.
Client sends request to server:
GET /ratings?opt=tree&format=full& u="http%3A%2F%2Fwww.w3.org%2Fpub%2FWWW%2F+&" u="http%3A%2F%2Fwww.w3.org%2Fpub%2FWWW%2FTheProject.html&" u="http%3A%2F%2Fwww.w3.org%2Funknown&" s="http%3A%2F%2Fwww.ages.org%2Four-service%2Fv1.0%2F&" s="http%3A%2F%2Fwww.rsac.org%2Fv1.0&" s="http%3A%2F%2Funknown.com" HTTP/1.0
Server responds to client:
HTTP/1.0 200 OK Content-Length: 1075 Content-Type: application/pics-labels Server: Jigsaw 0/0 Date: 15 Apr 1996 18:21:00 GMT (PICS-1.1 "http://www.ages.org/our-service/v1.0/" labels ;;several labels delimited by () (for "http://www.w3.org/pub/WWW/" generic true by "[email protected]" ratings (age 11) for "http://www.w3.org/pub/WWW/Overview.html" by "[email protected]" generic false ratings (age 12) by "[email protected]" for "http://www.w3.org/pub/WWW/PICS" generic true ratings (age 5) by "[email protected]" for "http://www.w3.org/pub/WWW/Daemon" generic true ratings (age 5)) ;;end of labels for directory http://www.w3.org/pub/WWW/ ;;no labels available for URLs containing ;;http://www.w3.org/pub/WWW/TheProject.html as a prefix error (not-labeled "http://www.w3.org/pub/WWW/TheProject.html") error (not-labeled "http://www.w3.org/unknown") "http://www.rsac.org/v1.0" labels (for "http://www.w3.org/pub/WWW" generic true by "[email protected]" ratings (v 0 s 0 n 0 l 0) for "http://www.w3.org/pub/WWW/TheProject.html" generic false by "[email protected]" ratings (v 0 s 0 n 0 l 0) for "http://www.w3.org/pub/WWW/Daemon" generic true by "[email protected]" ratings (v 0 s 0 n 0 l 0) for "http://www.w3.org/pub/WWW/PICS" generic true by "[email protected]" ratings (v 0 s 0 n 0 l 0)) error (not-labeled "http://www.w3.org/pub/WWW/TheProject.html") error (not-labeled "http://www.w3.org/unknown") error (no-ratings "unknown service"))
This query requests all generic labels for URLs that contain the requested URLs as prefixes. A subset of the labels returned for the previous query are returned here: only those that are generic.
Client sends request to server:
GET /ratings?opt=generic%2Btree& format=full& u="http%3A%2F%2Fwww.w3.org%2Fpub%2FWWW%2F+&" u="http%3A%2F%2Fwww.w3.org%2Fpub%2FWWW%2FTheProject.html&" u="http%3A%2F%2Fwww.w3.org%2Funknown&" s="http%3A%2F%2Fwww.ages.org%2Four-service%2Fv1.0%2F&" s="http%3A%2F%2Fwww.rsac.org%2Fv1.0&" s="http%3A%2F%2Funknown.com" HTTP/1.0
Server responds to client:
HTTP/1.0 200 OK Content-Length: 872 Content-Type: application/pics-labels Server: Jigsaw 0/0 Date: 15 Apr 1996 18:38:28 GMT (PICS-1.1 "http://www.ages.org/our-service/v1.0/" labels (for "http://www.w3.org/pub/WWW/" generic true by "[email protected]" ratings (age 11) by "[email protected]" for "http://www.w3.org/pub/WWW/PICS" generic true ratings (age 5) by "[email protected]" for "http://www.w3.org/pub/WWW/Daemon" generic true ratings (age 5)) error (not-labeled "http://www.w3.org/pub/WWW/TheProject.html") error (not-labeled "http://www.w3.org/unknown") "http://www.rsac.org/v1.0" labels (for "http://www.w3.org/pub/WWW" generic true by "[email protected]" ratings (v 0 s 0 n 0 l 0) for "http://www.w3.org/pub/WWW/Daemon" generic true by "[email protected]" ratings (v 0 s 0 n 0 l 0) for "http://www.w3.org/pub/WWW/PICS" generic true by "[email protected]" ratings (v 0 s 0 n 0 l 0)) error (not-labeled "http://www.w3.org/pub/WWW/TheProject.html") error (not-labeled "http://www.w3.org/unknown") error (no-ratings "unknown service"))Copyright © 1996 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
Webmaster
$Date: 2017/10/02 11:00:50 $