Project

General

Profile

Feature #3301

Reserve ContentType for Manifest

Added by Ilya Moiseenko almost 6 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Normal
Start date:
Due date:
% Done:

0%

Estimated time:

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.

#1

Updated by Alex Afanasyev almost 6 years ago

Does it needs to be defined at the network-level? If so, we need to formally define it in the spec.

#2

Updated by Ilya Moiseenko almost 6 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:

  1. Contenttype_Manifest - doesn't need an explanation, right?
  2. ManifestCatalogue - Manifest contains a catalogue of names. Router may need to look at it in order to cache more effectively for example.
  3. KeyValuePair - Is used in Manifest and application NACKs. For example, Retry-After NACK is implemented with this TLV.
#3

Updated by Junxiao Shi almost 6 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.

#4

Updated by Alex Afanasyev almost 6 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.

#5

Updated by Junxiao Shi almost 6 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".

#6

Updated by Junxiao Shi almost 6 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.

#7

Updated by Junxiao Shi over 3 years ago

  • Tracker changed from Task to Feature
  • Status changed from New to Resolved

Assignment is recorded in ContentType rev6.

#8

Updated by Junxiao Shi over 3 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF