blob: 5895c8b3ff14de6054a4c6323268d249305bfa29 [file] [log] [blame]
Alexander Afanasyeva6fc7272014-06-13 11:58:06 -07001Changes
2=======
3
Junxiao Shia0d36822014-09-21 11:32:09 -07004Since version 0.1.1
5-------------------
6
7- **Name**
8
9 + Allow zero-length name component
Alexander Afanasyev4b8be212014-10-06 10:55:04 -070010 + Require implicit digest to be specified using ``ImplicitSha256Digest`` name component
Junxiao Shia0d36822014-09-21 11:32:09 -070011
Alexander Afanasyev948affe2016-09-13 13:15:29 -070012- **Signature**
13
14 + Add spec for ``SignatureHmacWithSha256``
15
Junxiao Shidef7fc52015-06-10 13:29:21 -070016- **Interest**
17
18 + Delete deprecated ``Scope`` guider
Alexander Afanasyev948affe2016-09-13 13:15:29 -070019 + Restrict Interest to have name with at least one name component
20
21- **Data**
22
23 + Redirect ContentType number assignments to the `wiki page <https://redmine.named-data.net/projects/ndn-tlv/wiki/ContentType>`__
Junxiao Shidef7fc52015-06-10 13:29:21 -070024
Junxiao Shi4406fdd2015-06-10 13:28:10 -070025- **TLV-TYPE**
26
27 + Reserve 800-1000 range for link protocol
28
Alexander Afanasyeva6fc7272014-06-13 11:58:06 -070029Since version 0.1
30-----------------
31
32- **Signature**
33
Alexander Afanasyev4b896112014-06-23 21:47:15 -070034 + New ``SignatureSha256WithEcdsa`` signature type for Elliptic Curve Digital Signature Algorithm (ECDSA).
Alexander Afanasyevf3e5e852014-06-13 22:44:02 -070035 + ``KeyLocatorDigest`` renamed to ``KeyDigest``. The specification now explicitly allows KeyDigest to be a SHA256 of any type of the key.
Alexander Afanasyev4b896112014-06-23 21:47:15 -070036 + ``KeyLocator`` field is now defined to be optionally present in generic ``SignatureInfo`` block.
37 ``SignatureSha256WithRsa`` and ``SignatureSha256WithEcdsa`` still require ``KeyLocator`` to be always present.
Alexander Afanasyeva6fc7272014-06-13 11:58:06 -070038
39Since CCNx 0.7.2
40----------------
41
42- **General**
43
44 + XML-based ccnb packet encoding is replaced by TLV encoding
45
46- **Name**
47
48 + The name encoding is changed from binary XML to TLV format
49 + The discussions on naming conventions and the use of special markers inside NameComponents are removed from packet specification, and will be covered by a separate technical document
50 + Deprecated zero-length name component
51
52- **Interest Packet**
53
54 + ``Nonce`` is changed from optional to required
55 + ``PublisherPublicKeyDigest`` is replaced by ``PublisherPublicKeyLocator``
56 + ``AnswerOriginKind`` is simplified from 4bits to a 1-bit ``MustBeFresh``
57 + ``FaceID`` has been removed
58 + ``InterestLifetime`` changes the unit to the number of milliseconds
59 + Removed Bloom Filter from Exclude
60 + Changed default semantics of staleness
61
62 Specifically, NDN-TLV Interest without any selectors will bring any data that matches the name, and only when ``MustBeFresh`` selector is enabled it will try to honor freshness, specified in Data packets.
63 With Binary XML encoded Interests, the default behavior was to bring "fresh" data and return "stale" data only when ``AnswerOriginKind`` was set to 3.
64
65 Application developers must be aware of this change, reexamine the Interest expression code, and enable ``MustBeFresh`` selector when necessary.
66
67- **Data Packet**
68
69 + The structure of Data packet is changed:
70
71 * ``Name``, ``MetaInfo``, ``Content``, ``Signature{SignatureInfo, SignatureValue}``
72
73 + ``SignedInfo`` is renamed to ``MetaInfo`` and its content is changed
74 + ``PublisherPublicKeyDigest`` and ``ExtOpt`` are removed.
75 + ``Timestamp`` is removed
76 + ``KeyLocator`` is moved to be inside the ``Signature`` (``SignatureInfo``) block
77 + Three content types, ENCR, GONE, and NACK are removed
78 + ``FreshnessSeconds`` is renamed to ``FreshnessPeriod`` and is expressed in units of milliseconds
79
80- **Signature**
81
82 + ``Signature`` is moved to the end of Data packet.
83 + ``KeyLocator`` is moved to be a part of the ``SignatureInfo`` block, if it is applicable for the specific signature type.
84
85 The rationale for the move is to make Signature (sequence of ``SignatureInfo`` and ``SignatureValue`` TLVs) self-contained and self-sufficient.
86
87 + Signature type (or signing method information) is expressed as an assigned integer value (with no assumed default), rather than OID.
88 + Added support for hash-only "signature"
89 + The current specification does not define Merkle Hash Tree Aggregated Signatures, but it is expected that such (or similar) signatures will be defined in future version of this specification