© 2005 Jeena Paradies
The Personal Avatar (aka Pavatar) is a picture hosted on your webspace which can be used by webmasters to show it whenever they want to display an image referring to you. E.g. you make a comment or a forum posting and the implementation displays the image. This way delivering your Personal Avatar is peripheral and can be (nearly) anonymous, so there is no way for companies to collect informations about your habits on the internet.
The implementation which displays the Personal Avatars should cache them. Caching Personal Avatars saves a lot of traffic.
This is the first and unstable version, comments are welcome, please write to <pavatar@jeenaparadies.net>.
Please do not use this specification for your implementation until it is stable. There are currently two known implementation of this specification, but no formal testing has been done.
The Personal Avatar system is a way to use personalized small graphics to make commentors more recognizable through all sorts of websites where commentors leave comments. commentors are able to host their Personal Avatars themselves and the implementation should be aware that commentors should be able to decide who can download their Personal Avatar and who not. Webmasters are able to edit, cache and refuse every equal Personal Avatar.
The key words must, must not, required, shall, shall not, should, should not, recommended, may, and optional in this document are to be interpreted as described in [RFC 2119].
The implementation uses HTTP ([RFC 1945], [RFC 2616]) to check if there is a Personal Avatar on the URL which has been specified by the commentor. If so, it should download, save and serve it localy but may also refer to the original URL itself.
After a period of time the implementation should check if the Personal Avatar has changed and
upgrade it if so. The period can be specified by the commentor by the HTTP caching headers Expires
and/or Cache-Control. An implementation caching the Personal Avatars locally must
be aware of at least the Expires header.
A valid Personal Avatar must be a 80x80 pixel sized image in GIF ([GIF89a]), PNG ([PNG]) or JPEG ([ISO/IEC IS 10918-1], [ISO/IEC IS 14495-1], [ISO/IEC IS 15444-1]) format.
A valid Personal Avatar *must* be publicly accessible through a valid HTTP URL ([RFC 1738]). This URL must be used to reference to the Personal Avatar (see Autodiscovery).
The commentor must ensure that his server serves his Personal Avatar with the right
Content-Type header (e.g. with help of Apaches MultiViews).
Optionally the commentor's server may send HTTP Cache-Control and/or Expires headers.
Optionally the commentor's server may refuse delivery for non-standard and/or pushing implementations
or websites where the commentor doesn't want to appeare his Personal Avatar (e.g. by checking the remote address or
the Referer HTTP header). Therefore the server should send an HTTP 403 response header.
To completely refuse delivery of Personal Avatars the commentor may use a
robots.txt Disallow rule addressing robots
called pavatar.
There are several ways to find out where a Personal Avatar is stored, the first two are recommended:
A reference to a Personal Avatar may be returned with a X-Pavatar HTTP header, for example:
X-Pavatar: http://example.com/my/directory/my-own_pavatar.pngThe value of the X-Pavatar header must be the absolute URL of the
Personal Avatar.
The server response must not include more than one of such header. HTML and XHTML documents
may include a <link> element in addition to
an HTTP header, although this is discouraged. If included, the header should have exactly the
same value as the <link> element. In the case of a discrepancy, the HTTP header
shall override the <link> element.
An HTML or XHTML Personal Avatar enabled page may contain a
<link> element in one of the following two forms:
<link rel="pavatar" href="Personal Avatar resource"><link rel="pavatar" href="Personal Avatar resource" />If used, the link element must match the appropriate form exactly (including the whitespace before the slash, for instance).
Pages must not include more than one of such element, and must not include such a string matching the pattern described below unless it is intended to be the link element.
The Personal Avatar resource placeholder must be replaced by the absolute URL of the Personal Avatar. This URL must not include character entity references other than &, <, >, and ". In addition to this, it must not contain numeric character references. Other characters that would not be valid in the HTML document or that cannot be represented in the document's character encoding must be escaped using the %xx mechanism as described in [RFC2396].
There may be a file named pavatar (without extention like .png) on the commentors server. A implementation should consult the robots.txt file to look up if it is allowed to request one of these files. If not, there is a Disallow rule for robots called pavatar.
There are two places a Personal Avatar may be found (in case of a redirect, a implementation
should follow the redirection): speaking in terms of
[RFC 1738], a HTTP URL consists of the following
parts: "http://" hostport [ "/" hpath [ "?" search ]] while hpath ist defined
as follows: hpath = hsegment *[ "/" hsegment ]. An Implementation should do the following steps
to find the commentors Personal Avatar:
hsegmet ends with a slash: return to step 3hsegmenthsegments
Following this algorithm the EBNF expression of an valid Personal Avatar URL which should be found by trial
and error is puri = "http://" hostport *[ "/" hsegment ] "/pavatar".
The implementation should ensure to use as little traffic as possible to deal with Personal Avatars, especialy
during the comunication with the commentors website (e.g., use conditional get HTTP headers like If-Modified-Since).
Personal Avatar implementations, given a commentors website URL, should follow the following steps to find the Personal Avatar URL:
X-Pavatar headers then the first such
header's value should be used as the Personal Avatar resource. Clients must examine the HTTP
headers if they are able to. If for some reason the HTTP headers are not available to the implementation then
this step may be skipped, however, implementers should be aware that this will reduce the usefulness of their
application as link elements cannot be used for resources that are neither HTML nor XHTML, and HTTP headers
are defined to override link elements when they differ.If there is no X-Pavatar HTTP Header, search the entity body for the first match of the following
regular expression:
<link rel="pavatar" href="([^"]+)" ?/?>If the regular expression matched, clients must then expand the four allowed entities
(& for &, < for <,
> for >, and " for ").
X-Pavatar HTTP Header and no <link> could be found the implementation
should check the robots.txt
if it is allowed to request a Personal Avatar. If so, it shall check first if there
is a Personal Avatar in the commentors website directory. If not, it shall check if there
is a Personal Avatar in the commentors website document root.
If it finds a Personal Avatar the implementation should download it and save a copy.
The implementation may manipulate the cached Personal Avatar if necessary, e.g. changes in width and height, colors, etc..
The implementation should cache all Personal Avatars it wants to serve. It
should not serve it remotely. The commentor can avoid caching by specifying an Expires or
Cache-Control header referring to a date prior or equal to now.
The implementation may check regularly for changed Personal Avatars using the information given in the
Cache-Control or Expires headers. If the commentors website don't send these headers,
it is recommended to check weekly for changes.
The webmaster should not forget to check for every single Personal Avatar if it fits the law of his country. The implementation programmer should implement assistance for the webmaster.