© 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 to ensecure a permanent reachability.
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 the keyword
none (and nothing else) instead of the Personal Avatar URL in the header (e.g.
X-Pavatar: none) and/or the href attribute of the <link> element.
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 or the keyword none, if all Personal Avatar requests should be refused.
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
(and not a relative URL) of the Personal Avatar or the keyword none, if all Personal Avatar
requests should be refused. 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 specified in
[RFC2396].
There may be a file named pavatar (without extention like .png) on
the commentors server.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 (obs. if the implementation finds the keyword none instead of a valid URL it must abbort the autodiscovery because there will be no Personal Avatar at all):
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
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.