Merge pull request #5 from sembrestels/patch-1
Fixes #1. Fixed internal spec links
This commit is contained in:
commit
69932c46aa
1 changed files with 7 additions and 7 deletions
|
@ -56,7 +56,7 @@ Comments are welcome, please write to <spec@pavatar.com>.
|
|||
: A providers website must be a valid HTTP URL according to [RFC 1738](http://www.faqs.org/rfcs/rfc1738.html), which the provider has specified as his website.
|
||||
|
||||
**Personal Avatar**
|
||||
: A Personal Avatar is a picture stored on the provider's website conforming to the Personal Avatar conformance requirements described in [2][conformance-requirements].
|
||||
: A Personal Avatar is a picture stored on the provider's website conforming to the Personal Avatar conformance requirements described in [2](#2-personal-avatar-conformance-requirements).
|
||||
|
||||
**Consumer**
|
||||
: The consumer provides the service for the provider to act. The consumer and the provider may be the same.
|
||||
|
@ -75,15 +75,15 @@ A valid Personal Avatar **must** be a 80x80 pixel sized image in GIF ([GIF89a](h
|
|||
|
||||
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](http://www.faqs.org/rfcs/rfc1738.html)). This URL **must** be used to reference the Personal Avatar (see [Autodiscovery](autodiscovery)).
|
||||
A valid Personal Avatar **must** be publicly accessible through a valid HTTP URL ([RFC 1738](http://www.faqs.org/rfcs/rfc1738.html)). This URL **must** be used to reference the Personal Avatar (see [Autodiscovery](#3-autodiscovery)).
|
||||
|
||||
The Personal Avatar **must** have the correct `Content-Type` header.
|
||||
|
||||
### 2.b. Refusing Personal Avatar Requests
|
||||
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](3). to refuse the delivery of the Personal Avatar completely.
|
||||
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](#3a-http-header). to refuse the delivery of the Personal Avatar completely.
|
||||
|
||||
## 3. Autodiscovery
|
||||
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.
|
||||
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](#3a-http-header). and [3.b](#3b-link-element). is recommended. The consumer **must** accept all three ways.
|
||||
|
||||
### 3.a. HTTP Header
|
||||
If chosen, a reference to a Personal Avatar must be returned with a X-Pavatar HTTP header, for example:
|
||||
|
@ -124,7 +124,7 @@ If chosen, there **must** be a file named "*pavatar.png*" on the providers serve
|
|||
8. EXIT(FAILURE)
|
||||
|
||||
### Precedence
|
||||
The HTTP Header ([3.a.](3)) method **must** have the highest precedence, the Direct URL ([3.c](3c)) method the lowest.
|
||||
The HTTP Header ([3.a.](#3a-http-header)) method **must** have the highest precedence, the Direct URL ([3.c](#3c-direct-url-the-faviconico-way)) method the lowest.
|
||||
|
||||
## 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).
|
||||
|
@ -151,7 +151,7 @@ The implementation **should** cache **all** Personal Avatars it wants to serve.
|
|||
### 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 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](#autodiscovery-algorithm) didn't find a Personal Avatar and not check them for changes until the provider posts something new.
|
||||
The implementation **should** remember URLs for which the [autodiscovery](#4a-autodiscovery-algorithm) didn't find a Personal Avatar and not check them for changes until the provider posts something new.
|
||||
|
||||
## Appendix
|
||||
|
||||
|
@ -165,4 +165,4 @@ Clients **may** optimize the search. For example:
|
|||
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 Personal Avatar is unknown to the system. It **may** include a notification mechanism in case of an automatic denial-of-publish.
|
||||
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.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue