© 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 commenters more recognizable through all sorts of websites commenters leave comments. Commenters are able to host their Personal Avatars themselves and the implementation should be aware that commenters 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 URI which has been specified by the commentor. If so, it should download, save and serve it localy but may also refer to the original URI 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.
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 the commentor doesn't want to appeare his Personal Avatar (e.g. by checking the remote address or
the Referer HTTP header). Therefore he should send an HTTP 403 response header.
To completely refuse delivery of Personal Avatars the commentor may use a
robots.txt Disallow rule on robots
called pavatar.
There are several ways to find out where a Personal Avatar is stored, the first two are recommended:
Personal Avatars 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 URI of the
Personal Avatar.
Pages must not include more than one 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 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 URI of the Personal Avatar. This URI must not include entities other than &, <, >, and ". 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].
The may be a file named pavatar (without extention like .png) on the commentors server. A implementation should consult the robots.txt file to lookup if it is allowed to request one of this files. If not, there is a disallowed 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 pavatar:
hsegmet ends with a slash: return to step 3hsegmenthsegments
Following this algorithm the EBNF expression of an valid Personal Avatar URI 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 URI, 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 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 Pavatar 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 remotly. 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 Pavatars using the information given in the
Cache-Control or Expires headers. If the commenters 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.