idnits 2.17.1 draft-pics-labels-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 981 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 6 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 21, 1995) is 10376 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0-9' on line 248 -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '2') ** Obsolete normative reference: RFC 1521 (ref. '3') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 1866 (ref. '4') (Obsoleted by RFC 2854) ** Obsolete normative reference: RFC 1738 (ref. '5') (Obsoleted by RFC 4248, RFC 4266) Summary: 14 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT PICS 2 MIT/W3C 3 Expires May 21, 1996 November 21, 1995 5 Label Syntax and Communication Protocols 7 Status of this Memo 9 This document is an Internet-Draft. Internet-Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its areas, 11 and its working groups. Note that other groups may also distribute 12 working documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six 15 months and may be updated, replaced, or obsoleted by other documents 16 at any time. It is inappropriate to use Internet-Drafts as 17 reference material or to cite them other than as "work in progress." 19 To learn the current status of any Internet-Draft, please check the 20 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 21 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 22 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 23 ftp.isi.edu (US West Coast). 25 Distribution of this document is unlimited. 27 Comments on this draft should be sent to 28 "pics-spec-comments@w3.org". 30 1. Introduction 32 This document has been prepared for the technical subcommittee of 33 PICS (Platform for Internet Content Selection). It defines a 34 general format for labels that permits them to be embedded in 35 RFC-822-style headers. It defines three methods by which PICS 36 labels may be transmitted: 38 In a document 39 One or more labels may be embedded in a document. We specify the 40 format and note in particular how to use a META tag to embed 41 labels in HTML documents. 42 With a document 43 An HTTP client can request that labels be sent along with a 44 document. An HTTP server can satisfy the request, by sending the 45 labels in RFC-822-style headers. 46 Separately 47 A client can request labels from a "label bureau" that runs the 48 HTTP protocol. The labels may refer to items available through 49 protocols other than HTTP, such as ftp, gopher, or netnews. The 50 simplest implementation of a label bureau is an off-the-shelf 51 HTTP server running a special CGI script. 53 2. General Format 55 A label consists of a _service identifier_, _label options_, and a 56 _rating_. The service identifier is the URL chosen by the rating 57 service (see [1], "Rating Services and Rating Systems") as its 58 unique identifier. Label options give additional properties of the 59 document being rated as well as the rating itself, such as the time 60 the document was rated. The rating itself is a set of 61 attribute-value pairs that describe a document along one or more 62 dimensions. One or more labels may be distributed together as a 63 list. The general form for a label list (formatted for 64 presentation, and not showing error status codes) is: 66 (PICS-1.0 67 [option...] 68 labels [option...] ratings ( ...) 69 [option...] ratings ( ...) 70 ... 71 [option...] 72 labels [option...] ratings ( ...) 73 [option...] ratings ( ...) 74 ... 75 ...) 77 Label options are as follows (some options can be abbreviated, as 78 shown): 80 at _quoted-ISO-date_ 81 The last modification date of the item to which this rating 82 applies, at the time the rating was assigned. This can serve as 83 a less expensive, but less reliable, alternative to the message 84 integrity check (MIC) options. 85 by _quotedname_ 86 An identifier for the person or entity within the rating service 87 who is responsible for this particular label. 88 comment _quotedname_ 89 Information for humans who may see the label; no associated 90 semantics. 91 complete-label _quotedURL_ 92 full _quotedURL_ 93 Dereferencing this URL returns a complete label that can be used 94 in place of the current one. The complete label has values for 95 as many attributes as possible. This is used when a short label 96 is transmitted for performance purposes but additional 97 information is also available. When the URL is dereferenced it 98 returns an item of type application/pics-labels that contains a 99 labellist with exactly the one label. 100 extension (optional _quotedURL_ _data_*) 101 extension (mandatory _quotedURL_ _data_*) 102 Future extension mechanism. To avoid duplication of extension 103 names, each extension is identified by a _quotedURL_. The URL 104 can be dereferenced to get a human-readable description of the 105 extension. If the extension is *optional* then software which 106 does not understand the extension can simply ignore it; if the 107 extension is *mandatory* then software which does not understand 108 the extension should act as though no label had been supplied. 109 Each item of _data_ must be one of a fixed set of simple-to-parse 110 data types as specified in the detailed syntax below. 111 for _quotedURL_ 112 The URL of the item to which this rating applies. 113 generic _boolean_ 114 gen _boolean_ 115 This label can be applied to any URL starting with the prefix 116 given in the *for* option. This is used to supply ratings for 117 entire sites or directories. 118 MIC-md5 "_Base64-string_" 119 md5 "_Base64-string_" 120 A message integrity check (MIC) of the item being rated. The MD5 121 Message Digest Algorithm is used to compute the MIC. See [2], 122 "RFC 1321". 123 on _quoted-ISO-date_ 124 The date on which this rating was issued. 125 signature-PKCS "_Base64-string_" 126 An RSA digital signature encompassing the label as transmitted, 127 signed by the rating service that issued the label. See section 128 14, "MICs and Digital Signatures". 129 until _quoted-ISO-date_ 130 exp _quoted-ISO-date_ 131 The date on which this rating expires. 133 3. Example 135 For example, a label that uses the example rating system from the 136 document [1] "Rating Services and Rating Systems" might be as 137 follows: 139 (PICS-1.0 "http://www.gcf.org" 140 labels on "1994.11.05T08:15-0500" 141 until "1995.12.31T23:59-0000" 142 for "http://www.gcf.org/index.html" 143 by "John Patrick" 144 ratings (suds 0.5 density 0 color/hue 1)) 146 The same label may be transmitted more compactly by converting all 147 of the line breaks and subsequent indentation characters into a 148 single space, and by replacing the word "labels" with "l", "ratings" 149 with "r" and long option names with their abbreviations. It may be 150 compressed for transmission purposes even further by removing all of 151 the optional information to a separate document and referencing that 152 document by a URL: 154 (PICS-1.0 "http://www.gcf.org" l 155 full "http://www.gcf.org/labels/13242123" 156 r (suds 0.5 density 0 color/hue 1)) 158 Finally, the optional information may be omitted entirely, reducing 159 the information content of the label but making the transmission 160 even smaller. The resulting label would then be: 162 (PICS-1.0 "http://www.gcf.org" l r (suds 0.5 density 0 color/hue 1)) 164 4. Detailed Syntax 166 The following grammar, in modified BNF, describes the syntax of 167 labels. The methods by which labels are embedded in specific 168 protocols are detailed below. 170 Notes: 172 1. Whitespace is ignored except in quoted strings. 173 2. The string in a _transmit-name_ is case insensitive. All 174 other strings are case sensitive. 175 3. Option names ("on", "until", "at", etc.) are case insensitive. 176 4. This specification requires the use of US-ASCII. Note that 177 the document [1] "Rating Services and Rating Systems" 178 describes how a service can map the US-ASCII transmit-names to 179 descriptive strings using other character sets. 180 5. An option that appears in the _service-info_ applies to all 181 labels in that _service-info_ unless overridden by an option 182 in a specific _label_. That is, a _label_ is effectively 183 lexically nested within the enclosing _service-info_ for the 184 purpose of understanding the applicable options. This is most 185 likely to be useful in the case of the "at", "by", "generic", 186 "until" and experimental or future options. 187 6. Numbers in PICS labels may be integers or fractions with no 188 greater range or precision than that provided by IEEE 189 single-precision floating point numbers. 190 7. The _multi-value_ syntax *must* be used when the value on a 191 particular (multi-valued) scale has either zero or more than 192 one value. It *may* be used for a single-valued or 193 multi-valued field when there is exactly one value, but the 194 more compact version may also be used in that case. 195 8. The only options that may occur more than once in a single 196 label are "comment" and "extension"; if the "extension" 197 option is supplied more than once, the _quotedURL_s defining 198 the extensions must be distinct. 200 labellist :: '(' 'PICS-1.0' _service-info_+ ')' 201 service-info :: 'error' '(no-ratings' _explanation_* ')' 202 | _serviceID_ _service-error_ 203 | _serviceID_ _option_* _labelword_ _label_* 204 serviceID :: _quotedURL_ 205 labelword :: 'labels' | 'l' 206 label :: _label-error_ | _single-label_ | '(' _single-label_* ')' 207 single-label :: _option_* _ratingword_ '(' _rating_+ ')' 208 ratingword :: 'ratings' | 'r' 209 quotedURL :: '"' _URL_ '"' as described and extended in [1] "Rating 210 Services and Rating Systems. 211 option :: 'at' _quoted-ISO-date_ 212 | 'by' _quotedname_ 213 | 'comment' _quotedname_ 214 | 'complete-label' _quotedURL_ | 'full' _quotedURL_ 215 | 'extension' '(' _mand/opt_ _quotedURL_ _data_* ')' 216 | 'generic' _boolean_ | 'gen' _boolean_ 217 | 'for' _quotedURL_ 218 | 'MIC-md5' "_base64-string_" | 'md5' "_base64-string_" 219 | 'on' _quoted-ISO-date_ 220 | 'signature-PKCS' "_base64-string_" 221 | 'until' _quoted-ISO-date_ | 'exp' _quoted-ISO-date_ 222 mand/opt :: 'optional' | 'mandatory' 223 data :: _quoted-ISO-date_ | _quotedURL_ | _number_ | _quotedname_ 224 | '(' _data_* ')' 225 quoted-ISO-date :: '"'YYYY'.'MM'.'DD'T'hh':'mmStz'"' 226 based on the ISO 8601:1988 date and time standard, restricted 227 to the specific form described here: 228 YYYY :: four-digit year 229 MM :: two-digit month (01=January, etc.) 230 DD :: two-digit day of month (01 through 31) 231 hh :: two digits of hour (00 through 23) (am/pm NOT allowed) 232 mm :: two digits of minute (00 through 59) 233 S :: sign of time zone offset from UTC ('+' or '-') 234 tz :: four digit amount of offset from UTC 235 (e.g., 1512 means 15 hours and 12 minutes) 236 For example, "1994.11.05T08:15-0500" is a valid _quoted-ISO-date_ 237 denoting November 5, 1994, 8:15 am, US Eastern Standard Time. 238 Note: The ISO standard allows considerably greater flexibility 239 than that described here. PICS requires *precisely* the syntax 240 described here -- neither the time nor the time zone may be 241 omitted, none of the alternate formats are permitted, and the 242 punctuation must be as specified here. 243 rating :: _transmit-name_ _number_ | _transmit-name_ '(' _multi-value_* ')' 244 multi-value :: _number_ | _number_ ':' _number_ 245 transmit-name :: [1*n]_alphanumpm_ ['/' _transmit-name_] 246 number :: [_sign_]_unsignedint_['.' [_unsignedint_]] 247 sign :: '+' | '-' 248 unsignedint :: [1*n][0-9] 249 quotedname :: ' " ' [1*n]_extendedalphanum_ ' " ' 250 alphanumpm :: 'A' | ... | 'Z' | 'a' | ... | 'z' | '+' | '-' 251 extendedalphanum :: _alphanumpm_ | '.' | ' ' | ',' | ';' | ':' 252 | '&' | '=' | '?' | '!' | '*' | '~' | '@' | '#' 253 base64-string :: as defined in [3] "RFC 1521". 254 service-error :: 'error' '(' 'request-denied' _explanation_* ')' 255 | 'error' 'service-unavailable' 256 label-error :: 'error' '(' request-denied' [_quotedURL_ 257 _explanation_*] ')' 258 | 'error' '(' not-labeled' _quotedURL_* ')' 259 explanation :: _quotedname_ 261 5. Semantics of PICS Labels and Label Lists 263 A _labellist_ is used to transmit a set of PICS labels. The format 264 specified here is intended to be registered with IANA as the MIME 265 type "application/pics-labels." It allows for transmission of both 266 labels and reasons why labels are not available, and is the format 267 used when labels must be conveyed in a document, along with a 268 document, or from a PICS label bureau. The _labellist_ will always 269 be surrounded by parentheses and begin with the PICS version number 270 (1.0 in this specification). 272 A label list either specifies that there are no labels available at 273 all ("error (no-ratings ...)") or is separated into sections of 274 labels, one section for each rating service. The URL of each 275 service must be specified (the _serviceID_). This is either 276 followed by an error message indicating why no labels are available 277 from that service (_service-error_) or an overall set of optional 278 information (_option_*) followed by the keyword "labels" (or "l") 279 and the _label_s from the service. The optional information 280 provided here applies to every label from the service, unless 281 overridden in the specific label itself. 283 A _label_ encompasses three separate cases. The first is an error 284 that applies to retrieving the label for a particular URL 285 (_label-error_). The second, and most common, is a _single-label_ 286 consisting of options (which override those specified with the 287 service), the marker word "ratings" (or "r") and the ratings 288 themselves (a list of category names and values). Finally, in the 289 special case where the ratings for an entire tree of documents have 290 been requested, any number of _single-label_s can be transmitted, 291 enclosed in parentheses. This case is described in more detail in 292 the section on "Requesting Labels Separately". 294 A label may apply to a specific URL, or it may be generic. A 295 generic label implicitly rates every URL for which the specified one 296 is a prefix. For example, a generic label for the URL 297 "http://www.gcf.org" implicitly rates every document available at 298 that site. A regular (non-generic) label for the same URL, 299 "http://www.gcf.org", does not give any implicit ratings: it merely 300 rates the organization's home page that is fetched by the command 301 "GET / " sent by HTTP to the host "www.gcf.org". A generic label 302 *must* include the "for" option specifying the URL to which it 303 applies. 305 When a _multi-value_ is provided, any combination of numbers and 306 ranges of numbers may be specified, with the endpoints of a range 307 separated by a ":". Thus, in the labellist 309 (PICS-1.0 "http://www.gcf.org" l 310 r (suds 0.5 density 0 color/hue 1 subject (0.5:2.5 3))) 312 all subject values between 0.5 and 2.5 (including both endpoints) 313 apply to the item, as does the subject value 3. Given the example 314 service description in [1], Rating Services and Rating Systems", all 315 three document subjects apply, "soap", "water", and "soapdish". 317 6. RFC 822 Headers 319 Many protocols, such as Internet electronic mail, the HyperText 320 Transfer Protocol, and USENET News, use ASCII headers as described 321 in RFC 822. For use in such protocols, we define a new header, 322 PICS-Label, used to contain the labels described in this document. 323 The syntax is: 325 PICS-Label: 327 where _labellist_ is described according to the syntax above. 328 Continuation lines beginning with whitespace may be used following 329 the specification given in RFC 822. 331 7. Embedding Labels in HyperText Markup Language (HTML) 333 Labels may be embedded in HTML files as meta-information, using the 334 META element defined in the HTML specification. This embedding uses 335 the HTTP header equivalency mechanism: 337 339 (Note that the content attribute uses single quotes, because the 340 PICS label syntax uses double quotes. Any of the following 341 characters appearing within the content must be escaped using SGML 342 entities: 344 ' ' /* single quote */ 345 & & /* ampersand */ 346 > > /* greater than */ 348 See [4], the "HTML 2.0 Proposed Standard". 350 8. Sending Labels With A Document 352 When an HTTP server sends a document to a client, it sends 353 additional headers as well. We specify how the client can request 354 that one or more labels be included in a header. HTTP servers 355 should include PICS label headers only if requested to do so by the 356 client, and should only include the labels from services requested 357 by the client. 359 Example: 361 Client sends to HTTP server www.greatdocs.com: 363 GET foo.html HTTP/1.0 364 Accept-Protocol: 365 {PICS-1.0 {params full 366 {services "http://www.gcf.org/ratings"}}} 368 Server responds to client: 370 HTTP/1.0 200 OK 371 Date: Thursday, 30-Jun-95 17:51:47 GMT 372 MIME-version: 1.0 373 Last-modified: Thursday, 29-Jun-95 17:51:47 GMT 374 Protocol: {PICS-1.0 {headers PICS-Label}} 375 PICS-Label: 376 (PICS-1.0 "http://www.gcf.org" labels 377 on "1994.11.05T08:15-0500" 378 exp "1995.12.31T23:59-0000" 379 for "http://www.gcf.org/index.html" 380 by "George Sanderson, Jr." 381 ratings (suds 0.5 density 0 color/hue 1)) 382 Content-type: text/html 383 ...contents of foo.html... 385 Explanation of example: 387 The client requests the document foo.html. In addition, the client 388 requests the full label of the document from the rating service 389 "http://www.gcf.org/ratings". The server responds by sending back 390 the label, in the PICS-Label header, as well as the document. The 391 format of the PICS-Label header field (a _labellist_) allows the 392 server to respond either with a label or an explanation of why the 393 label is not available, since it would be inappropriate for the 394 server to generate an HTTP error status if the document is available 395 but (some of) the labels are not. 397 Following the usual HTTP distinction between HEAD and GET, a client 398 that wishes to examine a rating before retrieving the full document 399 can substitute the word HEAD for GET in the request. The server 400 responds with exactly the headers shown above, but does not send 401 back the document "foo.html". 403 9. Detailed Syntax of HTTP Requests for Labels With Document 405 The following grammar, in modified BNF, describes the syntax of the 406 additional header line to be included in an HTTP request for a 407 document and associated labels. 409 accept-header :: 410 'Accept-Protocol: {PICS-1.0 {params ' [_completeness_] 411 _extension_* _services_ '}}' 412 completeness :: 'minimal' | 'short' | 'full' | 'signed' 413 extension :: '{' _token-or-quoted-string_+ '}' 414 where the first _token-or-quoted-string_ is not 'services'. 415 token-or-quoted-string :: _token_ | _quotedname_ 416 token :: [1*n]_alphanumpm_ 417 services :: '{' 'services' _quotedURL_+ '}' 419 A request for a *minimal* label asks that all options be omitted, 420 unless a generic label is returned, in which case the "generic" and 421 "for" options must also be included in the label. A *short* label 422 includes everything that is included in a minimal label, plus 423 additional options that the server deems appropriate. A request for 424 a *full* label asks that as much information as possible should be 425 sent back in the label, either directly or through the use of a 426 "complete-label" (or "full") option, but no "signature-PKCS" option 427 is needed. 429 A request for *signed* labels asks that all the information in a 430 "full" label should be sent, along with a digital signature on the 431 label itself. In a signed label the information must be transmitted 432 directly as part of the label (and included in the computation of 433 the signature); the "complete-label" (or "full") option may be sent, 434 but it would be redundant. Details of signing labels are included 435 in section 14, "MICs and Digital Signatures". 437 It is acceptable for a server to ignore the _completeness_, either 438 by delivering more or fewer options than requested. If the 439 _completeness_ is omitted, it should be treated as though "minimal" 440 had been supplied. For future extensibility, any alphanumeric 441 string may be used for a value of the _completeness_ option. 442 Servers which receive a value of _completeness_ that they do not 443 recognize must treat it as though "minimal" had been specified. 445 The _extension_s are for future extensions to the protocol; any 446 extensions which are not understood by the server must be ignored by 447 it. It is recommended that experimental extensions use a URL, which 448 dereferences to a description of the extension, as the initial 449 _token-or-quoted-string_. 451 Each _service_ specifies a rating service from which the client is 452 requesting a label for the document. There may be as many 453 repetitions of the _service_ part of the query as desired. 455 10. Detailed Syntax For HTTP Response Headers for Labels With Document 457 Two additional headers are specified: 459 protocol-header :: 'Protocol: {PICS-1.0 {headers PICS-Label}}' 460 label-header :: 'PICS-Label: ' _labellist_ 462 11. Requesting Labels Separately 464 PICS labels can also be retrieved separately from the documents to 465 which they refer. To request labels in this way, a client contacts 466 a *label bureau*. A label bureau is an HTTP server that understands 467 a particular query syntax, defined below. It can provide labels for 468 documents that reside on other servers, and, indeed, for documents 469 available through protocols other than HTTP. It is anticipated that 470 there will be "well-known" label bureaus which dispense (possibly 471 for a fee) labels created by many rating services. 473 Rating services are also encouraged to act as label bureaus, 474 providing on-line access to their own labels. By default, the URL 475 that identifies a rating service also identifies its label bureau. 476 If a client requests the URL that identifies a rating service, a 477 human-readable description of the service is returned, as specified 478 in [1], "Rating Services and Rating Systems". If, on the other 479 hand, a client requests the same URL and includes query parameters 480 as defined below, it should be interpreted as a request for labels. 481 A rating service, however, is not required to act as a label bureau, 482 and it may choose a different URL (perhaps even on a different HTTP 483 server) to act as its label bureau. 485 Sample Query: 487 Imagine a rating service, identified by the URL 488 "http://www.labels.org/Ratings", which decides to run a label bureau 489 to dispense (at least) its own labels for documents. The following 490 sample request, made to the HTTP server "www.labels.org", is 491 illustrative (line breaks are inserted for presentation purposes 492 only): 494 GET /Ratings?opt=generic& 495 u="http%3A%2F%2Fwww.questionable.org%2Fimages"& 496 s="http%3A%2F%2Fwww.gcf.org%2Fratings"& 497 HTTP/1.0 499 The query asks the label bureau "http://www.labels.org/Ratings" to 500 send a single label that applies to everything in the images 501 directory at site "www.questionable.org". The desired label should 502 have been created by the service "http://www.gcf.org/ratings". 503 Notice the use of %3A to represent a ":" and %2F for "/". This is 504 required for encoding characters within a URL. See [5], "RFC 1738". 506 The label bureau responds by sending back a document of type 507 "application/pics-labels." The labels should be as complete as 508 possible, either by including as many options as possible or by 509 supplying the "complete-label" (or "full") option. 511 12. Detailed Syntax and Semantics of HTTP Query for Labels Separate 512 From Documents 514 The following grammar, in modified BNF, describes the syntax of the 515 GET request to a label bureau: 517 get :: 'get' _url-fragment_ '?' [_opt_] [_format_] _extension_* 518 _url_+ _service_+ 519 url-fragment :: the part of the original URL after the host name, as 520 specified in HTTP 1.0. 521 opt :: 'opt=' _option_ 522 option :: 'generic' | 'normal' | 'tree' | 'generic+tree' 523 format :: [and] 'format=' _form_ 524 form :: 'minimal' | 'short' | 'full' | 'signed' 525 extension :: _token_ '=' _token-or-quoted-string_ 526 where the _token_ is not one of "opt", "format", "u", or "s"; and 527 _token-or-quoted-string_ follows the quoting conventions 528 specified in [5], "RFC 1738". 529 token-or-quoted-string :: _token_ | _quotedname_ 530 token :: [1*n]_alphanumpm_ 531 url :: [and] 'u=' encodedURL 532 service :: [and] 's=' encodedURL 533 boolean :: 't' | 'f' | 'true' | 'false' 534 and :: '&' this must be included unless it immediately follows the ? 535 in the query. 536 encodedURL :: a URL, with quotation as required for inclusion within 537 another URL. According to [5], "RFC 1738", quotation is done using 538 "%xx" notation. Alphabetic characters, digits, and the special 539 characters $_-.+!*'(), need not be quoted, but other characters must 540 be. This *does* imply that the colon (:) must be encoded as %3A and 541 slash (/) as %2F. 543 Notes: 545 1. "opt=generic" requests generic labels. For each requested 546 URL, the desired response is a generic label that implicitly 547 applies to all URLs matching it. This is useful for 548 requesting a rating of a site or directory. 549 2. "opt=tree" requests a tree of labels. For each requested 550 URL, the desired response is all labels for URLS that match 551 it. This is a way to request all the labels for items in a 552 directory or a site. In the response, everywhere a _label_ 553 would normally be expected in the response, a set of 554 _simple-label_s will be returned, surrounded by parentheses. 555 3. "opt=generic+tree" requests all generic labels that apply to 556 matching URLs. This is a way to request generic labels for 557 all of the directories at a site. In the response, 558 everywhere a _label_ would normally be expected in the 559 response, a set of _simple-label_s will be returned, 560 surrounded by parentheses. 561 4. "opt=normal", or omitting the "opt" completely, requests 562 specific labels for the URLs specified. 563 5. It is permitted to include more than one URL in the request. 564 6. The "format=" specifies the optional information that should 565 be transmitted with the labels. It is treated precisely as 566 the similar keywords would be when sent to a document server 567 as the "completeness" (see section 9), except that the 568 default is "full" (rather than "minimal"). Servers which 569 receive a value of "completeness" that they do not recognize 570 must treat it as though the default, "full" had been 571 specified. 573 13. Detailed Syntax and Semantics of Response to Query for Labels 574 Separate From Documents 576 The label bureau responds by sending back a document of type 577 "application/pics-labels". Unless the document indicates an overall 578 error, there should be one _service-info_ for each rating service 579 requested in the query. Each _service-info_ should have an error 580 message or a label (or list of labels, in the case of a "tree" 581 query) for each requested URL. 583 The query's ordering must be preserved in the response. That is, the 584 information from the rating services must be presented in the same 585 order the rating services appear in the query, and the labels from 586 each service must be presented in the same order the URLs appear in 587 the query. If a rating service or label is not provided, the error 588 message should appear in the same position that the _service-info_ 589 or label would appear. Because order is preserved, it is acceptable 590 to omit from the labels the "for" option which indicates the URL 591 being rated (*unless* the label is "generic" in which case, as 592 always for generic labels, the "for" is required). The client 593 should match the label positionally with the URL for which it 594 requested a rating. 596 In response to a request for a generic label, only a generic label 597 may be returned. In response to a request for a regular label, a 598 generic label for a URL that is a prefix of the requested URL may be 599 returned. For example, in response to a label request for URL 600 "http://www.gcf.org/index.html" a generic label for the URL 601 "http://www.gcf.org" may be returned. In this case, it is required 602 that the "for" and "generic" options be included in the label, to 603 specify exactly what rating is being returned. 605 For a tree request, all the labels sent in response to a particular 606 URL are enclosed in parentheses, so the client can match them 607 positionally with the single request URL. The "for" option must be 608 included in such labels to specify exactly which URLs the labels 609 apply to. 611 14. MICs and Digital Signatures 613 This section remains to be specified. There are three particular 614 difficulties that must be addressed: 616 1. On what data is the MIC included in the _mic-md5_ (or 617 _md5_) option computed? In particular, if the URL 618 "ftp://www.somewhere.com/Pictures/Interesting/Look.gif" 619 refers to a compressed GIF image, is the MIC computed on the 620 compressed or uncompressed form? Does it depend on the 621 content-transfer-encoding? The MIME type? 622 2. How is the label canonicalized before computing the digital 623 signature? Because header lines can be folded by various 624 transports, it is important that a canonical form be 625 carefully defined. Clearly, it should not include the 626 signature itself, but does it include all of the other 627 optional fields? Does a signed label necessarily imply a 628 full label (hence the distinction should be dropped)? 629 3. How are the public keys for rating services distributed? Can 630 it be done using a variant on the same technique used for 631 communicating with a label bureau or is a full certificate 632 authority required? What authority should be used or can 633 multiple be used? Is the service's URL a satisfactory 634 distinguished name for use with a certificate authority? 636 15. Security Considerations 638 Security considerations will be addressed in future revisions of 639 this draft. 641 16. Glossary 643 application/pics-service 644 A new MIME data type used to describe a _rating service_, 645 defined in [1], "Rating Services and Rating Systems". 646 application/pics-labels 647 A new MIME data type used to transmit one or more _labels_, 648 defined in this document. 649 BNF 650 Backus-Naur Form (or Backus Normal Form). A notation for 651 describing a formal syntax, used extensively in describing 652 programming languages and computer-readable data formats. 653 category 654 The part of a rating system which describes a particular 655 criterion used for rating. For example, a rating system might 656 have three categories named "sexual material," "violence," and 657 "vocabulary." Also called a _dimension_. 658 content label 659 A data structure containing information about a given document's 660 contents. Also called a _rating_ or _content rating_. The 661 content label may accompany the document it is about or be 662 available separately. 663 content rating 664 See _content label_. 665 dimension 666 See _category_. 667 HTML 668 HyperText Markup Language. A means of representing _hypertext_ 669 documents. Based on _SGML_. See [4], the "HTML 2.0 Proposed 670 Standard". 671 HTTP 672 HyperText Transfer Protocol. Used for retrieving document 673 contents and/or descriptive header information. 674 hypertext 675 Text, graphics, and other media connected through links. 676 label 677 See _content label_. 678 MD5 679 An algorithm, see [2], "RFC 1321", that can be used to compute a 680 MIC. PICS specifies this particular algorithm for use in PICS 681 labels. 682 MIC 683 Message Integrity Check. Also known as a "cryptographic 684 checksum." For PICS, the importance of a MIC is that a rating 685 service can compute the MIC of a piece of information when the 686 label is created and that MIC can be put into the label itself. 687 A client can retrieve the label and the information to which it 688 is supposed to be attached, recompute the MIC and compare it to 689 the one in the label. If they match, for all practical purposes, 690 it is a proof that the label really belongs to the information 691 that has been retrieved. The particular algorithm specified by 692 PICS to compute the MIC is MD5. 693 MIME 694 Multimedia Internet Message Extension. A technique for sending 695 arbitrary data through electronic mail on the Internet. See [3], 696 "RFC 1521". 697 PICS 698 Platform for Internet Content Selection, the name for both the 699 suite of specification documents of which this is a part, and for 700 the organization writing the documents. For more information, 701 see the PICS home page on the World Wide Web at: 702 "http://www.w3.org/PICS". 703 rating 704 See _content label_. 705 label bureau 706 A computer system which supplies, via a computer network, ratings 707 of documents. It may or may not provide the documents 708 themselves. 709 rating server 710 See _label bureau_. 711 rating service 712 An individual or organization that assigns labels according to 713 some rating system, and then distributes them, perhaps via a 714 label bureau or via CD-ROM. 715 rating system 716 A method for rating information. A rating system consists of one 717 or more _categories_. 718 scale 719 The range of permissible values for a category. 720 SGML 721 Standard Generalized Markup Language. See ISO 8879. 722 transmission name 723 (of a _category_) The short name intended for use over a 724 network to refer to the category. This is distinct from the 725 category name in as much as the transmission name must be 726 language-independent, encoded in ASCII, and as short as 727 reasonably possible. Within a single _rating system_ the 728 transmission names of all categories must be distinct. 729 URL 730 Uniform Resource Locator. Described in [5], "RFC 1738". A URL 731 describes the location and means of retrieval for a single 732 document. It consists of three components: the "scheme" 733 (protocol used to retrieve a document, like "http" or "ftp"), a 734 host name, and a hierarchical document name within that host. 735 For example "http://www.w3.org/PICS" is the URL of the PICS home 736 page. The scheme for retrieving it is "http," the host is 737 "www.w3.org" and the name within that host is "PICS". 739 17. References 741 [1] PICS, "Rating Services and Rating Systems", Internet Draft, 742 "draft-pics-services-00.txt", 11/21/95. 743 [2] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, 744 04/16/1992. 745 [3] N. Borenstein, N. Freed, "MIME (Multipurpose Internet Mail 746 Extensions) Part One: Mechanisms for Specifying and Describing 747 the Format of Internet Message Bodies", RFC 1521, 09/23/1993. 748 [4] T. Berners-Lee, D. Connolly, "Hypertext Markup Language - 2.0", 749 RFC 1866, 11/03/1995. 750 [5] T. Berners-Lee, L. Masinter, M. McCahill, "Uniform Resource 751 Locators (URLs)", RFC 1738, 12/20/94. 753 18. Acknowledgments 755 Primary authors of this document: 757 Tim Krauskopf, Spyglass 758 Jim Miller, W3C 759 Paul Resnick, AT&T 760 G. Winfield Treese, OpenMarket 762 Additional contributors: 764 Brenda Baker, AT&T 765 Tim Berners-Lee, W3C 766 Roxana Bradescu, AT&T 767 Daniel W. Connolly, W3C 768 Roy Fielding, W3C 769 Jay Friedland, SurfWatch 770 Michael Gordon, Prodigy 771 Wayne Gramlich, Sun 772 Woodson Hobbs, NewView 773 Rohit Khare, W3C 774 Charlie Kim, Apple 775 John C. Klensin, MCI 776 Ann McCurdy, Microsoft 777 Rich Petke, CompuServe 778 Dave Raggett, W3C 779 Bob Schloss, IBM 780 David Singer, IBM 781 Michael Smith, Prodigy 782 Marcy Swenson, Providence Systems 783 Jason Thomas, MIT 785 19. Author's Address 787 PICS Technical Committee 788 World Wide Web Consortium 789 545 Technology Square 790 Cambridge, MA 02139 791 Phone: 617-253-3194 792 EMail: pics-spec-comments@w3.org 794 Temporary Appendix A: Why HTTP For Label Bureaus 796 This section is not expected to be contained in future versions of 797 this document. 799 Instead of extending HTTP, we considered proposals for 800 special-purpose label transport protocols. Before making a final 801 decision, we constructed the following lists of pros and cons. 803 Advantages of Using HTTP 805 o An existing HTTP server can be used as a PICS label bureau. This 806 is particularly useful in the short term. CGI scripts at the 807 HTTP server can handle the special header fields of a request for 808 labels. 809 o A label returned from a label bureau and a label returned along 810 with a document from an HTTP server can use identical label 811 formats. 812 o Client programs that already support HTTP will have much less new 813 code to implement. 814 o Client programs that do not support HTTP will have to support a 815 new protocol in any case. It may be easier to support HTTP than 816 a newly defined label transport protocol, because of available 817 software libraries. 818 o Several protocol elements are already fully specified by HTTP 819 that would be required in any PICS protocol. 821 o Date and time formats. 822 o Content encoding types. 823 o Character set and Internationalization issues. 824 o Error/result conditions. Both result categories (extensible), 825 as well as a sample set of messages are specified. 826 o Handling of expiration dates for each URL queried. 828 o HTTP is quite stable, has not diverged, and is well accepted. 829 o Security and payment systems either exist or are being developed 830 for HTTP. A binary format may also be developed for speed. PICS 831 need not reinvent such systems. 832 o Firewalls tend to allow HTTP headers to be transmitted already. 833 A new protocol would take much longer to be accepted. 834 o A reliable connection (initially TCP based), ASCII-based protocol 835 seems desirable initially. 836 o Current extensibility already defines how extensions to PICS 837 itself should be accomplished. 839 Advantages of Creating a New Protocol Instead of Using HTTP 841 o A new protocol would avoid any HTTP protocol wars. 842 o Label bureaus and clients would not need to be updated to 843 accommodate HTTP changes. 844 o RFC 822 and other precedents could still be used in the design of 845 a new protocol. 846 o A binary format could be considered initially for speed. 847 o UDP or other datagram lookups could be considered. 849 Temporary Appendix B: FAQ - Frequently Asked Questions 851 This section is not expected to be contained in future versions of 852 this document. 854 Why is there no ftp, gopher, or netnews protocol for requesting 855 labels along with a document? 857 Labels can be sent as additional headers in any protocol that 858 employs RFC 822 style headers. We have not yet determined, 859 however, convenient extensions to protocols other than HTTP to 860 permit requests that ask for labels created by specific services. 861 We may specify such extensions in the future. 863 How do you get labels for items on FTP, Gopher, or netnews servers? 864 Are we forcing all FTP implementations to implement all of HTTP as 865 well? 867 FTP, Gopher, and netnews servers need not distribute PICS labels. 868 Labels for items on such servers can be retrieved from an 869 HTTP-based label bureau. 871 The PICS premise is that all compliant clients will have to 872 implement some new protocol. The subset of HTTP which would be 873 required for obtaining a PICS label can be minimal. HTTP will be 874 no more difficult to implement in an FTP (or other) client than a 875 brand-new protocol that provides similar features. 877 Can existing HTTP servers be used as PICS label bureaus? 879 Using CGI scripts, or with a small amount of added code in the 880 HTTP server, an existing HTTP server can be configured to access 881 a database of labels and return that information coded as 882 additional HTTP Headers. Most of the work is in the lookup and 883 formatting of the labels themselves, not the modifications to 884 HTTP. 886 How do I design a really fast PICS label bureau? Won't the overhead 887 be too much? 889 HTTP already explicitly defines the minimum fields required and 890 then what rules must be followed when additional information is 891 useful to the transaction. For example, HTTP does not require 892 that clients provide "Accept:" headers to indicate preferred MIME 893 types for the content, but if they are provided, servers can 894 match up available formats with the client's request. An HTTP 895 server may be designed to optimize throughput or to optimize the 896 appearance of the result, or to adjust to the client software's 897 preference. 899 If you minimize the server's response to one line, plus the label 900 information, you are already dealing with the minimum amount of 901 data transfer possible to obtain a label. In addition, most 902 performance issues for PICS will probably be addressed with 903 caching, not by reducing lookup time for a single label. Caching 904 optimization requires meta-data which can be easily encoded 905 within HTTP headers. 907 How can we keep the PICS extensions from getting tied up in HTTP 908 standardization? 910 The management of header extensions for HTTP has been an issue of 911 discussion and work by the HTTP group for some time. The HTTP 912 specification lays down specific rules for the handling of 913 extensions which guarantee that those extensions will not be made 914 invalid by any revisions of HTTP itself. In addition, the W3C is 915 working on a system (PEP) for managing and negotiating HTTP 916 extensions even more intelligently. 918 The worst risk seems to be that HTTP could be upgraded to a new 919 revision level forcing some HTTP implementations to support 920 multiple versions (1.0 and 2.0, for example) or forcing some PICS 921 bureaus to update their protocol as well. Hopefully a major 922 update in HTTP would bring enough benefits for PICS to make any 923 update worthwhile. 925 What is PEP and Why is PICS Using It? 927 The Protocol Extension Proposal from the World Wide Web 928 Consortium uses a trio of header fields (Protocol, 929 Accept-Protocol, and Content-Encoding) to allow a HTTP client and 930 server to do sophisticated negotiation about the set of header 931 fields and their meanings. It is being proposed for use in HTTP 932 1.2 and HTTP-ng, and is currently under careful scrutiny by the 933 W3C Security Editorial Board to make sure that it contains the 934 features necessary to provide security for general document 935 transmission as well as electronic payments. 937 PICS faces many of the same problems that face the security and 938 electronic payment community. In PICS the issue revolves around 939 the ability for the client to tell the server from which rating 940 services it would like to have labels. This is a simple 941 negotiation problem of the kind PEP was designed to solve. 942 Rather than invent an orthogonal mechanism it seemed best to use 943 one that is already being proposed and investigated. 945 What if PEP Does Not Catch On? 947 If the general extension mechanism specified by PEP does not 948 become a generic feature of HTTP servers, PICS label bureaus will 949 need to look for the specific header line beginning 950 Accept-Protocol: PICS/1.0 and process it to determine the rating 951 request. PICS clients will need to look for and process the 952 specific header lines PICS-Label and PICS-Status. We will also 953 have to hope that no other group tries to extend HTTP in a way 954 that uses headers named PICS-Label or PICS-Status. 956 This Internet Draft Expires on May 21, 1996