Relays MAY cache Objects, but are not required to.
A caching relay saves Objects to its cache identified by the Object's Full Track Name, Group ID and Object ID. If multiple objects are received with the same Full Track Name, Group ID and Object ID, Relays MAY ignore subsequently received Objects or MAY use them to update certain cached fields. Implementations that update the cache need to protect against cache poisoning. The only Object fields that can be updated are the following:
-
Object Status can transition from any status to Object Does Not Exist in cases where the object is no longer available. Transitions between Normal, End of Group and End of Track are invalid.
-
Object Header Extensions can be added, removed or updated, subject to the constraints of the specific header extension.
An endpoint that receives a duplicate Object with an invalid Object Status change, or a Forwarding Preference, Subgroup ID, Priority or Payload that differ from a previous version MUST treat the track as Malformed.
Note that due to reordering, an implementation can receive a duplicate Object with a status of Normal, End of Group or End of Track after receiving a previous status of Object Not Exists. The endpoint SHOULD NOT cache or forward the duplicate object in this case.
A cache MUST store all properties of an Object defined in Section 9.2.1, with the exception of any extensions (Section 9.2.1.2) that specify otherwise.