<div dir="auto">Hi Zhiyi<div dir="auto"><br></div><div dir="auto">Have you figured out why the CA isn't responding?</div><div dir="auto">I attached packet samples so you can replay them onto your node.</div><div dir="auto"><br></div><div dir="auto">Yours, Junxiao</div><br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Tue, Nov 5, 2019, 17:25 Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu">shijunxiao@email.arizona.edu</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><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" target="_blank" rel="noreferrer">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" target="_blank" rel="noreferrer">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" target="_blank" rel="noreferrer">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" target="_blank" rel="noreferrer">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></div>
</blockquote></div></div>