tlv: rewrite syntax specifications using IETF ABNF
refs #4853
Change-Id: Iad79a63675279d53de2f7bb4891d10bf01d0424f
diff --git a/changelog.rst b/changelog.rst
index ddc616c..b24c849 100644
--- a/changelog.rst
+++ b/changelog.rst
@@ -4,6 +4,8 @@
Version 0.3
-----------
+- Rewrite TLV syntax specifications using `IETF Augmented BNF (RFC 5234) <https://tools.ietf.org/html/rfc5234>`__
+
- **Interest**
+ Remove ``Selectors`` element
diff --git a/data.rst b/data.rst
index 7444730..66a00c5 100644
--- a/data.rst
+++ b/data.rst
@@ -5,11 +5,11 @@
NDN Data packet is TLV defined as follows::
- Data ::= DATA-TLV TLV-LENGTH
- Name
- MetaInfo?
- Content?
- Signature
+ Data = DATA-TYPE TLV-LENGTH
+ Name
+ [MetaInfo]
+ [Content]
+ DataSignature
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.
@@ -28,18 +28,17 @@
::
- MetaInfo ::= META-INFO-TYPE TLV-LENGTH
- ContentType?
- FreshnessPeriod?
- FinalBlockId?
+ MetaInfo = META-INFO-TYPE TLV-LENGTH
+ [ContentType]
+ [FreshnessPeriod]
+ [FinalBlockId]
ContentType
+++++++++++
::
- ContentType ::= CONTENT-TYPE-TYPE TLV-LENGTH
- nonNegativeInteger
+ ContentType = CONTENT-TYPE-TYPE TLV-LENGTH nonNegativeInteger
The following ContentTypes are currently defined:
@@ -65,8 +64,7 @@
::
- FreshnessPeriod ::= FRESHNESS-PERIOD-TLV TLV-LENGTH
- nonNegativeInteger
+ FreshnessPeriod = FRESHNESS-PERIOD-TYPE TLV-LENGTH nonNegativeInteger
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.
@@ -84,8 +82,7 @@
::
- FinalBlockId ::= FINAL-BLOCK-ID-TYPE TLV-LENGTH
- NameComponent
+ FinalBlockId = FINAL-BLOCK-ID-TYPE TLV-LENGTH NameComponent
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.
@@ -99,6 +96,6 @@
::
- Content ::= CONTENT-TYPE TLV-LENGTH BYTE*
+ Content = CONTENT-TYPE TLV-LENGTH *OCTET
The ``Content`` element can carry any arbitrary sequence of bytes.
diff --git a/interest.rst b/interest.rst
index 0206e6d..0e408fb 100644
--- a/interest.rst
+++ b/interest.rst
@@ -7,23 +7,22 @@
::
- Interest ::= INTEREST-TYPE TLV-LENGTH
- Name
- CanBePrefix?
- MustBeFresh?
- ForwardingHint?
- Nonce?
- InterestLifetime?
- HopLimit?
- (ApplicationParameters |
- ApplicationParameters InterestSignatureInfo InterestSignatureValue)?
+ Interest = INTEREST-TYPE TLV-LENGTH
+ Name
+ [CanBePrefix]
+ [MustBeFresh]
+ [ForwardingHint]
+ [Nonce]
+ [InterestLifetime]
+ [HopLimit]
+ [ApplicationParameters [InterestSignature]]
``Name`` is the only required element in an Interest packet.
``Nonce`` is required when an Interest is transmitted over the network links, i.e., a compliant forwarder must augment the Interest with the ``Nonce`` element if it is missing.
``CanBePrefix``, ``MustBeFresh``, ``InterestLifetime``, and ``ForwardingHint`` are optional elements to guide Interest matching or forwarding.
Interest can also include an optional ``ApplicationParameters`` element.
-If an Interest contains ``InterestSignatureInfo`` and ``InterestSignatureValue``, it is considered a Signed Interest.
+If an Interest contains ``InterestSignature``, it is considered a Signed Interest.
See :doc:`Signed Interest section <signed-interest>` for details.
As recommended by :ref:`TLV evolvability guidelines <evolvability>`, unrecognized non-critical TLV elements may appear in the Interest packet.
@@ -42,7 +41,8 @@
::
- CanBePrefix ::= CAN-BE-PREFIX-TYPE TLV-LENGTH(=0)
+ CanBePrefix = CAN-BE-PREFIX-TYPE
+ TLV-LENGTH ; == 0
When present, ``Name`` element in the Interest is a prefix, exact, or full name of the requested Data packet.
@@ -57,7 +57,8 @@
::
- MustBeFresh ::= MUST-BE-FRESH-TYPE TLV-LENGTH(=0)
+ MustBeFresh = MUST-BE-FRESH-TYPE
+ TLV-LENGTH ; == 0
The presence or absence of the ``MustBeFresh`` element indicates whether a content store may satisfy the Interest with stale Data.
Refer for :ref:`FreshnessPeriod section <FreshnessPeriod>` for more information.
@@ -67,8 +68,7 @@
::
- ForwardingHint ::= FORWARDING-HINT-TYPE TLV-LENGTH
- Delegation+
+ ForwardingHint = FORWARDING-HINT-TYPE TLV-LENGTH 1*Delegation
The ForwardingHint element contains a list of name delegations, as defined in :ref:`link` section.
Each delegation implies that the requested Data packet can be retrieved by forwarding the Interest along the delegation path.
@@ -83,7 +83,9 @@
::
- Nonce ::= NONCE-TYPE TLV-LENGTH(=4) BYTE{4}
+ Nonce = NONCE-TYPE
+ TLV-LENGTH ; == 4
+ 4OCTET
The Nonce carries a randomly-generated 4-octet long byte-string.
The combination of Name and Nonce should uniquely identify an Interest packet.
@@ -94,7 +96,7 @@
::
- InterestLifetime ::= INTEREST-LIFETIME-TYPE TLV-LENGTH nonNegativeInteger
+ InterestLifetime = INTEREST-LIFETIME-TYPE TLV-LENGTH nonNegativeInteger
``InterestLifetime`` indicates the (approximate) time remaining before the Interest times out.
The value is the number of milliseconds. The timeout is relative to the arrival time of the Interest at the current node.
@@ -110,7 +112,9 @@
::
- HopLimit ::= HOP-LIMIT-TYPE TLV-LENGTH(=1) BYTE{1}
+ HopLimit = HOP-LIMIT-TYPE
+ TLV-LENGTH ; == 1
+ OCTET
The optional ``HopLimit`` element indicates the number of hops the Interest is allowed to be forwarded. The value is encoded as a 1-byte unsigned integer value in the range 0-255.
@@ -133,8 +137,7 @@
::
- ApplicationParameters ::= APPLICATION-PARAMETERS-TYPE TLV-LENGTH
- BYTE*
+ ApplicationParameters = APPLICATION-PARAMETERS-TYPE TLV-LENGTH *OCTET
The ``ApplicationParameters`` element can carry any arbitrary data that parameterizes the request for Data.
-The Interest's name MUST include a Interest parameters digest component to ensure uniqueness and integrity of the parameterized Interest (see :ref:`Interest Parameters Digest Component` section for additional details).
\ No newline at end of file
+The Interest's name MUST include a Interest parameters digest component to ensure uniqueness and integrity of the parameterized Interest (see :ref:`Interest Parameters Digest Component` section for additional details).
diff --git a/link.rst b/link.rst
index ca64b56..1b554a7 100644
--- a/link.rst
+++ b/link.rst
@@ -5,21 +5,17 @@
The Link Object is a specialized form of a :ref:`Data packet <data>` packet, defined as follows::
- LinkObject ::= DATA-TLV TLV-LENGTH
- Name
- MetaInfo (.ContentType = LINK)
- LinkContent
- Signature
+ LinkObject = DATA-TYPE TLV-LENGTH
+ Name
+ MetaInfo ; ContentType == LINK
+ LinkContent
+ Signature
- LinkContent ::= CONTENT-TYPE TLV-LENGTH
- Delegation+
+ LinkContent = CONTENT-TYPE TLV-LENGTH 1*Delegation
- Delegation ::= LINK-DELEGATION-TYPE TLV-LENGTH
- Preference
- Name
+ Delegation = LINK-DELEGATION-TYPE TLV-LENGTH Preference Name
- Preference ::= LINK-PREFERENCE-TYPE TLV-LENGTH
- nonNegativeInteger
+ Preference = LINK-PREFERENCE-TYPE TLV-LENGTH nonNegativeInteger
Link Object is a data packet, whose content contains a list of one or more name delegations: a pair of name and the associate priority.
diff --git a/name.rst b/name.rst
index df3e8e6..a7f0fca 100644
--- a/name.rst
+++ b/name.rst
@@ -14,26 +14,26 @@
::
- Name ::= NAME-TYPE TLV-LENGTH NameComponent*
+ Name = NAME-TYPE TLV-LENGTH *NameComponent
- NameComponent ::= GenericNameComponent |
- ImplicitSha256DigestComponent |
- ParametersSha256DigestComponent |
- OtherTypeComponent
+ NameComponent = GenericNameComponent /
+ ImplicitSha256DigestComponent /
+ ParametersSha256DigestComponent /
+ OtherTypeComponent
- GenericNameComponent ::= NAME-COMPONENT-TYPE TLV-LENGTH
- BYTE*
+ GenericNameComponent = GENERIC-NAME-COMPONENT-TYPE TLV-LENGTH *OCTET
- ImplicitSha256DigestComponent ::= IMPLICIT-SHA256-DIGEST-COMPONENT-TYPE TLV-LENGTH(=32)
- BYTE{32}
+ ImplicitSha256DigestComponent = IMPLICIT-SHA256-DIGEST-COMPONENT-TYPE
+ TLV-LENGTH ; == 32
+ 32OCTET
- ParametersSha256DigestComponent ::= PARAMETERS-SHA256-DIGEST-COMPONENT-TYPE TLV-LENGTH(=32)
- BYTE{32}
+ ParametersSha256DigestComponent = PARAMETERS-SHA256-DIGEST-COMPONENT-TYPE
+ TLV-LENGTH ; == 32
+ 32OCTET
- OtherTypeComponent ::= OTHER-TYPE-COMPONENT-TYPE TLV-LENGTH
- BYTE*
+ OtherTypeComponent = OTHER-TYPE-COMPONENT-TYPE TLV-LENGTH *OCTET
- OTHER-TYPE-COMPONENT-TYPE ::= number in the range 3-65535 inclusive except 8
+ ; OTHER-TYPE-COMPONENT-TYPE is a TLV-TYPE in the range 1-65535 (inclusive) other than the above defined types
- ``GenericNameComponent`` is a generic name component, without any restrictions on the content of the value.
diff --git a/signature.rst b/signature.rst
index 9a0d713..28a74ed 100644
--- a/signature.rst
+++ b/signature.rst
@@ -17,15 +17,13 @@
::
- Signature ::= SignatureInfo
- SignatureValue
+ DataSignature = SignatureInfo SignatureValue
- SignatureInfo ::= SIGNATURE-INFO-TYPE TLV-LENGTH
- SignatureType
- KeyLocator?
+ SignatureInfo = SIGNATURE-INFO-TYPE TLV-LENGTH
+ SignatureType
+ [KeyLocator]
- SignatureValue ::= SIGNATURE-VALUE-TYPE TLV-LENGTH
- BYTE+
+ SignatureValue = SIGNATURE-VALUE-TYPE TLV-LENGTH *OCTET
.. _InterestSignature:
@@ -41,15 +39,16 @@
::
- InterestSignatureInfo ::= INTEREST-SIGNATURE-INFO-TYPE TLV-LENGTH
- SignatureType
- KeyLocator?
- SignatureNonce?
- SignatureTime?
- SignatureSeqNum?
+ InterestSignature = InterestSignatureInfo InterestSignatureValue
- InterestSignatureValue ::= INTEREST-SIGNATURE-VALUE-TYPE TLV-LENGTH
- BYTE+
+ InterestSignatureInfo = INTEREST-SIGNATURE-INFO-TYPE TLV-LENGTH
+ SignatureType
+ [KeyLocator]
+ [SignatureNonce]
+ [SignatureTime]
+ [SignatureSeqNum]
+
+ InterestSignatureValue = INTEREST-SIGNATURE-VALUE-TYPE TLV-LENGTH *OCTET
Signature Elements
------------------
@@ -59,8 +58,7 @@
::
- SignatureType ::= SIGNATURE-TYPE-TYPE TLV-LENGTH
- nonNegativeInteger
+ SignatureType = SIGNATURE-TYPE-TYPE TLV-LENGTH nonNegativeInteger
This specification defines the following SignatureType values:
@@ -94,9 +92,9 @@
::
- KeyLocator ::= KEY-LOCATOR-TYPE TLV-LENGTH (Name | KeyDigest)
+ KeyLocator = KEY-LOCATOR-TYPE TLV-LENGTH (Name / KeyDigest)
- KeyDigest ::= KEY-DIGEST-TYPE TLV-LENGTH BYTE+
+ KeyDigest = KEY-DIGEST-TYPE TLV-LENGTH *OCTET
See :ref:`Name specification <Name>` for the definition of Name field.
@@ -112,8 +110,9 @@
::
- SignatureNonce ::= SIGNATURE-NONCE-TYPE TLV-LENGTH(=4)
- BYTE{4}
+ SignatureNonce = SIGNATURE-NONCE-TYPE
+ TLV-LENGTH ; == 4
+ 4OCTET
The ``SignatureNonce`` element adds additional assurances that a signature will be unique.
@@ -125,8 +124,7 @@
::
- SignatureTime ::= SIGNATURE-TIME-TYPE TLV-LENGTH
- nonNegativeInteger
+ SignatureTime = SIGNATURE-TIME-TYPE TLV-LENGTH nonNegativeInteger
The value of the ``SignatureTime`` element is the signature's timestamp (in terms of milliseconds since 1970-01-01 00:00:00 UTC) encoded as nonNegativeInteger.
@@ -139,8 +137,7 @@
::
- SignatureSeqNum ::= SIGNATURE-SEQ-NUM-TYPE TLV-LENGTH
- nonNegativeInteger
+ SignatureSeqNum = SIGNATURE-SEQ-NUM-TYPE TLV-LENGTH nonNegativeInteger
The ``SignatureSeqNum`` element adds additional assurances that a signature will be unique.
@@ -171,13 +168,14 @@
::
- SignatureValue ::= SIGNATURE-VALUE-TYPE TLV-LENGTH(=32)
- BYTE+(=SHA256{Name, MetaInfo, Content, SignatureInfo})
+ SignatureValue = SIGNATURE-VALUE-TYPE
+ TLV-LENGTH ; == 32
+ 32OCTET ; == SHA256{Name, MetaInfo, Content, SignatureInfo}
- InterestSignatureValue ::= INTEREST-SIGNATURE-VALUE-TYPE TLV-LENGTH(=32)
- BYTE+(=SHA256{Name(without T, L, and ParametersSha256DigestComponent),
- ApplicationParameters,
- InterestSignatureInfo})
+ InterestSignatureValue = INTEREST-SIGNATURE-VALUE-TYPE
+ TLV-LENGTH ; == 32
+ 32OCTET ; == SHA256{Name(without T, L, and ParametersSha256DigestComponent),
+ ; ApplicationParameters, InterestSignatureInfo}
.. _SignatureSha256WithRsa:
@@ -192,17 +190,16 @@
::
- SignatureValue ::= SIGNATURE-VALUE-TYPE TLV-LENGTH
- BYTE+(=RSA over SHA256{Name, MetaInfo, Content, SignatureInfo})
+ SignatureValue = SIGNATURE-VALUE-TYPE TLV-LENGTH
+ *OCTET ; == RSA over SHA256{Name, MetaInfo, Content, SignatureInfo}
- InterestSignatureValue ::= INTEREST-SIGNATURE-VALUE-TYPE TLV-LENGTH(=32)
- BYTE+(=RSA over SHA256{Name(without T, L, and ParametersSha256DigestComponent),
- ApplicationParameters,
- InterestSignatureInfo})
+ InterestSignatureValue = INTEREST-SIGNATURE-VALUE-TYPE TLV-LENGTH
+ *OCTET ; == RSA over SHA256{Name(without T, L, and ParametersSha256DigestComponent),
+ ApplicationParameters, InterestSignatureInfo}
.. note::
- SignatureValue size varies (typically 128 or 256 bytes) depending on the private key length used during the signing process.
+ The TLV-LENGTH of these elements varies (typically 128 or 256 bytes) depending on the private key length used during the signing process.
This type of signature ensures strict provenance of a Data packet, provided that the signature verifies and signature issuer is authorized to sign the Data packet.
The signature issuer is identified using :ref:`KeyLocator` block in :ref:`SignatureInfo <Signature>` block of ``SignatureSha256WithRsa``.
@@ -228,24 +225,23 @@
::
- SignatureValue ::= SIGNATURE-VALUE-TYPE TLV-LENGTH
- BYTE+(=ECDSA over SHA256{Name, MetaInfo, Content, SignatureInfo})
+ SignatureValue = SIGNATURE-VALUE-TYPE TLV-LENGTH
+ *OCTET ; == ECDSA over SHA256{Name, MetaInfo, Content, SignatureInfo}
- InterestSignatureValue ::= INTEREST-SIGNATURE-VALUE-TYPE TLV-LENGTH(=32)
- BYTE+(=ECDSA over SHA256{Name(without T, L, and ParametersSha256DigestComponent),
- ApplicationParameters,
- InterestSignatureInfo})
+ InterestSignatureValue = INTEREST-SIGNATURE-VALUE-TYPE TLV-LENGTH
+ *OCTET ; == ECDSA over SHA256{Name(without T, L, and ParametersSha256DigestComponent),
+ ApplicationParameters, InterestSignatureInfo}
.. note::
- The SignatureValue size depends on the private key length used during the signing process (about 63 bytes for a 224 bit key).
+ The TLV-LENGTH of these elements depends on the elliptic curve used during the signing process (about 63 bytes for a 224 bit key).
This type of signature ensures strict provenance of a Data packet, provided that the signature verifies and the signature issuer is authorized to sign the Data packet.
The signature issuer is identified using the :ref:`KeyLocator` block in the :ref:`SignatureInfo <Signature>` block of the ``SignatureSha256WithEcdsa``.
KeyDigest option in ``KeyLocator`` is defined as SHA256 digest over the DER encoding of the SubjectPublicKeyInfo for an EC key as defined by `RFC 5480 <http://www.ietf.org/rfc/rfc5480.txt>`_.
See the :ref:`KeyLocator section <KeyLocator>` for more detail.
-The value of ``SignatureValue`` of ``SignatureSha256WithEcdsa`` is a DER encoded DSA signature as defined in `Section 2.2.3 in RFC 3279 <http://tools.ietf.org/html/rfc3279#section-2.2.3>`_.
+The value of ``SignatureValue`` of ``SignatureSha256WithEcdsa`` is a DER encoded ECDSA signature as defined in `Section 2.2.3 in RFC 3279 <http://tools.ietf.org/html/rfc3279#section-2.2.3>`_.
::
@@ -266,13 +262,14 @@
::
- SignatureValue ::= SIGNATURE-VALUE-TYPE TLV-LENGTH(=32)
- BYTE+(=HMAC{Name, MetaInfo, Content, SignatureInfo})
+ SignatureValue = SIGNATURE-VALUE-TYPE
+ TLV-LENGTH ; == 32
+ 32OCTET ; == HMAC{Name, MetaInfo, Content, SignatureInfo}
- InterestSignatureValue ::= INTEREST-SIGNATURE-VALUE-TYPE TLV-LENGTH(=32)
- BYTE+(=HMAC{Name(without T, L, and ParametersSha256DigestComponent),
- ApplicationParameters,
- InterestSignatureInfo})
+ InterestSignatureValue = INTEREST-SIGNATURE-VALUE-TYPE
+ TLV-LENGTH ; == 32
+ 32OCTET ; == HMAC{Name(without T, L, and ParametersSha256DigestComponent),
+ ApplicationParameters, InterestSignatureInfo}
.. note::
@@ -286,4 +283,4 @@
The shared key used to generate HMAC signature can be identified by the :ref:`KeyLocator` block in :ref:`SignatureInfo <Signature>`, e.g., by using the ``Name`` according to application's naming conventions.
It is the application's responsibility to establish association between the shared key and the identities of the parties who hold the shared key.
-.. bibliography:: ndnspec-refs.bib
\ No newline at end of file
+.. bibliography:: ndnspec-refs.bib
diff --git a/signed-interest.rst b/signed-interest.rst
index 63ad44b..9043551 100644
--- a/signed-interest.rst
+++ b/signed-interest.rst
@@ -5,22 +5,12 @@
**Signed Interest** is a mechanism to issue an authenticated Interest.
-::
+A signed Interest is an Interest where:
- SignedInterest ::= INTEREST-TYPE TLV-LENGTH
- Name (must end with ParametersSha256DigestComponent)
- CanBePrefix?
- MustBeFresh?
- ForwardingHint?
- Nonce?
- InterestLifetime?
- HopLimit?
- ApplicationParameters
- InterestSignatureInfo
- InterestSignatureValue
+* Name ends with ``ParametersSha256DigestComponent``.
+* ``InterestSignature`` is present.
-
-See :ref:`Interest Signature section <InterestSignature>` for details of ``InterestSignatureInfo`` and ``InterestSignatureValue``.
+See :ref:`Interest Signature section <InterestSignature>` for details on ``InterestSignature``.
Construction of Signed Interest
-------------------------------
@@ -84,4 +74,4 @@
Update `s0` to `s` if the signed Interest has been validated according to this and all other rules.
.. note::
- The first ``SignatureSeqNum`` received is considered valid only if it satisfies the application's policy. For example, application can decide the first ``SeqNum`` can only be a minimum value like 0 or 1, or a value that both sender and receiver agree on.
\ No newline at end of file
+ The first ``SignatureSeqNum`` received is considered valid only if it satisfies the application's policy. For example, application can decide the first ``SeqNum`` can only be a minimum value like 0 or 1, or a value that both sender and receiver agree on.
diff --git a/tlv.rst b/tlv.rst
index 38d5e39..4e294ec 100644
--- a/tlv.rst
+++ b/tlv.rst
@@ -21,60 +21,20 @@
We define a variable-length encoding for numbers in NDN as follows::
- VAR-NUMBER := BYTE+
+ VAR-NUMBER = %x00-FC / %xFD 2OCTET / %xFE 4OCTET / %xFF 8OCTET
The first octet of the number either carries the actual number, or signals that a multi-octet encoding is present, as defined below:
-- if the first octet is < 253, the number is encoded in that octet;
+- if the first octet is less than or equal to 252 (0xFC), the number is encoded in that octet;
-- if the first octet == 253, the number is encoded in the
- following 2 octets, in net byte-order;
+- if the first octet is 253 (0xFD), the number is encoded in the following 2 octets, in network byte-order;
-- if the first octet == 254, the number is encoded in the
- following 4 octets, in net byte-order;
+- if the first octet is 254 (0xFE), the number is encoded in the following 4 octets, in network byte-order;
-- if the first octet == 255, the number is encoded in the
- following 8 octets, in net byte-order.
+- if the first octet is 255 (0xFF), the number is encoded in the following 8 octets, in network byte-order.
-
-One-octet number::
-
- 0 1 2 3 4 5 6 7
- +----------------+
- | < 253 = NUMBER |
- +----------------+
-
-
-Two-octet number::
-
- 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
- +---------------+---------------+---------------+
- | 253 | NUMBER (MSB) NUMBER (LSB) |
- +---------------+---------------+---------------+
-
-Four-octet number::
-
- 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +---------------+---------------+----------------+--------------+
- | 254 | NUMBER (MSB) /
- +---------------+---------------+----------------+--------------+
- | NUMBER (LSB) |
- +---------------+
-
-Eight-octet number::
-
- 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +---------------+---------------+----------------+--------------+
- | 255 | NUMBER (MSB) /
- +---------------+ +
- | /
- + +---------------+----------------+--------------+
- | NUMBER (LSB) |
- +---------------+
-
+.. note::
+ The formal grammar of NDN packet format in this specification is given using `Augmented BNF for Syntax Specifications <https://tools.ietf.org/html/rfc5234>`__
.. _TLV:
@@ -83,11 +43,10 @@
TLV encoding for NDN packets is defined as follows::
- NDN-TLV := TLV-TYPE TLV-LENGTH TLV-VALUE?
- TLV-TYPE := VAR-NUMBER
- TLV-LENGTH := VAR-NUMBER
- TLV-VALUE := BYTE+
-
+ NDN-TLV = TLV-TYPE TLV-LENGTH TLV-VALUE
+ TLV-TYPE = VAR-NUMBER
+ TLV-LENGTH = VAR-NUMBER
+ TLV-VALUE = *OCTET
TLV-TYPE MUST be in the range ``1-4294967295`` (inclusive).
Zero is reserved to indicate an invalid TLV element and MUST NOT appear on the wire.
@@ -104,20 +63,20 @@
Non Negative Integer Encoding
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-A number of TLV elements in NDN packet format take a non-negative integer as their value, with the following definition::
+A number of TLV elements in NDN packet format take a non-negative integer as their TLV-VALUE, with the following definition::
- nonNegativeInteger ::= BYTE{1} | BYTE{2} | BYTE{4} | BYTE{8}
+ nonNegativeInteger = 1OCTET / 2OCTET / 4OCTET / 8OCTET
TLV-LENGTH of the TLV element MUST be either 1, 2, 4, or 8.
Depending on TLV-LENGTH, a nonNegativeInteger is encoded as follows:
-- if the length is 1 (i.e. the value length is 1 octet), the nonNegativeInteger is encoded in one octet;
+- if the length is 1, the nonNegativeInteger is encoded in one octet;
-- if the length is 2 (= value length is 2 octets), the nonNegativeInteger is encoded in 2 octets, in net byte-order;
+- if the length is 2, the nonNegativeInteger is encoded in 2 octets, in network byte-order;
-- if the length is 4 (= value length is 4 octets), the nonNegativeInteger is encoded in 4 octets, in net byte-order;
+- if the length is 4, the nonNegativeInteger is encoded in 4 octets, in network byte-order;
-- if the length is 8 (= value length is 8 octets), the nonNegativeInteger is encoded in 8 octets, in net byte-order.
+- if the length is 8, the nonNegativeInteger is encoded in 8 octets, in network byte-order.
The following shows a few examples of TLVs that have nonNegativeInteger as their value component in hexadecimal format (where ``TT`` represents ``TLV-TYPE``, followed by the ``TLV-LENGTH``, then ``TLV-VALUE``)::
diff --git a/types.rst b/types.rst
index 4f6c314..608b16e 100644
--- a/types.rst
+++ b/types.rst
@@ -82,6 +82,10 @@
| Preference | 30 | 0x1e |
+---------------------------------------------+------------------+-----------------+
+.. note::
+ ABNF grammar of this specification denotes TLV-TYPE of element X as ``X-TYPE``.
+ For example, ``INTEREST-TYPE`` means ``%x05``, the TLV-TYPE of ``Interest`` encoded as ``VAR-NUMBER``.
+
.. _type reservations:
TLV-TYPE number reservations