Personal Avatar 0.2.0

Abstract

The Personal Avatar (aka Pavatar) is a picture hosted on your webspace which can be used by webmasters to display an image referring to you. E.g. you make a comment or a forum posting and the Pavatar 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 secure a permanent reachability.

Status of This Document

This is an early and unstable version, comments are welcome, please write to <pavatar@jeenaparadies.net>.

Please do not use this specification for implementation until it is stable. There are currently three known implementations of this specification, but no formal testing has been done.

1. Classic Forum
2. Weblogsoftware Block
3. Pavatar check, see the sourcecode

Table of Contents

1. Introduction
1. Definitions
2. Technical Details
2. Personal Avatar Conformance Requirements
   1. Technical Definition
   2. Refusing Personal Avatar requests
   3. Autodiscovery
   1. HTTP Header
   2. Link Element
   3. Direct URL
   4. Precedence
   4. Dealing with Personal Avatars
      1. Autodiscovery Algorithm
      2. Manipulating
      3. Caching
      4. Updating
   5. Appendix
      1. Optimization
      2. Support of Conformance to Arbitrary Rules

   ---

   1. Introduction

   The Personal Avatar system is a way to use small personalized graphics to standardize your profile picture through various websites when leaving comments and other content. Commentators are able to host their Personal Avatars themselves and the implementation must support the commentators ability to restrict access to their Personal Avatar. The publisher of the Personal Avatar should be able to edit and cache the Personal Avatar. The publisher must be able to refuse a Personal Avatar.

   1.a. Definitions

   Commentator

   Commentator is the person who leaves a comment, post, annotation or similar content on a publishers page and possesses the Personal Avatar. The commentator and the publisher may be the same.

   Commentators Website

   A commentators website must be a valid HTTP URL according to [RFC 1738], which the commentator has specified as his website.

   Personal Avatar

   A Personal Avatar is a picture stored on the commentator's website conforming to the Personal Avatar Conformance Requirements described in 2.

   Webmaster

   The publisher provides the service for the commentator to act. The publisher and the commentator may be the same.

   The Personal Avatar implementation (short: implementation)

   This is the implementation running the publishers's service dealing the Personal Avatars.

   Now

   Now refers to the time the HTTP request is finished.

   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].

   1.b. Technical Details

   The implementation must use HTTP ([RFC 1945], [RFC 2616]) to test for the availability of a Personal Avatar at the URL specified by the commentator. In case of success, it should download, save and serve it locally but may also refer to the originating URL of the Personal Avatar.

   An implementation must be able to use the HTTP caching mechanisms.

   ---

   2. Personal Avatar Conformance Requirements

   2.a. Technical Definition

   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]) and must not exceed the size of 102400 Bit (twice the 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 commentator may use HTTP Cache-Control and/or Expires headers.

   2.b. Refusing Personal Avatar requests

   The commentator may restrict access to the Personal Avatar. The commentator 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 key word "none" of the HTTP-Header X-Pavatar as described in 3.a. to refuse the delivery of the Personal Avatar completly.

   ---

   3. Autodiscovery

   The URL of the Personal Avatar must be offered by the commentator in one or more of the following ways to the publisher, the use of 3.a. and 3.b. is recommended. The publisher must accept all three ways.

   3.a. HTTP Header

   If choosed a reference to a Personal Avatar must be returned with a X-Pavatar HTTP header, for example:

   X-Pavatar: http://example.com/my/directory/my-own_pavatar.png

   The 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 of such header.

   3.b. Link element

   If chosen, an HTML or XHTML Personal Avatar enabled page must contain a <link> element. It must have one of the following forms:

   HTML

   <link rel="pavatar" href="URL">

   XHTML

   <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".

   3.c. Direct URL (the favicon.ico way)

   If choosed there must be a file named "pavatar.png" on the commentators 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].

   puri = "http://" hostport *[ "/" hsegment ] "/pavatar.png"

   Example in pseudocode:

   1. IF the last hsegmet ends with a slash: GOTO 3
   2. Remove the first hsegment
   3. Append "pavatar.png" to the result
   4. IF success (i.e. a 2xx answer to an HEAD request) EXIT(SUCCESS)
   5. ELSE remove all hsegments
   6. Append "pavatar.png" to the result
   7. IF success (i.e. a 2xx answer to an HEAD request) EXIT(SUCCESS)
   8. EXIT(FAILURE)

   Precedence

   The HTTP Header (3.a.) method MUST have the highest precedence, the Direct URL (3.c) method the lowest.

   ---

   4. Dealing with Personal Avatars

   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).

   4.a. Autodiscovery Algorithm

   Personal Avatar implementations, given a commentators 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):

   1. Examine the HTTP headers of the response. If there are any 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.

   2. 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 ").

   3. If no X-Pavatar HTTP Header and no <link> could be found the implementation shall check first if there is a Personal Avatar in the commentators website directory. If not, it shall check if there is a Personal Avatar in the commentators website document root.

   If it finds a Personal Avatar the implementation should download it and save a copy.

   4.b. Manipulating

   The implementation may manipulate the cached Personal Avatar if necessary, e.g. changes in width and height, colors, etc.. It should not manipulate it if the commentator has avoided caching.

   4.c. Caching

   The implementation should cache all Personal Avatars it wants to serve. It should not serve it remotely. The commentator can avoid caching by specifying an Expires or Cache-Control header referring to a date prior or equal to now.

   4.d. Updating cached Personal Avatars

   The implementation may check regularly for changed Personal Avatars using the information given in the Cache-Control or Expires headers. If the commentators website doesn't send these headers, it is recommended that it check weekly for changes.

   ---

   5. Appendix

   This chapter is informative. UAs are not required to implement the properties of this chapter in order to conform to the Personal Avatar specification.

   5.a. Optimization

   Clients may optimize the search. For example:

   1. The client may initally only send an HTTP HEAD request in the hope that the header will be found and the content will not have to be fetched.
   2. Since <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).
   3. Since the Personal Avatar links are most likely to appear near the top of the document, clients may abort the search after passing a certain size threshold. Clients may similarly use the HTTP Content-Range header to only fetch the first few kilobytes of the target URI.

   5.b. Support of Conformance to Arbitrary Rules

   The implementation may include an automatic denial-of-publish mechanism if the pavatar is unknown to the system. It may include a notification mechanism in case of an automatic denial-of-publish.