Metadata » History » Revision 6
Revision 5 (Davide Pesavento, 10/25/2018 02:05 PM) → Revision 6/7 (Davide Pesavento, 07/10/2026 08:08 PM)
# Metadata Realtime Data Retrieval Protocol (RDR) protocol This document defines the recommended semantics and packet format of the Metadata Retrieval Protocol. This protocol, inspired by [Real-Time Data Retrieval in Named Data Networking](https://named-data.net/publications/hoticn18realtime-retrieval/), can be used to discover Networking](https://named-data.net/publications/hoticn18realtime-retrieval/) published in HotICN'18 introduces Real-time Data Retrieval (RDR) protocol for discovering the latest version number of a data stream and any other application-specific metadata. real-time streaming data. This document defines the recommended packet format of the RDR protocol. This RDR is an application-level protocol, and its usage could be application specific. Therefore, an it is RECOMMENDED that each application MAY define defines its own instance of the RDR protocol based on this document, rather than directly referencing this specification. ## Metadata Packet The In RDR, the *metadata packet* is a Data packet that carries the latest version number of a data stream and any other application-specific metadata. stream. ### Name Suffix The name of a metadata packet MUST end with these three name components: 1. The keyword component `32=metadata`, indicating this Data packet is a metadata packet under this specification. 2. A version number component, whose format is defined in Naming Conventions. 3. A segment number component, whose format is defined in Naming Conventions. Normally the metadata is not segmented and thus the segment number is zero, but this component is included for future extensions. ### Name Prefix The name prefix of a metadata packet before the above three name components SHOULD be the same as the name of the versioned data up to (and not including) its version number component. For example, an application can have the following namespace: ``` # data stream /net/example/www/frontpage/%FD%97%47%1E%6C/%00%00 /net/example/www/frontpage/%FD%97%47%1E%6C/%00%01 /net/example/www/frontpage/%FD%97%47%1E%6D/%00%00 /net/example/www/frontpage/%FD%97%47%1E%6D/%00%01 # metadata packet /net/example/www/frontpage/32=metadata/%FD%7E%5F%45%08/%00%00 ``` ### FreshnessPeriod The *FreshnessPeriod* of a metadata packet MUST NOT be zero. See the [RDR paper](https://named-data.net/publications/hoticn18realtime-retrieval/) RDR paper for guidelines on an appropriate value for this field. ### Content Payload The *Content* Content of a metadata packet MUST be a sequence of TLV elements. At least one of the TLV elements MUST be a *Name* element. The first *Name* element indicates the versioned name of the latest version of the data; additional *Name* elements, if any, are ignored. For example: ```xml ``` <Content> <ArbitraryElement>this is ignored</ArbitraryElement> <Name>/net/example/www/frontpage/%FD%97%47%1E%6D</Name> <Name>this is ignored</Name> </Content> ``` ## Metadata RDR Discovery Interest Consumers In the RDR protocol, consumers express *metadata discovery Interests* RDR Discovery Interests to retrieve metadata packets, in order to discover the latest version number of the data stream and any other application-specific metadata. stream. A metadata discovery An RDR Discovery Interest MUST: * have carry a name that ends with a `32=metadata` keyword component * contain *CanBePrefix* * contain *MustBeFresh*