| Alexander Afanasyev | a6fc727 | 2014-06-13 11:58:06 -0700 | [diff] [blame] | 1 | Changes |
| 2 | ======= |
| 3 | |
| Junxiao Shi | a0d3682 | 2014-09-21 11:32:09 -0700 | [diff] [blame] | 4 | Since version 0.1.1 |
| 5 | ------------------- |
| 6 | |
| 7 | - **Name** |
| 8 | |
| 9 | + Allow zero-length name component |
| Alexander Afanasyev | 4b8be21 | 2014-10-06 10:55:04 -0700 | [diff] [blame^] | 10 | + Require implicit digest to be specified using ``ImplicitSha256Digest`` name component |
| Junxiao Shi | a0d3682 | 2014-09-21 11:32:09 -0700 | [diff] [blame] | 11 | |
| Alexander Afanasyev | a6fc727 | 2014-06-13 11:58:06 -0700 | [diff] [blame] | 12 | Since version 0.1 |
| 13 | ----------------- |
| 14 | |
| 15 | - **Signature** |
| 16 | |
| Alexander Afanasyev | 4b89611 | 2014-06-23 21:47:15 -0700 | [diff] [blame] | 17 | + New ``SignatureSha256WithEcdsa`` signature type for Elliptic Curve Digital Signature Algorithm (ECDSA). |
| Alexander Afanasyev | f3e5e85 | 2014-06-13 22:44:02 -0700 | [diff] [blame] | 18 | + ``KeyLocatorDigest`` renamed to ``KeyDigest``. The specification now explicitly allows KeyDigest to be a SHA256 of any type of the key. |
| Alexander Afanasyev | 4b89611 | 2014-06-23 21:47:15 -0700 | [diff] [blame] | 19 | + ``KeyLocator`` field is now defined to be optionally present in generic ``SignatureInfo`` block. |
| 20 | ``SignatureSha256WithRsa`` and ``SignatureSha256WithEcdsa`` still require ``KeyLocator`` to be always present. |
| Alexander Afanasyev | a6fc727 | 2014-06-13 11:58:06 -0700 | [diff] [blame] | 21 | |
| 22 | Since CCNx 0.7.2 |
| 23 | ---------------- |
| 24 | |
| 25 | - **General** |
| 26 | |
| 27 | + XML-based ccnb packet encoding is replaced by TLV encoding |
| 28 | |
| 29 | - **Name** |
| 30 | |
| 31 | + The name encoding is changed from binary XML to TLV format |
| 32 | + 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 |
| 33 | + Deprecated zero-length name component |
| 34 | |
| 35 | - **Interest Packet** |
| 36 | |
| 37 | + ``Nonce`` is changed from optional to required |
| 38 | + ``PublisherPublicKeyDigest`` is replaced by ``PublisherPublicKeyLocator`` |
| 39 | + ``AnswerOriginKind`` is simplified from 4bits to a 1-bit ``MustBeFresh`` |
| 40 | + ``FaceID`` has been removed |
| 41 | + ``InterestLifetime`` changes the unit to the number of milliseconds |
| 42 | + Removed Bloom Filter from Exclude |
| 43 | + Changed default semantics of staleness |
| 44 | |
| 45 | 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. |
| 46 | With Binary XML encoded Interests, the default behavior was to bring "fresh" data and return "stale" data only when ``AnswerOriginKind`` was set to 3. |
| 47 | |
| 48 | Application developers must be aware of this change, reexamine the Interest expression code, and enable ``MustBeFresh`` selector when necessary. |
| 49 | |
| 50 | - **Data Packet** |
| 51 | |
| 52 | + The structure of Data packet is changed: |
| 53 | |
| 54 | * ``Name``, ``MetaInfo``, ``Content``, ``Signature{SignatureInfo, SignatureValue}`` |
| 55 | |
| 56 | + ``SignedInfo`` is renamed to ``MetaInfo`` and its content is changed |
| 57 | + ``PublisherPublicKeyDigest`` and ``ExtOpt`` are removed. |
| 58 | + ``Timestamp`` is removed |
| 59 | + ``KeyLocator`` is moved to be inside the ``Signature`` (``SignatureInfo``) block |
| 60 | + Three content types, ENCR, GONE, and NACK are removed |
| 61 | + ``FreshnessSeconds`` is renamed to ``FreshnessPeriod`` and is expressed in units of milliseconds |
| 62 | |
| 63 | - **Signature** |
| 64 | |
| 65 | + ``Signature`` is moved to the end of Data packet. |
| 66 | + ``KeyLocator`` is moved to be a part of the ``SignatureInfo`` block, if it is applicable for the specific signature type. |
| 67 | |
| 68 | The rationale for the move is to make Signature (sequence of ``SignatureInfo`` and ``SignatureValue`` TLVs) self-contained and self-sufficient. |
| 69 | |
| 70 | + Signature type (or signing method information) is expressed as an assigned integer value (with no assumed default), rather than OID. |
| 71 | + Added support for hash-only "signature" |
| 72 | + 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 |