NFD » NDN Specifications

ndn-cxx has not been used to develop any real-time application so I don’t see why this needs to be in ndn-cxx, as opposed to ndn-cpp.

From protocol point of view, finding the name for “latest data” requires an Interest reaching the producer itself.
Using selectors, the last Interest excluding all existing versions would reach the producer, and the producer should Nack this Interest, so the consumer knows it has found the last versions.
Not using selectors, the consumer can directly ask the producer /producer-prefix/what-is-latest-version/[random-number], and the producer can answer with the current version number plus some metadata about how to derive future versions, such as “I’ll generate a new version every second, and they’ll be named like ..”. The consumer can then retrieve the indicated version, plus several later versions as derived from the metadata in order to account for the round-trip during “what-is-latest-version” retrieval.

Yes, this may be more appropriate for ndn-cpp (except for the blocks on selector deprecation). But generally we have followed the pattern where architectural issues are demonstrated/prototyped in ndn-cxx, then the ndn-ccl implementations follow. I'll follow up with Lixia et al on this.