Subject: [icnrg] Fwd: Suggestion

From: Hatem Ibn_Khedher <[email-masked]>
Date: Fri, 17 Mar 2017 14:54:14 +0100 (CET)

----- Mail transféré -----

De: "Hatem Ibn_Khedher" <[email-masked]> 
À: [email-masked] 
Envoyé: Jeudi 16 Mars 2017 16:24:06 
Objet: Suggestion 

Dear Van, 

Through ICN paradigm, you are proposing to put the content within a name (Ravist) and sign the whole name. Then, you send the data. 

We can found a solution for the signature overhead using Mercle Hash Tree (for example). However, is it a scalable process when putting the name on each data packet ? 

We suggest ICN compression header ? what do you think ? 

Best Regards, 
Hatem

---

From: Lixia Zhang <[email-masked]>
Date: Fri, 17 Mar 2017 08:52:54 -0700

> On Mar 17, 2017, at 6:54 AM, Hatem Ibn_Khedher <[email-masked]> wrote:

I doubt Van is on this mailing list, so please allow me to throw in my 2 cents here: 
- the question below seems implying very long data names, thus worth the
  added cost of compression (not just the computation but also additional protocol
  complexity).
- but does this assumption (of necessarily long names) necessarily hold true? 
  e.g. locally we’ve been working with someone who uses NDN in constrained environment
  with very small packets, so data names are short too.

It seems to me there is a popular (mis)conception that data names would be coded in ASCII (hence long); this might have comes from another (mis)conception of data names being "human readable". 
My understanding is that ICN data names should be semantically meaningful to the apps.

Lixia

> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg