Am 21.07.2005 um 16:13 schrieb Mark Nottingham:
On 19/07/2005, at 1:48 AM, Stefan Eissing wrote:
[...]
I have the feeling that clients will need to protect themselves from
servers with almost infinite histories. So a client will probably
offer a XX days into the past, max NN entries setting in its UI. Maybe
that is all that's needed.
Good question. I was thinking roughly along these lines in the
Security Considerations, but didn't want to lead people too much.
How about:
"In case feeds are served via HTTP, server implemenations SHOULD
offer ETag and Last-Modified headers on history documents (see RFC
2616 xxx). Clients SHOULD persist ETag and Last-Modified information
and use If-* headers to ease server load on history synchronization."
Hmm. Maybe not SHOULDs, but some prose might lead people in the right
direction, perhaps an 'Implementer Notes' section?
Ok, a SHOULD is not really required. Let common sense prevail.
The remaining question for me is if the fh:prev links are pointing to
history records or if they are just a way to split a large feed into
chunks.
The more I think about it, the more I lean towards leaving the spec as
is. Since clients do not trust servers very much, a clever client will
most likely implement a synch strategy which frequently checks if the
prev uris change and once a day/after a week absence traverse the prev
chain and retrieve all documents.
//Stefan
