~ubuntu-branches/ubuntu/feisty/w3-recs/feisty : revision 1

1

<HTML>

2

<HEAD>

3

<TITLE>REC-PICS-labels-961031</TITLE>

4

</HEAD>

5

6

7

8

<A HREF="http://www.w3.org/pub/WWW/PICS/"><IMG BORDER="0" SRC="pics_48x48.gif"

9

ALT="PICS" WIDTH="48" HEIGHT="48"></A>

10

11

REC-PICS-labels-961031

12

</H3>

13

14

PICS Label Distribution Label Syntax and Communication Protocols

15

</H1>

16

<H3>

17

18

</CENTER>

19

</H3>

20

21

Version 1.1

22

</H3>

23

24

W3C Recommendation 31-October-96

25

</H3>

26

27

<DL>

28

<DT>

29

<DT>

30

Editor:

31

<DD>

32

Jim Miller <A HREF="mailto:jmiller@w3.org"><jmiller@w3.org></A>

33

<DT>

34

Authors:

35

<DD>

36

Tim Krauskopf

37

38

<DD>

39

Jim Miller

40

41

Paul Resnick

42

43

Win Treese

44

45

<DD>

46

</DL>

47

48

<HR>

49

<H2>

50

Status of this document

51

</H2>

52

53

This document has been reviewed by W3C members and other interested parties

54

and has been endorsed by the Director as a W3C Recommendation. It is a stable

55

document and may be used as reference material or cited as a normative reference

56

from another document. W3C's role in making the Recommendation is to draw

57

attention to the specification and to promote its widespread deployment.

58

This enhances the functionality and interoperability of the Web.

59

60

A list of current W3C Recommendations and other technical documents can be

61

found at

62

<A href="http://www.w3.org/pub/WWW/TR/">http://www.w3.org/pub/WWW/TR/</A>.

63

64

<H2>

65

Abstract

66

</H2>

67

68

This document has been prepared for the technical subcommittee of PICS (Platform

69

for Internet Content Selection). It defines a general format for labels and

70

three methods by which these labels may be transmitted:

71

<UL>

72

<LI>

73

In an HTML document.

74

<LI>

75

With a document transported via a protocol that uses RFC-822 headers.

76

<LI>

77

Separately from the document.

78

</UL>

79

<H2>

80

<HR>

81

82

Table of Contents

83

</H2>

84

85

<A HREF="#Overview">Overview</A>

86

87

<A HREF="#General">General Format</A>

88

89

<A HREF="#Example">Example</A>

90

91

<A HREF="#Detailed">Detailed Syntax</A>

92

93

<A HREF="#Semantics">Semantics of PICS Labels and Label Lists</A>

94

95

<A HREF="#Embedding">Embedding Labels in HyperText Markup Language (HTML)</A>

96

97

<A HREF="#Using">Using HTTP to Request Labels With A Document</A>

98

99

<A HREF="#Requesting">Requesting Labels Separately</A>

100

101

<A HREF="#MICs">MICs and Digital Signatures</A>

102

103

<A HREF="#Glossary">Glossary</A>

104

105

<A HREF="#Acknowledgements">Acknowledgments</A>

106

107

<A HREF="#Appendix A">Appendix A: An Algorithm for Locating a Label Bureau</A>

108

109

<A HREF="#Appendix B">Appendix B: Sample Label Bureau Queries and

110

Responses</A><A NAME="queries"> </A>

111

112

<HR>

113

<H2>

114

<A NAME="Overview">Overview</A>

115

</H2>

116

117

This document has been prepared for the technical subcommittee of PICS (Platform

118

for Internet Content Selection). It defines a general format for labels and

119

three methods by which these labels may be transmitted:

120

121

<DT>

122

In an HTML document.

123

<DD>

124

We specify a mechanism, using the existing META tag, for embedding one or

125

more labels in (the header of) an HTML document.

126

<DT>

127

With a document transported via a protocol that uses RFC-822 headers.

128

<DD>

129

Labels can be transmitted using any protocol that uses RFC-822-style

130

headers. In addition, we define an extension specific to the HTTP protocol

131

that allows an HTTP client (Web browser) to request which labels (if any)

132

it would like to have sent along with a document. The PICS committee hopes

133

that other network protocols will be extended in a similar way.

134

<DT>

135

Separately from the document.

136

<DD>

137

A client can request labels from a "label bureau" that runs the HTTP protocol.

138

The labels may refer to any document that has a URL (see

139

<A HREF="ftp://ds.internic.net/rfc/rfc1738.txt">RFC-1738</A>), including

140

those available through protocols other than HTTP, such as ftp, gopher, or

141

netnews. Notice that PICS defines a new URL scheme for referencing IRC chat

142

rooms (see <A href="http://w3.org/PICS/services.html">Rating Services and

143

Rating Systems</A>). The simplest implementation of a label bureau is an

144

off-the-shelf HTTP server running a special CGI script.

145

</DL>

146

<H2>

147

<A NAME="General">General Format</A>

148

</H2>

149

150

A label consists of a service identifier, label options, and

151

a rating. The service identifier is the URL chosen by the rating service

152

(see <A href="http://w3.org/PICS/services.html">Rating Services and Rating

153

Systems</A>) as its unique identifier. Label options give additional properties

154

of the document being rated as well as properties of the rating itself, such

155

as the time the document was rated. The rating itself is a set of attribute-value

156

pairs that describe a document along one or more dimensions. One or more

157

labels may be distributed together as a list. The general form for a label

158

list (formatted for presentation, and not showing error status codes) is:

159

<PRE>

160

(PICS-1.1

161

<service url> [option...]

162

labels [option...] ratings (<category> <value> ...)

163

[option...] ratings (<category> <value> ...)

164

...

165

<service url> [option...]

166

labels [option...] ratings (<category> <value> ...)

167

[option...] ratings (<category> <value> ...)

168

...

169

...)

170

</PRE>

171

172

A specific label applies to a single document. If the document is

173

in HTML format, it may refer to other documents, either by external reference

174

(for example, using the <A href=...> tag) or by requesting that they

175

be displayed in-line (for example, using the <img ...> or <object

176

...> tag). A label applies to the given document only, not to

177

the referenced documents.

178

179

A generic label (identified by the use of the generic option)

180

applies to any document whose URL begins with a specific string of characters

181

(specified using the for option). A generic label does not

