Introducing explicit type for implicit digest component
Change-Id: Ib2cd9a986a6b8835b0217c10aba62dbb30fc8bbc
Refs: #2011
diff --git a/changelog.rst b/changelog.rst
index 07d67db..1101493 100644
--- a/changelog.rst
+++ b/changelog.rst
@@ -7,6 +7,7 @@
- **Name**
+ Allow zero-length name component
+ + Require implicit digest to be specified using ``ImplicitSha256Digest`` name component
Since version 0.1
-----------------
diff --git a/conf.py b/conf.py
index 1e55a67..1d987ce 100644
--- a/conf.py
+++ b/conf.py
@@ -50,7 +50,7 @@
# The short X.Y version.
version = '0.2'
# The full version, including alpha/beta/rc tags.
-release = '0.2-alpha-1'
+release = '0.2-alpha-2'
# The language for content autogenerated by Sphinx. Refer to documentation
# for a list of supported languages.
diff --git a/interest.rst b/interest.rst
index e80a1e1..6e27d50 100644
--- a/interest.rst
+++ b/interest.rst
@@ -81,7 +81,7 @@
Any ::= ANY-TYPE TLV-LENGTH(=0)
The ``Exclude`` selectors allows requester to specify list and/or ranges of names components that MUST NOT appear as a continuation of the Name prefix in the responding Data packet to the Interest.
-For example, if Interest is expressed for ``/ndn/edu`` and Exclude specifies one name component ``ucla``, then nor data producer nor conforming NDN routers are allowed to return any Data packet that has prefix ``/ndn/edu/ucla``.
+For example, if Interest is expressed for ``/ndn/edu`` and Exclude specifies one name component ``ucla``, then neither data producer nor conforming NDN routers are allowed to return any Data packet that has prefix ``/ndn/edu/ucla``.
Exclude filter applies only to a name component of the Data packet name that is located at a position that numerically equals to the number of name components in the Interest packet, assuming 0 is the first name component.
diff --git a/name.rst b/name.rst
index ac88781..4dd8199 100644
--- a/name.rst
+++ b/name.rst
@@ -10,13 +10,24 @@
We use a 2-level nested TLV to represent a name.
The Type in the outer TLV indicates this is a Name.
-All inner TLVs have the same Type indicating that they each contain a name component.
-There is no restriction on the Value field in a name component and it may contain any byte sequence.
+Inner TLVs should be one of ``NameComponent`` blocks, as defined in the following:
::
Name ::= NAME-TYPE TLV-LENGTH NameComponent*
- NameComponent ::= NAME-COMPONENT-TYPE TLV-LENGTH BYTE*
+
+ NameComponent ::= GenericNameComponent |
+ ImplicitSha256DigestComponent
+
+ GenericNameComponent ::= NAME-COMPONENT-TYPE TLV-LENGTH BYTE*
+
+ ImplicitSha256DigestComponent ::= IMPLICIT-SHA256-DIGEST-COMPONENT-TYPE TLV-LENGTH(=32)
+ BYTE{32}
+
+
+- ``GenericNameComponent`` is a generic name component, without any restrictions on the content of the value.
+
+- ``ImplicitSha256DigestComponent`` is an implicit SHA256 digest component and it is required to contain a value of 32 octets.
NDN URI Scheme
@@ -27,20 +38,34 @@
- The scheme identifier is ``ndn``.
-- When producing a URI from an NDN Name, only the generic URI unreserved characters are left unescaped.
- These are the US-ASCII upper and lower case letters (A-Z, a-z), digits (0-9), and the four specials PLUS (+), PERIOD (.), UNDERSCORE (\_), and HYPHEN (-).
- All other characters are escaped using the percent-encoding method of the URI Generic Syntax.
-
-- To unambiguously represent name components that would collide with the use of . and .. for relative URIs, any component that consists solely of zero or more periods is encoded using three additional periods.
-
- The authority component (the part after the initial ``//`` in the familiar http and ftp URI schemes) is not relevant to NDN.
It should not be present, and it is ignored if it is present.
+- Component types have the following URI representations:
+
+ * ``GenericNameComponent``
+
+ + When producing a URI from an NDN Name, only the generic URI unreserved characters are left unescaped.
+ These are the US-ASCII upper and lower case letters (A-Z, a-z), digits (0-9), and the four specials PLUS (+), PERIOD (.), UNDERSCORE (\_), and HYPHEN (-).
+ All other characters are escaped using the percent-encoding method of the URI Generic Syntax.
+
+
+ + To unambiguously represent name components that would collide with the use of . and .. for relative URIs, any component that consists solely of zero or more periods is encoded using three additional periods.
+
+ * ``ImplicitSha256DigestComponent``
+
+ + Implicit SHA256 digest component starts with ``sha256digest=`` prefix (case sensitive), following the digest represented as a sequence of 32 hexadecimal numbers.
+
+ For example, ``sha256digest=893259d98aca58c451453f29ec7dc38688e690dd0b59ef4f3b9d33738bff0b8d``
+
+
+.. _Implicit Digest Component:
+
Implicit Digest Component
~~~~~~~~~~~~~~~~~~~~~~~~~
The Name of every piece of content includes as its final component a derived digest that ultimately makes the name unique.
-This digest may occur in an Interest Name as an ordinary Component (the last one in the name).
+This digest may occur in an Interest Name as an ``ImplicitSha256DigestComponent`` and MUST appear as the last component in the name.
This final component in the name is never included explicitly in the Data packet when it is transmitted on the wire.
It can be computed by any node based on the Data packet content.
@@ -53,12 +78,27 @@
Canonical Order
~~~~~~~~~~~~~~~
-In several contexts in NDN packet processing, it is useful to have a consistent ordering of names and name components. NDN names consist of a sequence of NameComponents, and each NameComponent is a sequence of zero or more 8-bit bytes. The ordering for components is such that:
+In several contexts in NDN packet processing, it is necessary to have a consistent ordering of names and name components.
-- If *a* is shorter than *b* (i.e., has fewer bytes), then *a* comes before *b*.
+The order between individual name components is defined as follows:
-- If *a* and *b* have the same length, then they are compared in ASCII lexicographic order (e.g., ordering based on memcmp() operation.)
+- If components have different type, then
+ + Any ``ImplicitSha256DigestComponent`` is less than any ``GenericNameComponent``
+
+ ::
+
+ ImplicitSha256DigestComponent < GenericNameComponent
+
+ .. note::
+ This order can be enforced by directly comparing TYPE code of the components.
+ Type code ``ImplicitSha256DigestComponent`` is guaranteed to be less than type code ``GenericNameComponent``.
+
+- If components have the same type, then
+
+ + If *a* is shorter than *b* (i.e., has fewer bytes), then *a* comes before *b*.
+
+ + If *a* and *b* have the same length, then they are compared in lexicographic order based on absolute value of octet values (e.g., ordering based on memcmp() operation.)
For Names, the ordering is just based on the ordering of the first component where they differ.
If one name is a proper prefix of the other, then it comes first.
diff --git a/types.rst b/types.rst
index bc4ffa4..ddd39ec 100644
--- a/types.rst
+++ b/types.rst
@@ -19,6 +19,8 @@
+---------------------------------------------+-------------------+----------------+
| NameComponent | 8 | 0x08 |
+---------------------------------------------+-------------------+----------------+
+| ImplicitSha256DigestComponent | 1 | 0x01 |
++---------------------------------------------+-------------------+----------------+
| **Interest packet** |
+---------------------------------------------+-------------------+----------------+
| Selectors | 9 | 0x09 |