Updates for version 0.3
Change-Id: I1e5307e5c04323046549c001fcf638c17e08f0ab
Refs: #4445, #4444, #4443, #4442, #4441, #4440, #4485
diff --git a/data.rst b/data.rst
index 7b1e5b8..eba092c 100644
--- a/data.rst
+++ b/data.rst
@@ -7,11 +7,11 @@
Data ::= DATA-TLV TLV-LENGTH
Name
- MetaInfo
- Content
+ MetaInfo?
+ Content?
Signature
-The Data packet represents some arbitrary binary data (held in the Content element) together with its Name, some additional bits of information (MetaInfo), and a digital Signature of the other three elements. The Name is the first element since all NDN packet processing starts with the name. Signature is put at the end of the packet to ease the implementation because signature computation covers all the elements before Signature.
+The Data packet represents some arbitrary binary data (held in the optional ``Content`` element) together with its ``Name``, some additional bits of optional information (``MetaInfo``), and a digital ``Signature`` of the other element(s). The Name is the first element since all NDN packet processing starts with the name. Signature is put at the end of the packet to ease the implementation because signature computation covers all the elements before Signature.
Name
~~~~
@@ -23,8 +23,6 @@
MetaInfo
~~~~~~~~
-.. [#f1] If ``ContentType``, ``FreshnessPeriod`` and ``FinalBlockId`` are optional, one may consider ``Metainfo`` itself should be optional. But would having all 4 parts of Data packet help simplify implementation? We leave this question to people who are more familiar with high speed implementations.
-
::
MetaInfo ::= META-INFO-TYPE TLV-LENGTH
@@ -42,21 +40,22 @@
The following ContentTypes are currently defined:
-+-----------------+----------------+--------------------------------------------------------------+
-| ContentType | Assigned value | Description of the content |
-+=================+================+==============================================================+
-| BLOB | 0 | payload identified by the data name; this is the default |
-| | | ContentType |
-+-----------------+----------------+--------------------------------------------------------------+
-| LINK | 1 | a list of delegations (see :ref:`link`) |
-+-----------------+----------------+--------------------------------------------------------------+
-| KEY | 2 | public key |
-+-----------------+----------------+--------------------------------------------------------------+
-| NACK | 3 | application-level NACK |
-+-----------------+----------------+--------------------------------------------------------------+
++-----------------+-----------------+--------------------------------------------------------------+
+| ContentType | Assigned number | Description of the content |
++=================+=================+==============================================================+
+| BLOB | 0 | payload identified by the data name; this is the default |
+| | | ContentType |
++-----------------+-----------------+--------------------------------------------------------------+
+| LINK | 1 | a list of delegations (see :ref:`link`) |
++-----------------+-----------------+--------------------------------------------------------------+
+| KEY | 2 | public key |
++-----------------+-----------------+--------------------------------------------------------------+
+| NACK | 3 | application-level NACK |
++-----------------+-----------------+--------------------------------------------------------------+
Other ContentType numbers are assigned and maintained in `NDN Packet Specification Wiki <https://redmine.named-data.net/projects/ndn-tlv/wiki/ContentType>`__.
+.. _FreshnessPeriod:
FreshnessPeriod
+++++++++++++++
@@ -66,33 +65,28 @@
FreshnessPeriod ::= FRESHNESS-PERIOD-TLV TLV-LENGTH
nonNegativeInteger
-The optional FreshnessPeriod indicates how long a node should wait after the arrival of this data before marking it as stale.
+The optional ``FreshnessPeriod`` indicates how long a node should wait after the arrival of this data before marking it "non-fresh".
The encoded value is number of milliseconds.
-Note that the stale data is still valid data; the expiration of FreshnessPeriod only means that the producer may have produced newer data.
+Note that the "non-fresh" data is still valid data; the expiration of ``FreshnessPeriod`` only means that the producer may have produced newer data.
-Each content store associates every piece of Data with a staleness bit.
-If the Data carries a FreshnessPeriod, it will initially be considered "fresh" and, after the Data has resided in the content store for FreshnessPeriod, it will be marked as stale.
-This is per object staleness and is local to the NDN node.
+If the Data packet carries a ``FreshnessPeriod`` greater than zero, a node should initially consider it "fresh". After the Data has resided in the node for ``FreshnessPeriod`` milliseconds, it will be marked as "non-fresh".
+If the Data does not have a ``FreshnessPeriod`` or if it has a ``FreshnessPeriod`` equal to zero, it MUST be immediately marked "non-fresh".
-If an Interest contains MustBeFresh TLV, a content store MUST NOT return Data with the staleness bit set in response to this interest.
-The effect is the same as if that stale Data did not exist (i.e., the Interest might be matched by some other Data in the store, or, failing that, get forwarded to other nodes).
-When an exact duplicate of the "stale" Data packet, carrying a positive FreshnessPeriod value, is inserted into a content store, the store SHOULD remove the "stale" bit from the cached Data.
-In particular, the Data in the store is no longer stale.
-
-When a content store receives a Data packet without a FreshnessPeriod or with a FreshnessPeriod equal to 0, then it can satisfy an Interest marked MustBeFresh.
+If an Interest contains ``MustBeFresh`` element, a node MUST NOT return "non-fresh" Data in response to this Interest.
+The effect is the same as if that "non-fresh" Data did not exist (i.e., the Interest might be matched by some other Data in the store, or, failing that, get forwarded to other nodes).
+When an exact duplicate of the "non-fresh" Data packet with a positive ``FreshnessPeriod`` value arrives at the node, the node SHOULD re-mark it as "fresh" for the specified duration.
FinalBlockId
++++++++++++
::
- FinalBlockId ::= FINAL-BLOCK-ID-TLV TLV-LENGTH
- NameComponent
+ FinalBlockId ::= FINAL-BLOCK-ID-TYPE TLV-LENGTH
+ NameComponent
-The optional FinalBlockId indicates the identifier of the final block
-in a sequence of fragments.
+The optional FinalBlockId identifies the final block in a sequence of fragments.
It should be present in the final block itself, and may also be present in other fragments to provide advanced warning of the end to consumers.
-The value here should be equal to the last explicit Name Component of the final block.
+The value here should be equal to the last explicit name component of the final block.
.. _Content:
@@ -103,3 +97,5 @@
::
Content ::= CONTENT-TYPE TLV-LENGTH BYTE*
+
+The ``Content`` element can carry any arbitrary sequence of bytes.