182

have the expected semantics of a "default" label that can be overridden by

183

more specific labels. While a specific label does override a generic label

184

when a client has access to both, the two labels may be distributed separately,

185

and thus a client may have access to only the generic label. A server can

186

keep track of defaults and overrides and generate a specific label based

187

on a default that is not overridden in its local database. However, a generic

188

label for a site or directory should only be distributed if it applies to

189

all the documents in that site or directory.

190

191

A rating service may provide a generic label for any or all prefixes of a

192

given URL, but should provide only one specific label for that URL. When

193

the specific label for a document can be found, it should be used in preference

194

to any generic label. Lacking a specific label, any generic label may be

195

substituted, but preference should be given to the generic label which has

196

the longest string. Some PICS client software may impose restrictions on

197

the use of generic labels. For example, a client may choose to ignore a generic

198

label that applies to a node in the URL tree more than two levels above the

199

node where the document is located.

200

201

Label options can be divided into three groups. Options from the first group

202

supply information about the document to which the label applies. Options

203

from the second group supply information about the label itself. The last

204

group provides miscellaneous information.

205

<OL>

206

<LI>

207

Information about the document that is labeled.

208

209

<DT>

210

at quoted-ISO-date

211

<DD>

212

The last modification date of the item to which this rating applies, at the

213

time the rating was assigned. This can serve as a less expensive, but less

214

reliable, alternative to the message integrity check (MIC) options.

215

<DT>

216

MIC-md5 "Base64-string"

217

<DT>

218

-or- md5 "Base64-string"

219

<DD>

220

A message integrity check (MIC) of the item being rated. The MD5 Message

221

Digest Algorithm (see

222

<A HREF="ftp://ds.internic.net/rfc/rfc1321.txt">RFC1321</A>) is used to compute

223

the MIC. One way to create this message digest is to use the RSAREF (version

224

2.0) software available for this purpose at no charge from RSA Laboratories.

225

See <A href="#MICs">MICs and Digital Signatures</A> below.

226

</DL>

227

<LI>

228

Information about the label itself.

229

<DL>

230

<DT>

231

by quotedname

232

<DD>

233

An identifier for the person or entity within the rating service who was

234

responsible for creating this particular label. This may be human readable,

235

or it may be used to contain a (base-64 encoded) set of certificates and

236

other information used to verify the signature on the label.

237

<DT>

238

for quotedURL

239

<DD>

240

The URL (or prefix string of a URL) of the item to which this rating applies.

241

This option is required for generic labels and in certain other cases (see

242

"Requesting Labels Separately," below); it is optional in other cases. Since

243

a single document can have many URLs, the URL used to retrieve a document

244

may differ from the URL in the for option of a label that accompanies

245

the document.

246

<DT>

247

generic boolean

248

<DT>

249

-or- gen boolean

250

<DD>

251

If this option is set to true, the label can be applied to any URL starting

252

with the prefix given in the for option. This is used to supply ratings

253

for entire sites or any subparts of sites. All generic labels must also include

254

the for option. As mentioned earlier, a generic label should not be

255

created unless it can be legitimately applied to all documents whose

256

URL begins with the prefix specified in the for option (even if a

257

more specific label exists).

258

<DT>

259

on quoted-ISO-date

260

<DD>

261

The date on which this rating was issued.

262

<DT>

263

signature-RSA-MD5 "Base64-string"

264

<DD>

265

An RSA digital signature encompassing the label. The signature is computed

266

using the MD5 algorithm by the rating service that issued the label. One

267

way to create this signature is to use the RSAREF (version 2.0) software

268

available for this purpose at no charge from RSA Laboratories. See

269

<A href="#MICs">MICs and Digital Signatures</A> below.

270

<DT>

271

until quoted-ISO-date

272

<DT>

273

-or- exp quoted-ISO-date

274

<DD>

275

The date on which this rating expires.

276

</DL>

277

<LI>

278

Other information.

279

<DL>

280

<DT>

281

comment quotedname

282

<DD>

283

Information for humans who may see the label; no associated semantics.

284

<DT>

285

complete-label quotedURL

286

<DT>

287

-or- full quotedURL

288

<DD>

289

Dereferencing this URL returns a complete label that can be used in place

290

of the current one. The complete label has values for as many attributes

291

as possible. This is used when a short label is transmitted for performance

292

purposes but additional information is also available. When the URL is

293

dereferenced it returns an item of type application/pics-labels that contains

294

a labellist with exactly one label.

295

<DT>

296

extension (optional quotedURL data*)

297

<DT>

298

-or- extension (mandatory quotedURL data*)

299

<DD>

300

Future extension mechanism. To avoid duplication of extension names, each

301

extension is identified by a quotedURL. The URL can be dereferenced

302

to get a human-readable description of the extension. If the extension is

303

optional then software which does not understand the extension can

304

simply ignore it; if the extension is mandatory then software which

305

does not understand the extension should act as though no label had been

306

supplied. Each item of data must be one of a fixed set of simple-to-parse

307

data types as specified in the detailed syntax below. See

308

<A href="http://w3.org/PICS/extensions/"> http://w3.org/PICS/extensions/</A>

309

to find out what extensions are currently in use.

310

</DL>

311

</OL>

312

<H2>

313

<A NAME="Example">Example</A>

314

</H2>

315

316

For example, a label list for two documents, using the example rating system

317

from <A HREF="REC-PICS-services-961031.html">PICS Rating Services and Rating

318

Systems</A>, might be as follows (in all examples, the spacing and indentation

319

is provided for readability; the specification treats multiple white space

320

characters as if they were compressed into a single space):

321

<PRE>

322

(PICS-1.1 "http://www.gcf.org/v2.5"

323

by "John Doe"

324

labels on "1994.11.05T08:15-0500"

325

until "1995.12.31T23:59-0000"

326

for "http://w3.org/PICS/Overview.html"

327

ratings (suds 0.5 density 0 color/hue 1)

328

for "http://w3.org/PICS/Underview.html"

329

by "Jane Doe"

330

ratings (subject 2 density 1 color/hue 1))

331

</PRE>

332

333

The same label list may be transmitted more compactly by converting all of

334

the line breaks and subsequent indentation characters into a single space,

335

and by replacing the word "labels" with "l", "ratings" with "r" and long

336

option names with their abbreviations. It may be compressed for transmission

