IV. Profile Request Protocol
Protocol Extension for Operator Profile Logging and Exchange?
This is seen as an HTTP extension protocol using the
PEP (protocol extension protocol) mechanism.
The sequence proposed is:
- The server rejects a request which has insufficient profile information
with a reject code and a PEP header explaining that a certain
profile scheme is required. The profile scheme is identified by a URL.
- The client will indicate this (typically with a dialog box)
giving the user the option of cancelling, or filling in the details.
- If the user proceeds, the client fetches a description of the
profile scheme. This will typically be either as an HTML form, or as
a PICS-style rating scheme description. (Hopefully the capabilities of the
two will be merged). In either case, the profile scheme
contains not only a list of the information required but also a
statement of the undertakings by the server as to the privacy treatment of the
- The user fills in the form.
- The result is a profile containing the contents of the form.
This profile is kept by the client. It has a name,
perhaps a default
derived from the name of the profile scheme, or one chosen by the
user. The client stores this information, and gives it an identifier.
- The client re-issues the request, giving a user-profile:
header with the URL of the profile as stored on the client.
- The server retrieves the profile using either an HTTP call-back,
for which a URL scheme would be required, or by a request to an HTTP
server port which the client holds open for this.
V. Access reporting protocol
This proposal addresses the problem of high fan-out proxies
which currently block demographic information.
The sequence is as follows.
- The server makes a demand for a profile as above. The PEP line indicates
that a proxy should pass the PEP request on or understand it but
not remove it.
- Conforming to the extension protocol,
the proxy adds a line to each request indicating that profile
logging is available.
- The server, seeing that line on the request, send back with the data
a "mandatory" record indicating
- The profile scheme required, if any, and other information such
as time/date, and other HTTP fields;
- The URL to which logs should be posted
- Times at which posting is preferred
- The proxy does the protocol above locally with the client in
order to acquire the necessary profile information before releasing the
requested object to the client
- The proxy spools the log information requested by the server
in a serial file for posting to the URL requested.
- At a suitable time, as a function of spool size, server and
proxy preference, the proxy independently accesses the server and performs
an HTTP "POST" of the log file to the URL given.
A proxy must be allowed to write back a log file at any time,
to protect itself from storage overflow.
It may be necessary to define norms
for storage space for proxies.
Created October 1995
Last updated 06 Nov 1995