[Ndn-interest] any comments on naming convention?

[Marc.Mosko at parc.com]

If you want to keep exclusions, and to some extent left/right-most child, I think you only have a few options.  For example, how do I exclude a version component but not a binary component with the same bytes?  Are you going to add a MarkedComponent option to each exclusion predicate?

1) Use one “T” then always use a (key=value) pair in the name component of every name component.  This is a TLKV encoding.
2) Ditch TLV for name components, use a run-length encoding L(key=value) (LKV encoding), the exclude will include the “KV” as the “NameComponent”.
3) Use #2 with the observation that it’s really LTV encoding by another name.
4) Use one “T” and use the “_v/…” name component pairs.
5) Use MarkedComponents and extend the exclusion predicate to include the type.
6) Don’t use exclusions (the ccnx 1.0 option)

It is not straightforward to include the type directly in the exclusion if you use multiple "T" TLV encoding with multiple types.  You’d need to change the grammar of the exclusion.

Exclude ::= EXCLUDE-TYPE TLV-LENGTH Any? (NameComponent (Any)?)+
Any ::= ANY-TYPE TLV-LENGTH(=0)

Did I miss anything?

Marc

On Sep 17, 2014, at 10:10 AM, Thompson, Jeff <jefft0 at remap.ucla.edu> wrote:

> Hi Junxiao,
> 
> In your MarkedComponent proposal, would you want to make the marker code fixed-length to address the concerns explained by Marc?  In other words, the desire that a shorter name component value always sorts before a longer component value, regardless of its type?  (The risk is that a shorter component value may have a marker code which encodes as a long VAR-NUMBER which would make the overall TLV longer and mess up the sorting.)
> 
> - Jeff T
> 
> From: Junxiao Shi <shijunxiao at email.arizona.edu>
> Date: Wednesday, September 17, 2014 7:46 AM
> To: "Marc.Mosko at parc.com" <Marc.Mosko at parc.com>
> Cc: "ndn-interest at lists.cs.ucla.edu" <ndn-interest at lists.cs.ucla.edu>
> Subject: Re: [Ndn-interest] any comments on naming convention?
> 
> Hi Marc
> 
> The MarkedComponent proposal <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/2014-September/000085.html> is precisely a T0/T1 system:
> T0=NameComponent
> T1=MarkedComponent
> key is encoded as variable length number (same way as T)
> This still requires all codes to distinguish between NameComponent and MarkedComponent everywhere, but we'll have exactly two types, instead of potentially many types.
> 
> However, I agree that putting the key into TLV-TYPE is better than using MarkedComponent or having a key in every component, because the processing cost isn't any different.
> 
> Yours, Junxiao
> 
> On Wed, Sep 17, 2014 at 7:36 AM, <Marc.Mosko at parc.com> wrote:
>> I think if you require all name components to have a “key=value” format, then that is an ok system, but it seems duplicative of having the TLV type.   Personally, I would then encode the “key=“ piece the same way you encode the TLV “T” (i.e. the 1/3/5 system).
>> 
>> Though it does seem rather duplicative of having the TLV type, as I said.  I think having one T (call it T0) for non-tagged and one T (call it T1) for “key=value” introduces more overhead than is needed, as you now have two type systems for one value.  You will need to keep the T0/T1 distinction everywhere in the code so you know if there is a “key=“ embedded in the name.  Programmatically, you’ll probably need to sprout a new class or getter/setter for the “key=“ for those types.  It seems simpler to me for the TLV “T” to always be associated with a name component, so you are always working with the (T, value) pair.
>> 
>> Marc
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20140917/086123e6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2595 bytes
Desc: not available
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20140917/086123e6/attachment.bin>