<div dir="ltr"><div dir="ltr">Hi Varun<div><br></div><div>There is no fundamental difference between NDN-TLV and CBOR.</div><div>In either case, you would need to define a clear and unambiguous schema on how each object is encoded.</div><div><div><br></div><div>NDNts has already <a href="https://ndnts-docs.ndn.today/typedoc/modules/sync.html">implemented PSync and syncps</a>, and will implement SVS once your protocol is reasonably stable.</div><div><br></div><div><font size="4">Reasons for choosing CBOR</font></div><div>CBOR have a machine readable schema language (CDDL, <a href="https://tools.ietf.org/html/rfc8610" target="_blank">RFC8610</a>).</div><div>NDN-TLV only has ABNF schema definition, and this definition often depends on comments to express semantics.</div><div><br></div><div></div></div><div><font size="4">Reasons for choosing NDN-TLV</font></div><div>General purpose NDN-TLV encoder and decoder are available in most libraries.</div><div><div>CBOR would be an additional dependency, which increases code size, especially for webapps and microcontrollers.</div><div><br></div><div>If you need to encode NDN elements, such as a name or a certificate, it is natural to embed NDN-TLV inside NDN-TLV.</div><div><br></div><div></div></div><div>It <a href="https://zjkmxy.github.io/posts/2020/07/tlv-reflection/" target="_blank">has been argued </a>that NDN-TLV codec should use the "reflection" feature, if available in the programming language.</div><div>python-ndn has an implementation of this idea. Additional <a href="https://github.com/zjkmxy/ndn-encoding-test" target="_blank">experiments </a>are being done for Go.</div><div>This would make programming with NDN-TLV easier.</div><div><br></div><div>Yours, Junxiao</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 18, 2021 at 11:11 AM Varun Patil <<a href="mailto:varunpatil@ucla.edu" target="_blank">varunpatil@ucla.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p style="text-align:center"><font color="red"><strong>External Email</strong><br></font></p><div dir="ltr"><div>Hello,</div><div><br></div><div>I've been developing a StateVectorSync library (named-data/ndn-svs), and there seem to be two approaches to encoding the state vector:</div><div><br></div><div>1. An NDN custom TLV.</div><div><br></div><div>2. A standardised serializer. Currently the library uses boost-serialization, but I'm in favor of CBOR (RFC 8949, Standards Track, Dec. 2020). This would make it easier to write compatible SVS libraries in other languages, since CBOR decoders are already available in virtually every language (also it may be more space efficient than custom TLV blocks).</div><div><br></div><div>Any thoughts/suggestions on which is the better approach?</div><div><br></div><div>Thanks,</div><br clear="all"><div><div dir="ltr"><div dir="ltr"><div>Varun Patil</div><div>Graduate Student</div><div>Computer Science, UCLA<br></div></div></div></div></div><br>
</blockquote></div></div>