I didn't mean to suggest advocating a retention period, but a policy: permanent or temporary - not an explicit period. This would allow clients to request a specific policy, which can be handy. The server-sided complexity should be minimal - more so if you allow servers to offer just one of the policies.
I'm a fan of not overwriting a slot at all, but have the HTTP resource be completely static. That keeps things simple, from a caching and acces control mechanism. When an avatar (or $thing) changes, I think I'd prefer that the reference to the data changes too. On 8 September 2017 at 11:46, Daniel Gultsch <[email protected]> wrote: > 2017-09-08 11:04 GMT+02:00 Guus der Kinderen <[email protected] > >: > > Perhaps it'd be sensible to always add a reference to the desired > retention > > policy - also for temporary slots. Perhaps the server should answer with > the > > applied policy too? > > > I see your point. However there are two potential problems with it. > Just specifying the retention period doesn't provide a way to easily > overwrite the previous avatar (or $thing). And server developers need > to come with a way to store the desired retention period. > > But maybe we don't need that overwrite feature but instead put a lower > overall storage space limit on files that do not have a retention > period. > > cheers > Daniel > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
