© 2006 Jeena Paradies
The Personal Avatar (short Pavatar) system is a way to use small personalized images to standardize a providers profile picture through various websites when leaving comments and other content. Providers are able to host their Personal Avatars themselves.
This is the 18 December 2006 Candidate Recommendation of the Personal Avatar. This Candidate Recommendation was published to indicate that the document is believed to be stable and to encourage implementation by the developer community.
Comments are welcome, please write to <spec@pavatar.com>.
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].
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 not exceed the size of 409600 Bit (the octuple size of an uncompressed 80x80pixel big picture with 8-bit color depth).
A valid Personal Avatar must be publicly accessible through a valid HTTP URL ([RFC 1738]). This URL must be used to reference the Personal Avatar (see Autodiscovery).
The Personal Avatar must have the correct Content-Type header.
The provider may restrict access to the Personal Avatar. The provider must
act accordingly to HTTP, e.g. should response with a 403 HTTP status code, if access is denied.
It is recommended to use the keyword "none" of the HTTP-Header
X-Pavatar as described in 3.a. to refuse the delivery of the Personal
Avatar completely.
The URL of the Personal Avatar must be offered by the provider in one or more of the following ways to the consumer, the use of 3.a. and 3.b. is recommended. The consumer must accept all three ways.
If chosen, a reference to a Personal Avatar must be returned with a X-Pavatar
HTTP header, for example:
X-Pavatar: http://example.com/path/to/my-own_pavatar.pngThe value of the X-Pavatar header must be the absolute URL of the
Personal Avatar or the keyword "none".
The server response must not include more than one such header.
If chosen, an HTML or XHTML Personal Avatar enabled page must contain a <link>
element. It must have one of the following forms:
<link rel="pavatar" href="URL"><link rel="pavatar" href="URL" />The URL in the "href" attribute must be a valid and absolute HTTP URL according to
[RFC 1738] or the keyword "none".
If chosen, there must be a file named "pavatar.png" on the providers server. The URL for this file must conform to the following form. The EBNF keywords used here are similar to the ones used in [RFC 1738].
hostport = host [ ":" port ]
hsegment = *[ uchar | ";" | ":" | "@" | "&" | "=" ]
puri = "http://" hostport *[ "/" hsegment ] "/pavatar.png"
hsegmet ends with a slash: GOTO 3hsegmenthsegmentsThe HTTP Header (3.a.) method must have the highest precedence, the Direct URL (3.c) method the lowest.
The implementation should ensure to use as little traffic as possible to deal with Personal Avatars
(e.g., use conditional get HTTP headers like If-Modified-Since).
Personal Avatar implementations, given a publisher's 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 decode the allowed HTML 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 publisher's website directory. If
not, it shall check if there is a Personal Avatar in the publisher's website document root.
The implementation may manipulate the cached Personal Avatar if necessary, e.g. changes in width and height, colors, etc. but it must respect the visual identity of the provider and therefore avoid destructive transformations of the Personal Avatar, such as those that fundamentally alter the content of the image.
The implementation should cache all Personal Avatars it wants to serve. It should not serve them remotely.
The implementation may check regularly for changed Personal Avatars using the information given in the
Cache-Control or Expires headers. If the publisher's website doesn't send these headers,
it is recommended that it checks weekly for changes.
The implementation should remember URLs for which the autodiscovery didn't find a Personal Avatar and not check them for changes until the provider posts something new.
This chapter is informative. Useragents are not required to implement the properties of this chapter in order to conform to the Personal Avatar specification.
Clients may optimize the search. For example:
<link> elements may only appear in the document's head, clients may abort
when the strings </head> or <body> are seen (e.g. if the client
reads the content one line at a time).The implementation may include an automatic denial-of-publish mechanism if the Personal Avatar is unknown to the system. It may include a notification mechanism in case of an automatic denial-of-publish.