337

purposes even further by removing all of the optional information to a separate

338

document and referencing that document by a URL:

339

<PRE>

340

(PICS-1.1 "http://www.gcf.org/v2.5" l

341

full "http://www.gcf.org/labels/13242123"

342

r (suds 0.5 density 0 color/hue 1)

343

full "http://www.gcf.org/labels/123412278"

344

r (subject 2 density 1 color/hue 1))

345

</PRE>

346

347

Finally, the optional information may be omitted entirely, reducing the

348

information content of the labels but making the transmission even smaller.

349

The resulting label list would then be:

350

<PRE>

351

(PICS-1.1 "http://www.gcf.org/v2.5"

352

l r (suds 0.5 density 0 color/hue 1)

353

r (subject 2 density 1 color/hue 1))

354

</PRE>

355

<H2>

356

<A NAME="Detailed">Detailed Syntax</A>

357

</H2>

358

359

The following grammar, in modified BNF, describes the syntax of labels. The

360

methods by which labels are embedded in specific protocols are detailed below.

361

362

Notes:

363

<OL>

364

<LI>

365

The string "PICS-1.1" in version corresponds to the version number

366

1.1 of the PICS specification in <A HREF="REC-PICS-services-961031.html">PICS

367

Rating Services and Rating Systems</A>. While it is inelegant that the service

368

description uses the notation "(PICS-version 1.1)" while the label itself

369

uses "PICS-1.1", it is intentional.

370

<LI>

371

Whitespace is ignored except in quoted strings. Multiple contiguous whitespace

372

characters can be treated as though they were a single space character.

373

<LI>

374

Transmit-names and quoted strings are case sensitive. Option names and other

375

tokens in the BNF grammar are case insensitive.

376

<LI>

377

This specification is strictly about information carried over the wire from

378

the client to the server, and it requires the use of US-ASCII. The companion

379

document <A HREF="REC-PICS-services-961031.html">PICS Rating Services and

380

Rating Systems</A> describes how a client can map these transmit-names to

381

descriptive strings using other character sets. Clients are advised to cache

382

the descriptions of rating services they use so that the information in labels

383

can be conveniently presented to the user.

384

<LI>

385

An option that appears in the service-info applies to all labels in

386

that service-info unless overridden by an option in a specific

387

label. That is, a label is effectively lexically nested within

388

the enclosing service-info for the purpose of understanding the applicable

389

options. This is most likely to be useful in the case of the by,

390

generic, on, until and experimental or future options. In the

391

first example above, the by option (with the value "John Doe") supplied

392

with the service-info applies to the first label, but is overridden

393

in the second (by the value "Jane Doe").

394

<LI>

395

Numbers in PICS labels may be integers or fractions with no greater range

396

or precision than that provided by IEEE single-precision floating point numbers.

397

Implementors concerned about the vagaries of floating point comparisons may

398

choose to represent numbers internally as ASCII strings.

399

<LI>

400

The multi-value syntax must be used when there is more than

401

one value for a particular category. This syntax may be used when

402

there is exactly one value, but the more compact version may also be used

403

in that case. When there is no value, the category may be omitted entirely

404

or transmitted using the multi-value syntax.

405

<LI>

406

The only options that may occur more than once in a particular

407

single-label or service-info are comment and

408

extension; if the extension option is supplied more than once,

409

the quotedURLs defining the extensions must be distinct.

410

<LI>

411

Categories may appear in any order in a rating; they need not match

412

the order in which they appear in the <TT>application/pics-service</TT>.

413

<LI>

414

For parsing purposes, notice that a label ends with either "ratings" or "r"

415

followed by a parenthesized list of categories and values. If this does not

416

end the label list, it is followed by either another label (possibly starting

417

with options), a new service URL (recognizable because it must be surrounded

418

by quotation marks), or an error (starting with the word "error").

419

</OL>

420

<PRE>

421

labellist :: '(' version service-info+ ')'

422

version :: 'PICS-1.1'

423

service-info :: 'error' '(no-ratings' explanation* ')'

424

| serviceID service-error | serviceID option* labelword label*

425

serviceID :: quotedURL

426

labelword :: 'labels' | 'l'

427

label :: label-error | single-label | '(' single-label* ')'

428

single-label :: option* ratingword '(' rating+ ')'

429

ratingword :: 'ratings' | 'r'

430

quotedURL :: '"' URL '"' as described and extended in

431

<A HREF="REC-PICS-services-961031.html">Rating Services and Rating Systems</A>.

432

option :: labeloption | documentoption | otheroption

433

labeloption ::

434

'by' quotedname

435

| 'generic' boolean | 'gen' boolean

436

| 'for' quotedURL

437

| 'on' quoted-ISO-date

438

| 'signature-RSA-MD5' "base64-string"

439

| 'until' quoted-ISO-date | 'exp' quoted-ISO-date

440

documentoption ::

441

'at' quoted-ISO-date

442

| 'MIC-md5' "base64-string" | 'md5' "base64-string"

443

otheroption ::

444

'comment' quotedname

445

| 'complete-label' quotedURL | 'full' quotedURL

446

| 'extension' '(' mand/opt quotedURL data* ')'

447

mand/opt :: 'optional' | 'mandatory'

448

data :: quoted-ISO-date | quotedURL

449

| number | quotedname | '(' data* ')'

450

quoted-ISO-date :: '"'YYYY'.'MM'.'DD'T'hh':'mmStz'"'

451

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

452

to the specific form described here:

453

YYYY :: four-digit year

454

MM :: two-digit month (01=January, etc.)

455

DD :: two-digit day of month (01 through 31)

456

hh :: two digits of hour (00 through 23) (am/pm NOT allowed)

457

mm :: two digits of minute (00 through 60)

458

S :: sign of time zone offset from UTC ('+' or '-')

459

tz :: four digit amount of offset from UTC

460

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

461

For example, "1994.11.05T08:15-0500" is a valid quoted-ISO-date

462

denoting November 5, 1994, 8:15 am, US Eastern Standard Time

463

Note: The ISO standard allows considerably greater

464

flexibility than that described here. PICS requires precisely

465

the syntax described here -- neither the time nor the time zone may

466

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

467

the punctuation must be as specified here.

468

rating :: transmit-name number | transmit-name '(' multi-value* ')'

469

multi-value :: number | number ':' number

470

transmit-name :: transmit-name-char+ ['/' transmit-name]

471

number :: [sign]unsignedint['.' [unsignedint]]

472

sign :: '+' | '-'

473

unsignedint :: [0-9]+

474

quotedname :: '"' urlchar-or-space+ '"'

475

alphanumpm :: 'A' | ... | 'Z' | 'a' | ... | 'z' | '0' | ... | '9' | sign

476

transmit-name-char :: alphanumpm | '.' | '$' | ',' | ';' | ':'

477

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

478

| '#' | '_' | '%' hex hex

479

Note: Use the "%" escape technique (% followed by the two

480

hex digits that represent the character in the ASCII character

481

set) to insert single or double quotation marks or parentheses.

482

urlchar :: transmit-name-char | '(' | ')'

483

hex :: '0' | ... | '9' | 'A' | ... | 'F' | 'a' | ... | 'f'

484

urlchar-or-space :: urlchar | ' '

485

base64-string :: as defined in <A HREF="ftp://ds.internic.net/rfc/rfc1521.txt">RFC-1521</A>.

486

service-error :: 'error' '(' 'request-denied' explanation* ')'

487

| 'error' 'service-unavailable'

488

label-error :: 'error' '(' 'request-denied' [quotedURL explanation*] ')'

489

| 'error' '(' 'not-labeled' quotedURL* ')'

490

explanation :: quotedname

491

</PRE>

492

<H2>

493

<A NAME="Semantics">Semantics of PICS Labels and Label Lists</A>

494

</H2>

495

496

A labellist is used to transmit a set of PICS labels. The format specified

497

here is intended to be registered with IANA as the MIME type

498

"application/pics-labels." It allows for transmission of both labels and

499

reasons why labels are not available, and is the format used when labels

500

must be conveyed in a document, along with a document, or from a PICS label

501

bureau. The labellist will always be surrounded by parentheses and

502

begin with the PICS version number (1.1 in this specification).

503

504

A label list either specifies that there are no labels available at all (e.g.,

505

"error (no-ratings ...)") or is separated into sections of labels, one section

506

for each rating service. The URL of each service must be specified (the

507

serviceID). This is either followed by an error message indicating

508

why no labels are available from that service (service-error) or an

509

overall set of optional information (option*) followed by the keyword

510

"labels" (or "l") and the labels from the service. The optional

511

information provided here applies to every label from the service, unless

512

overridden in the specific label itself.

513

514

A label encompasses three separate cases. The first is an error that

515

applies to retrieving the label for a particular URL (label-error).

516

The second, and most common, is a single-label consisting of options

517

(which override those specified with the service), the marker word "ratings"

518

(or "r") and the ratings themselves (a list of category names and values).

519

Finally, in the special case where the ratings for an entire tree of documents

520

have been requested, any number of single-labels can be transmitted,

521

enclosed in parentheses. This case is described in more detail in the section

522

on "Requesting Labels Separately."

523

524

A label may apply to a specific URL, or it may be generic. A generic label

525

implicitly rates every URL for which the specified one is a prefix. For example,

526

a generic label for the URL "http://w3.org" implicitly rates every document

527

available at that site. A specific (non-generic) label for the same URL,

528

"http://w3.org", does not give any implicit ratings: it merely rates the

529

organization's home page that is fetched by the command "<CODE>GET /</CODE>"

530

sent by HTTP to the host <CODE>w3.org</CODE>. A generic label must

531

include the "for" option specifying the URL to which it applies.

532

As mentioned above, a generic label should be supplied only if it can be

533

legitimately applied to all documents with URLs that begin with

534

the string specified in the label's for option.

535

536

When a multi-value is provided, any combination of numbers and ranges

537

of numbers may be specified, with the endpoints of a range separated by a

538

":". Thus, in the labellist

539

<PRE>

540

(PICS-1.1 "http://www.gcf.org/v2.5" l

541

r (suds 0.5 density 0 color/hue 1 subject (0.5:1.5 2)))

542

</PRE>

543

544

all subject values between 0.5 and 1.5 (including both endpoints) apply to

545

the item, as does the subject value 2. Given the example service description

546

in <A href="http://w3.org/PICS/services.html">Rating Services and Rating

547

Systems</A>, two document subjects apply, "water" (subject value 1) and

548

"soapdish" (subject value 2.) The third, "soap," has subject value 0, so

549

it does not apply.

550

<H2>

551

RFC-822 Headers

552

</H2>

553

554

Many protocols, such as Internet electronic mail, the HyperText Transfer

555

Protocol, and USENET News, use US-ASCII headers as described in RFC-822.

556

For use in such protocols, we define a new header, PICS-Label, used to contain

557

the labels described in this document. The syntax is:

558

<PRE>

559

PICS-Label: <labellist>

560

</PRE>

561

562

where labellist is described according to the syntax above. Continuation

563

lines beginning with whitespace may be used following the specification given

564

in RFC-822.

565

<H2>

566

<A NAME="Embedding">Embedding Labels in HyperText Markup Language (HTML)</A>

567

</H2>

568

569

Labels may be embedded in HTML files as meta-information, using the META

570

element defined in the HTML specification. This embedding uses the HTTP header

571

equivalence mechanism:

572

<PRE>

573

574

</PRE>

575

576

Note that the content attribute uses single quotes, because the PICS label

577

syntax uses double quotes. Any of the following characters appearing within

578

the content must be escaped using SGML entities:

579

<PRE>

580

' &#39; /* single quote */

581

& &amp; /* ampersand */

582

> &gt; /* greater than */

583

</PRE>

584

585

See the <A HREF="http://ds.internic.net/rfc/rfc1866.txt">HTML 2.0 Proposed

586

Standard</A>.

587

588

A label that is embedded in a document may omit the "for" option, which would

589

normally specify a URL to which the label applies. A specific (non-generic)

590

label embedded in a document applies to that document, regardless of what

591

URL is used to locate the document. A generic label, when embedded in a document

592

that can be retrieved via a "home" URL (i.e., a URL path ending in /), applies

593

to all URLs that include the home URL as a prefix.

594

595

For example, if a client is interested in a label for the document

596

"http://www.greatdocs.com/foo/bar/bat.htm", it can first check whether the

597

document has a specific label embedded in it. If not, the client can ask

598

for the document "http://www.greatdocs.com/foo/bar/". The server sends back

599

