<div dir="ltr"><div>Hi Zhiyi</div><div><br></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>Sorry. but to be honest, I don't know why the client will have invalid last component. (my clinet code simply runs setApplicationParameter(), no more function calls).</div></div></blockquote><div><br></div><div>I guess it's because I'm running the client from your <a href="https://github.com/Zhiyi-Zhang/ndncert">personal repo</a>, designed to work with ndn-cxx-0.6.6, which does not append ParametersDigestSha256Component.</div><div>However, my other program appends ParametersDigestSha256Component properly, and I have verified against latest ndn-cxx that the digest is correct.</div><div><br></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>Regarding the CA does not reply, I guess it may be the JSON format problem (if you generate the JSON on your own)?  I recalled in last hackathon, Alex met the similar issue. They said some weird newlines are added to the JSON file generated by the BOOST library. </div></div></blockquote><div><br></div><div>According to <a href="https://tools.ietf.org/html/rfc8259#section-2">RFC8259 section 2</a>, </div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_quote"><div>Insignificant whitespace is allowed before or after any of the six structural characters.</div></div></blockquote><div class="gmail_quote"><div>Therefore, it's not wrong to add "weird newlines", as they will be ignored by a decoder.</div><div> </div><div>ApplicationParameters element (including T,L,V) is:<br></div><div><br></div><div><font face="monospace">0000   24 1f 7b 22 65 6d 61 69 6c 22 3a 22 53 75 73 65   $.{"email":"Suse<br>0010   6e 74 65 72 40 64 61 79 72 65 70 2e 63 6f 6d 22   <a href="mailto:nter@dayrep.com">nter@dayrep.com</a>"<br>0020   7d                                                }</font><br></div><div><br></div><div>The JSON payload is handwritten. It is not generated by BOOST library.</div><div></div><div><br></div><div>Interpreting the TLV-VALUE using <a href="https://tools.ietf.org/html/rfc8259">RFC8259</a>, we can see that it represents a JSON object that contains a key "email".</div><div><br></div><div>As specified in NDNCERT protocol:</div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_quote"><div>JSON format: The format depends on the probe of the configuration file. As an example, if we have "probe":"email:full-name", then the JSON file carried in the PROBE Interest will contains two attributes: email and full-name.</div></div></blockquote><div class="gmail_quote"><div><br></div><div>As seen in <font face="monospace">/ndn/edu/ucla/yufeng/CA/_PROBE/INFO</font> packet (frame 5 in <a href="https://www.lists.cs.ucla.edu/pipermail/nfd-dev/2019-November/003861.html">packet sample</a>), the CA expects PROBE parameters to have "email" key.</div><div>Therefore, I believe my Interest satisfies the schema shown on the protocol page.</div><div><br></div><div>Yours, Junxiao</div></div></div>