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 can transition from existing to not existing in cases where the object is no longer available.
-
Object Properties can be added, removed or updated, subject to the constraints of the specific property.
An endpoint that receives a duplicate Object with a different Forwarding Preference, Subgroup ID, Priority or Payload MUST treat the track as Malformed.
For ranges of objects that do not exist, relays MAY change the representation of a missing range to a semantically equivalent one. For instance, a relay may change an End-of-Group="Y" Subgroup Header to an equivalent object with an End of Group status, or a Prior Group ID Gap extension could be removed in FETCH, where it's redundant.
Note that due to reordering, an implementation can receive an Object after receiving an indication that the Object in question does not exist. The endpoint SHOULD NOT cache or forward the object in this case.
A cache MUST store all fields of an Object defined in Section 10.2.1, with the exception of any Object Properties (Section 10.2.1.2) that specify otherwise.