the home document for foo/bar, which may be foo/bar/index.html,

600

foo/bar/home.html, or something else, depending on the server. If that document

601

contains an embedded generic label, then the client may interpret it as applying

602

to the document bat.htm. If the client does not find a generic label there,

603

it may check further up the hierarchy, in "http://www.greatdoc.com/foo/"

604

or even at "http://www.greatdocs.com/".

605

606

Web site operators who wish to provide specific labels for their html documents

607

are encouraged to embed them in the documents. Those who wish to provide

608

generic labels for their sites or subparts of their sites are encouraged

609

to include them in the home documents at as many levels of the document naming

610

hierarchy as they think are appropriate. They are also encouraged to use

611

the more elegant and functional method, described in the next section, of

612

sending labels in the http header stream, whenever tools are available for

613

doing so.

614

<H2>

615

<A NAME="Using">Using HTTP to Request Labels With A Document</A>

616

</H2>

617

618

We specify a simple extension to HTTP that allows a client to request that

619

one or more labels be included in a header along with the document. We deal

620

here only with the HTTP protocol; we hope that other protocols will be similarly

621

extended. HTTP servers should include PICS label headers only if requested

622

to do so by the client, and should only include the labels from services

623

requested by the client. As with labels embedded in documents, the client

624

may assume that a label returned in the http header stream applies to the

625

document requested, regardless of the URL specified in the "for" option of

626

the label.

627

<H3>

628

Example

629

</H3>

630

631

Client sends to HTTP server www.greatdocs.com, a PICS-enabled server:

632

<PRE>

633

GET /foo.html HTTP/1.0

634

Protocol-Request: {PICS-1.1 {params full

635

{services "http://www.gcf.org/v2.5"}}}

636

</PRE>

637

638

Server responds to client:

639

<PRE>

640

HTTP/1.0 200 OK

641

Date: Thu, 30 Jun 1995 17:51:47 GMT

642

Last-modified: Thursday, 29-Jun-95 17:51:47 GMT

643

Protocol: {PICS-1.1 {headers PICS-Label}}

644

PICS-Label:

645

(PICS-1.1 "http://www.gcf.org/v2.5" labels

646

on "1994.11.05T08:15-0500"

647

exp "1995.12.31T23:59-0000"

648

for "http://www.greatdocs.com/foo.html"

649

by "George Sanderson, Jr."

650

ratings (suds 0.5 density 0 color/hue 1))

651

Content-type: text/html

652

653

...contents of foo.html...

654

</PRE>

655

<H3>

656

Explanation of example

657

</H3>

658

659

The client requests the document foo.html. In addition, the client requests

660

the full label of the document from the rating service "http://www.gcf.org/v2.5".

661

The server responds by sending back the label, in the PICS-Label header,

662

as well as the document. The format of the PICS-Label header field (a

663

labellist) allows the server to respond either with a label or an

664

explanation of why the label is not available, since it would be inappropriate

665

for the server to generate an HTTP error status if the document is available

666

but (some of) the labels are not.

667

668

Following the usual HTTP distinction between HEAD and GET, a client that

669

wishes to examine a rating before retrieving the full document can substitute

670

the word HEAD for GET in the request. The server responds with exactly the

671

headers shown above, but does not send back the document foo.html.

672

<H3>

673

Detailed Syntax of HTTP Requests for Labels With Document

674

</H3>

675

676

The following grammar, in modified BNF, describes the syntax of the additional

677

header line to be included in an HTTP request for a document and associated

678

labels.

679

<PRE>

680

request-header ::

681

'Protocol-Request: {PICS-1.1 {params ' [completeness]

682

extension*

683

services '}}'

684

completeness :: 'minimal' | 'short' | 'full' | 'signed'

685

extension :: '{' token-or-quoted-string+ '}'

686

where the first token-or-quoted-string is not 'services'.

687

token-or-quoted-string :: token | quotedname

688

token :: alphanumpm+

689

services :: '{' 'services' quotedURL+ '}'

690

</PRE>

691

692

A request for a minimal label asks that all options be omitted, unless

693

a generic label is returned, in which case the generic and for

694

options must also be included in the label. A short label includes

695

everything that is included in a minimal label, plus additional options

696

that the server deems appropriate. A request for a full label asks

697

that as much information as possible should be sent back in the label, either

698

directly or through the use of a complete-label (or full) option,

699

but no signature-RSA-MD5 option is needed.

700

701

A request for signed labels asks that all the information in a

702

full label should be sent, along with a digital signature on the label

703

itself. In a signed label the information must be transmitted directly as

704

part of the label (and included in the computation of the signature); the

705

complete-label (or full) option may be sent, but it would be

706

redundant. Details of signing labels are included in the section

707

<A href="#MICs">MICs and Digital Signature</A>.

708

709

It is acceptable for a server to ignore the completeness, either by

710

delivering more or fewer options than requested. If the completeness

711

is omitted, it should be treated as though minimal had been supplied.

712

For future extensibility, any alphanumeric string may be used for a value

713

of the completeness option. Servers which receive a value of

714

completeness that they do not recognize must treat it as though

715

minimal had been specified.

716

717

The extensions are for future extensions to the protocol; any extensions

718

which are not understood by the server must be ignored by it. It is recommended

719

that experimental extensions use a URL, which dereferences to a description

720

of the extension, as the initial token-or-quoted-string.

721

722

Each quotedURL in a service specifies a rating service from

723

which the client is requesting a label for the document. There may be as

724

many repetitions of the quotedURL part of the service as desired,

725

so it is possible to request labels from any number of rating services in

726

a single HTTP request.

727

<H3>

728

Detailed Syntax For HTTP Response Headers For Labels With Document

729

</H3>

730

731

Two additional headers are specified:

732

<PRE>

733

protocol-header :: 'Protocol: {PICS-1.1 {headers PICS-Label}}'

734

label-header :: 'PICS-Label: ' labellist

735

</PRE>

736

<H2>

737

<A NAME="Requesting">Requesting Labels Separately</A>

738

</H2>

739

740

PICS labels can also be retrieved separately from the documents to which

741

they refer. To request labels in this way, a client contacts a label

742

bureau. A label bureau is an HTTP server that understands a particular

743

query syntax, defined below. It can provide labels for documents that reside

744

on other servers, and, indeed, for documents available through protocols

745

