<div dir="ltr"><div dir="ltr"></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Both NDN-TLV and CBOR can be considered "standardized" in the context of NDN applications.</div></div></blockquote><div>Hmm, alright.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>You can choose either one, but you should write down the schema first. In other words, CBOR is not an excuse for not writing the schema.</div></div></blockquote><div>At least for my use case, there isn't a schema - I just need to encode an unordered_map<string, int>. Which is why CBOR seemed ideal.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>Caution: not every CBOR implementation supports every CBOR feature. Thus, it may end up being more complicated than NDN-TLV.<br></div></div></div></blockquote><div>Ah didn't consider this. I guess NDN-TLV seems like a more consistent solution to go with then.</div><div><br></div><div>Thanks again.</div><div><br></div><div>Best,</div><div>Varun</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div></div><div><br></div><div>Sidenode: I've used CBOR in the past. See my name on <a href="https://github.com/PelionIoT/cbor-sync" target="_blank">https://github.com/PelionIoT/cbor-sync</a> and <a href="https://github.com/bergos/ArduinoCbor" target="_blank">https://github.com/bergos/ArduinoCbor</a> .</div></div><br><div>Yours, Junxiao<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 20, 2021 at 6:49 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"><b>External Email</b><br></font></p><div dir="auto"><div dir="auto">Hi Junxiao,</div><div dir="auto"><br></div><div dir="auto">Thanks for the (very insightful) reply.</div><div dir="auto"><br></div><div dir="auto">If I understand correctly, both reasons to choose NDN-TLV have to do with not adding a dependency.</div><div dir="auto">My argument for CBOR is similar to the reason we use JSON over arbitrary formats - a highly standardised encoding will give better results in the long term.</div><div dir="auto">But on the other hand it introduces inconsistency, so I will stick with NDN-TLV unless there is more encouragement from the community that we want to try out a new standard.</div><div dir="auto"><br></div><div dir="auto">Any other thoughts?</div><div dir="auto"><br></div><div dir="auto">Thanks,</div><div dir="auto"><br></div><div dir="auto">Varun</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 20, 2021, 12:31 AM Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu" target="_blank">shijunxiao@email.arizona.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"><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" rel="noreferrer" target="_blank">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" rel="noreferrer" 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/" rel="noreferrer" 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" rel="noreferrer" 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" rel="noreferrer" 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"><b>External Email</b><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></blockquote></div></blockquote></div></div>
</blockquote></div></div>