Feature #3301
closedReserve ContentType for Manifest
0%
Description
Reserve a ContentType code for Manifest, as introduced in Fetching content in Named Data Networking with embedded manifests.
This is to be implemented in Consumer/Producer API.
Updated by Alex Afanasyev about 9 years ago
Does it needs to be defined at the network-level? If so, we need to formally define it in the spec.
Updated by Ilya Moiseenko about 9 years ago
Does it needs to be defined at the network-level? If so, we need to formally define it in the spec.
There are 3 TLVs added:
- Contenttype_Manifest - doesn't need an explanation, right?
- ManifestCatalogue - Manifest contains a catalogue of names. Router may need to look at it in order to cache more effectively for example.
- KeyValuePair - Is used in Manifest and application NACKs. For example, Retry-After NACK is implemented with this TLV.
Updated by Junxiao Shi about 9 years ago
Quote Lixia's email from 20150908:
(a developer) declared a few things to put into the implementation as needed by his thesis, yet the technical rationals behind those implementation decisions sound rather unconvincing.
I wonder whether we should bring those designs (that affect NFD implementation) for some explanation first, before (a developer) simply declares his needs and puts into the implementation decision.
According to this opinion, a full explanation of the semantics of these TLVs should be provided, before I can agree to adding this into the implementation.
Updated by Alex Afanasyev about 9 years ago
I partially disagree with note-3, as there are two things mixed:
If these blocks are outside networking level (=need not be understood by routers, in application TLV range), there is no additional explanation necessary. Just the corresponding implementation (a new separate header file defining the TLV codes).
If these blocks need to be at the networking level, additional explanations and discussions are necessary.
In any case, we need to have a formal specification for the declared blocks, however self-explanatory they are.
Updated by Junxiao Shi about 9 years ago
If these blocks are outside networking level (=need not be understood by routers, in application TLV range), there is no additional explanation necessary. Just the corresponding implementation (a new separate header file defining the TLV codes).
If they are application, they can appear only in the application (or in consumer-producer-API library), not in ndn-cxx.
note-3 quote originally refers to NFD Transport::Packet::localEndpoint
field, which is not on the wire, but Lixia still demands explanation, so I disagree with "no additional explanation necessary".
Updated by Junxiao Shi about 9 years ago
- Project changed from ndn-cxx to NDN Specifications
- Subject changed from Add new TLV for Manifest and application NACK processing to Reserve ContentType for Manifest
- Description updated (diff)
- Category deleted (
Base) - Priority changed from High to Normal
- Target version deleted (
v0.4) - Start date deleted (
10/29/2015)
20151112 conference call agrees to reserve code 4 for this experimental purpose.
ManifestCatalogue
and KeyValuePair
in note-2 should go into application range.
Updated by Junxiao Shi almost 7 years ago
- Tracker changed from Task to Feature
- Status changed from New to Resolved
Assignment is recorded in ContentType rev6.