other than HTTP. It is anticipated that there will be "well-known" label

746

bureaus which dispense (possibly for a fee) labels created by many rating

747

services.

748

749

Rating services are also encouraged to act as label bureaus, providing on-line

750

access to their own labels. By default, the URL that identifies a rating

751

service also identifies its label bureau. If a client requests the URL that

752

identifies a rating service, a human-readable description of the service

753

is returned, as specified in <A href="http://w3.org/PICS/services.html">Rating

754

Services and Rating Systems</A>. If, on the other hand, a client requests

755

the same URL and includes query parameters as defined below, it should be

756

interpreted as a request for labels. A rating service, however, is not required

757

to act as a label bureau, and it may choose a different URL (perhaps even

758

on a different HTTP server) to act as its label bureau.

759

<H3>

760

Sample Query

761

</H3>

762

763

(For more complex queries and responses, see <A href="#queries">Appendix

764

B.</A>)

765

766

Imagine a rating service, identified by the URL http://www.labels.org/Ratings,

767

which decides to run a label bureau to dispense (at least) its own labels

768

for documents. The following sample request, made to the HTTP server

769

www.labels.org, is illustrative (line breaks are inserted for presentation

770

purposes only):

771

<PRE>

772

GET /Ratings?opt=generic&

773

u="http%3A%2F%2Fwww.questionable.org%2Fimages"&

774

s="http%3A%2F%2Fwww.gcf.org%2Fv2.5"

775

HTTP/1.0

776

</PRE>

777

778

The query asks the label bureau http://www.labels.org/Ratings to send a single

779

label that applies to everything in the images hierarchy at site

780

www.questionable.org. The desired label should have been created by the service

781

http://www.gcf.org/v2.5. Notice the use of %3A to represent a ":" and %2F

782

for "/." This is required for encoding characters within a URL. See

783

<A HREF="ftp://ds.internic.net/rfc/rfc1738.txt">RFC-1738</A>.

784

785

The label bureau responds by sending back a document of type

786

"application/pics-labels." The labels should be as complete as possible,

787

either by including as many options as possible or by supplying the

788

complete-label (or full) option.

789

<H3>

790

Detailed Syntax of HTTP Query for Labels Separate From Documents

791

</H3>

792

793

The following grammar, in modified BNF, describes the syntax of GET and POST

794

requests to a label bureau. The use of the POST request is specified only

795

for backward compatibility with HTTP servers that cannot handle a long GET

796

query. Its use, while described in the

797

<A href="ftp://ds.internic.net/rfc/rfc1866.txt">HTML 2.0</A> specification

798

(for use in submitting forms, see section 8.2.1 and 8.2.3), is deprecated.

799

<PRE>

800

request :: get | post

801

get :: 'get' url-fragment '?' [opt] [format]

802

extension* url+ service+

803

post :: 'post' url-fragment crlf crlf formencodeddata

804

url-fragment :: the part of the original URL after the host

805

name, as specified in HTTP 1.0.

806

crlf :: carriage return (hex D) followed by line feed (hex A)

807

opt :: 'opt=' option

808

option :: 'generic' | 'normal' | 'tree' | 'generic+tree'

809

format :: [and] 'format=' form

810

form :: 'minimal' | 'short' | 'full' | 'signed'

811

extension :: token '=' token-or-quoted-string

812

where the token is not one of opt, format,

813

u, or s; and token-or-quoted-string follows

814

the quoting conventions specified in <A HREF="ftp://ds.internic.net/rfc/rfc1738.txt">RFC-1738</A>

815

token-or-quoted-string :: token | quotedname

816

token :: alphanumpm+

817

url :: [and] 'u=' encodedURL

818

service :: [and] 's=' encodedURL

819

boolean :: 't' | 'f' | 'true' | 'false'

820

and :: '&' this must be included unless it immediately

821

follows the ? in the query.

822

encodedURL :: a quoted URL. Following <A HREF="ftp://ds.internic.net/rfc/rfc1738.txt">RFC-1738</A>, quotation and some

823

special characters inside the URL are encoded using "%xx" notation.

824

Alphabetic characters, digits, and the special characters

825

$_-.+!*'(), need not be quoted, but other characters must be.

826

This does imply that the colon (:) must be encoded as %3A

827

and slash (/) as %2F.

828

formencodeddata :: The query as specified for get but encoded into

829

MIME type application/x-www-form-encoded as described in

830

sections 8.2.1 and 8.2.3 of <A href="ftp://ds.internic.net/rfc/rfc1866.txt">HTML 2.0</A>.

831

</PRE>

832

<H3>

833

Response to Query for Labels Separate From Documents

834

</H3>

835

<UL>

836

<LI>

837

The label bureau responds by sending back a document of type

838

"application/pics-labels."

839

<LI>

840

Unless the document indicates an overall error, there should be one

841

service-info for each rating service requested in the query. Each

842

service-info should have an error message or a label (or list of labels,

843

in the case of a "tree" query) for each requested URL.

844

<LI>

845

The query's ordering must be preserved in the response. That is, the information

846

from the rating services must be presented in the same order the rating services

847

appear in the query, and the labels from each service must be presented in

848

the same order the URLs appear in the query. If a rating service or label

849

is not provided, the error message should appear in the same position that

850

the service-info or label would appear. Because order is preserved,

851

it is acceptable (except where indicated below) to omit from the labels the

852

"for" option which indicates the URL being rated. The client should

853

match the label positionally with the URL for which it requested a rating.

854

<LI>

855

Definitions. Given a URL (e.g., "http://www.greatdocs.com/foo/"),

856

a descendant URL is any URL that contains the original as a prefix

857

(e.g., "http://www.greatdocs.com/foo/bar/bat.htm"). A child URL is

858

any descendant URL that does not contain any additional '/' characters (e.g.,

859

"http://www.greatdocs.com/foo/ba"). An ancestor URL is any URL that

860

is a prefix of the original (e.g., "http://www.greatdocs.com/f"). Note that

861

ancestry and descendence is determined strictly by case-sensitive string

862

matching on URLs, not by any links that may appear in html documents retrieved

863

using those URLs. Note that any quotation such as %3A for colon (:) or %2F

864

for slash (/) is unencoded prior to comparing URL strings.

865

<LI>

866

opt=normal, or omitting the opt completely, requests specific

867

labels for the URLs specified. If no specific label is available for a requested

868

URL, the server may choose to send a generic label for the requested URL

869

or for an ancestor URL. For example, in response to a label request for URL

870

"http://w3.org/PICS/Overview.html" a generic label for the URL

871

"http://w3.org/PICS" (or even "http://w3.org") may be returned. In this case,

872

it is required that the "for" and "generic" options be included

873

in the label, to specify exactly what rating is being returned. Note that

874

the "for" option may specify a URL string which does not appear to match

875

the request URL, perhaps due to the server knowing about the existence of

876

an alternative URL for the same document. In that case, the server is suggesting

877

that the label applies to the request URL, though a suspicious client may

878

choose not to believe the suggestion.

879

<LI>

880

opt=generic requests generic labels. It is useful for requesting a

881

rating of a site or subpart of a site. For each requested URL, the desired

882

response is a generic label that applies to the requested URL and all descendant

883

URLs. A generic label for the requested URL, or a generic label for any ancestor

884

URL, would satisfy this request, as such a generic label would apply to all

885

URLs containing the requested URL as a prefix. If no such generic label is

886

available, the server should include the "no-label" message rather than sending

887

back a specific label.

888

<LI>

889

opt=tree requests a tree of labels. This is a way to request all the

890

labels that apply to items in a site or subpart of a site. For each requested

891

URL, the desired response is a set of labels (both specific and generic)

892

that apply to descendants of the requested URL. In the response, everywhere

893

a label would normally be expected in the response, a set of

894

simple-labels will be returned, surrounded by parentheses. This enables

895

the client to match the entire set positionally with the single request URL.

896

All labels produced in response to this query must include a for option.

897

The minimum response expected is the set of labels that would have been generated

898

if a query had been issued, with opt=normal specified, for each known

899

child of the requested URL. Additional labels may also be returned, typically

900

either generic labels for ancestor URLs or labels for descendant URLs farther

901

down the hierarchy than children.

902

<LI>

903

opt=generic+tree is similar to the opt=tree request, but returns

904

only generic labels. As with opt=tree, the server can choose the amount

905

of detail. The minimum response expected is the set of labels that would

906

have been generated if a query had been issued, with opt=generic

907

specified, for each known child of the requested URL. Additional labels may

908

also be returned, typically generic labels for ancestor URLs. All labels

909

produced in response to this query must include a for option.

910

<LI>

911

It is permitted to include more than one URL and/or service in the request.

912

Requesting u URLs and s services results in a total of u

913

x s labels being generated (or label sets in the case of tree and

914

generic+tree queries.)

915

<LI>

916

The format= specifies the optional information that should be transmitted

917

with the labels. It is treated precisely as the similar keywords would be

918

when sent to a document server as the completeness (see

919

<A href="#with">Detailed Syntax of HTTP Requests for Labels With Document</A>),

920

except that the default is full (rather than minimal). Servers

921

which receive a value of completeness that they do not recognize must

922

treat it as though the default, full, had been specified. All labels

923

produced in response to this query must include a for option.

924

</UL>

925

<H2>

926

<A NAME="MICs">MICs and Digital Signatures</A>

927

</H2>

928

929

This specification includes two independent security features, each intended

930

to prevent a different problem that can arise in a PICS system. They may

931

be used independently or together. Both features rely on patented cryptographic

932

technology whose use is subject to a variety of legal restrictions (including

933

possible U.S. export controls). The PICS technical committee cannot provide

934

any information about the exact legal status of the code or algorithms.

935

936

Within the United States, RSA Laboratories (100 Marine Parkway, Redwood City,

937

CA, 94065-1031) distributes a source code kit called

938

<A href="http://www.rsa.com/rsalabs/faq/faq_misc.html">RSAREF</A> which provides

939

all of the code required to implement the cryptographic components of the

940

PICS spec. The president of RSA Data Security, Inc., Mr. Jim Bidzos, has

941

advised us that RSAREF will be made available at no cost for use in implementing

942

the PICS specifications. Questions about the legal status, etc., should be

943

directed to Mr. Bidzos.

944

945

The first problem arises when a document has been examined and a label generated,

946

and then the document is modified without updating the label. While this

947

can happen legitimately (as when Time-Warner updates the page containing

948

the current issue of Time Magazine and believes that the label is still valid)

949

it can also happen as a result of tampering with the document by an unauthorized

950

party. PICS labels contain three option fields intended to help deter this

951

kind of problem:

952

<DL>

953

<DT>

954

At

955

<DD>

956

If the objective is to simply detect accidental changes, then the date of

957

last modification of the document can be calculated when the label is created

958

and stored in the at field. Assuming that the last modification time

959

is accurately maintained, this will detect updates to the document made after

960

the label was created.

961

<DT>

962

Until or exp

963

<DD>

964

If the document is expected to be updated infrequently or periodically, the

965

label can contain an expiration date that should cause the label to be invalid

966

before the document is next updated. This, too, does not guard against a

967

concerted malicious attack.

968

<DT>

969

MIC-md5 or md5

970

<DD>

971

If the label is intended to apply only to the data that was actually rated,

972

then a form of checksum (called a "message digest") can be applied to the

973

data when the label is created. The message digest is converted into US-ASCII

974

characters using <A href="ftp://ds.internic.net/rfc/rfc1521.txt">MIME</A>

975

base-64 encoding and stored in the MIC-md5 (also called md5)

976

field. When the document is later retrieved, the same algorithm can be used

977

to recompute the message digest and the two digests can be compared. The

978

MD5 algorithm is designed so that it is extremely unlikely that the two digests

979

will be the same if the document has been tampered with in any way.

980

This technique is well-known in the cryptographic community and has been

981

adopted by the electronic mail community, where it is part of the

982

<A href="ftp://ds.internic.net/rfc/rfc1848.txt">MOSS</A> specification. For

983

use with electronic mail, an elaborate technique is required to assure that

984

the two message digests will match, since electronic mail gateways can modify

985

the data before it is delivered (by wrapping lines, for example). We have

986

chosen not to adopt MOSS directly for PICS, largely because of this

987

complexity.

988

Instead, we recommend the direct use of the MD5 algorithm on the source document

989

and conversion of the result to base64 encoding. This resulting string is

990

included directly in the mic-md5 (md5) label option. The MD5

991

algorithm and the conversion of the result into US-ASCII characters is provided

992

by the RSAREF (version 2.0) software.

993

Because PICS labels can be embedded inside of the documents they label, care

994

must be taken to ensure that the message digest is computed excluding

995

all PICS labels in the document. For HTML documents, this means

996

that the digest must be computed after removing all META elements that include

997

PICS labels (and any whitespace immediately following the end of each of

998

these meta elements).

999

</DL>

1000

1001

The second problem is that of tampering with or forging labels. Here the

1002

problem is that the end user needs some way of being reassured that the label

1003

they receive was created by the rating service they expected and that it

1004

has not been altered since it was created. PICS addresses this problem by

1005

allowing labels to be "digitally signed". A digital signature, while not

1006

currently legally recognized, is a cryptographic technique to provide exactly

1007

this assurance. The RSA signature technique works as follows:

1008

<UL>

1009

<LI>

1010

In order to sign a label, the rating service (or people authorized to generate

1011

labels on behalf of the service) needs a "public key pair." (The RSAREF software

1012

includes routines to create these pairs.) One of these (the private key)

1013

must be kept secret by the service; the other (the public key) must be

1014

distributed to anyone who is interested in verifying the signatures on the

1015

service's labels.

1016

<LI>

1017

After creating a label, the service converts it to a special form specified

1018

below and computes the MD5 message digest of the label. It then uses the

1019

service's private key to encrypt the digest. This encrypted digest is the

1020

digital signature, and it is converted to US-ASCII using the same base64

1021

encoding technique mentioned above. The US-ASCII version (split into 60 character

1022

lines) is stored in the signature-rsa-md5 option of the label when

1023

it is transmitted to the client. (The RSAREF software includes routines to

1024

generate the signature and convert it to US-ASCII.)

1025

<LI>

1026

When the client receives a label and wants to verify the signature it takes

1027

the label it received and converts it back into the same special form in

1028

which it was originally signed. The client recomputes the message digest

1029

on this special form. It also takes the contents of the

1030

signature-rsa-md5 option, combines all of the lines back into a single

1031

string of US-ASCII characters, converts these from base64 into their original

1032

(binary) form, and decrypts them using the service's public key. If the result

1033

isn't the same as the message digest it computed the signature is invalid.

1034

(RSAREF contains routines to do all of this work except for the combining

1035

of the lines into a long string.)

1036

</UL>

1037

1038

The problem of distributing these keys (and invalidating them in case the

1039

service's key is compromised) is an active area of commercial competition.

1040

Since there is no clearly established solution available today, PICS assumes

1041

that each service will distribute the public keys in some way it chooses.

1042

It also assumes that no keys will ever have to be invalidated. While this

1043

is clearly not a perfect solution, it seems to be the limit of what can be

1044

done today without committing to specific proprietary technology.

1045

1046

There is one additional problem with the digital signature solution outlined

1047

above. If a rating service allows other people to generate labels under its

1048

name (for example, a service that supports self-ratings by content producers)

1049

then the labels may need to be signed by both the service and the

1050

content producer. This can be done (each signs the label without the other's

1051

signature), but it becomes quite difficult to distribute the public keys

1052

needed to verify the signature. The PICS specification does not propose a

1053

solution to this problem (it, too, is part of active commercial competition).

1054

<H3>

1055

Signature Details

1056

</H3>

1057

<OL>

1058

<LI>

1059

PICS specifically requires the use of the RSA signature algorithm with the

1060

MD5 message digest. Should this system become outdated, the PICS specification

1061

can be easily updated to add a new label option that supports a different

1062

pair of algorithms.

1063

<LI>

1064

PICS does not specify the key length to be used for the digital signatures.

1065

Individual services will need to investigate the legal and technical

1066

ramifications involved and make a choice. Should a single answer become common,

1067

this specification may be re-issued with this detail filled in.

1068

<LI>

1069

The special form of the label that is used for signatures is computed as

1070

follows:

1071

<UL>

1072

<LI>

1073

The service must decide which options it will include in the signed label

1074

when it is transmitted. Any options not transmitted with the signature cannot

1075

be used in the computation of the signature. We recommend that all

1076

options with known values be included with the exception of

1077

signature-rsa-md5. Any option may be omitted, but it will be common

1078

for the options mic-md5 (or md5) and full (or

1079

complete-label) to be omitted. The signature-rsa-md5 option

1080

is never included in the list of options.

1081

<LI>

1082

The selected options are sorted alphabetically by their shortest name (i.e.

1083

use full instead of complete-label). If a selected option has

1084

a default value and it is the same as the value to be used in the label,

1085

the option is omitted from this list.

1086

<LI>

1087

For each option in the list (in order), the short name is put into the label

1088

followed by a single space followed by the value of the option, followed

1089

by a space. The shortest form of a value is used, and strings are output

1090

in lower case if they are case insensitive.

1091

<LI>

1092

After all of the options has been output, output the characters "r (".

1093

<LI>

1094

Output the transmission names and their values, in alphabetical order by

1095

transmission name (using the US-ASCII character collating sequence for

1096

"alphabetical order"), separating the transmission name from the value by

1097

a single space. In outputting the value, no whitespace is permitted except

1098

for a single space used to separate items in a multi-value.

1099

<LI>

1100

Output a ")"

1101

</UL>

1102

<LI>

1103

When the client computes the special label format described above, it will

1104

use all options available to it: both those in the single-label

1105

and in the service-info. This implies a constraint on the server

1106

when it decides what options to include in the transmitted set. The transmitted

1107

set must include any options that the server ships as part of the

1108

service-info, unless either the value specified in the

1109

service-info or the value of the option for this label is the default

1110

value of the option.

1111

</OL>

1112

<H2>

1113

<A NAME="Glossary">Glossary</A>

1114

</H2>

1115

1116

<DT>

1117

application/pics-labels

1118

<DD>

1119

A new MIME data type used to transmit one or more labels, defined

1120

in this document.

1121

<DT>

1122

application/pics-service

1123

<DD>

1124

A new MIME data type used to describe a rating service, defined in

1125

<A href="http://w3.org/PICS/services.html">Rating Services and Rating

1126

Systems</A>.

1127

<DT>

1128

BNF

1129

<DD>

1130

Backus-Naur Form (or Backus Normal Form). A notation for describing a formal

1131

syntax, used extensively in describing programming languages and

1132

computer-readable data formats.

1133

<DT>

1134