[Ndn-interest] any comments on naming convention?

[Tai-Lin Chu]

Summarize all types that people need (feel free to add some, and paste
in your reply)
- regular
- segment
- version (timestamp)
- signature
- key: assuming that the next regular component will be value. The
value is empty if it sees another key component immediately after.
- app-specific


However, I am not convinced that we need version, signature, and
app-specific as typed component. Will these change how packet routes?



On Tue, Sep 16, 2014 at 8:47 AM, Junxiao Shi
<shijunxiao at email.arizona.edu> wrote:
> Hi Jeff
>
> Please see my proposal of MarkedComponent
> <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/2014-September/000085.html>,
> which is a solution to eliminate ambiguity by defining a new type
> specifically for key-value pair.
>
> Yours, Junxiao
>
> On Tue, Sep 16, 2014 at 8:18 AM, Burke, Jeff <jburke at remap.ucla.edu> wrote:
>>
>>
>> Second, if the most important issue is eliminating ambiguity/aliasing,
>> then why not define a new type that hints that the component can be
>> interpreted as a key/value pair with some encoding convention?  This could
>> enable an unambiguous, short list of commonly used conventions that you've
>> mentioned (using marker-like keys),  while keeping information describing
>> the data object in the name. It would also be very useful for applications
>> that desire their own k/v representation for components, which Dave has
>> argued for in other circumstances and we keep running across. It doesn't
>> rule out use of hierarchy, and doesn't limit what an application defined
>> keys could be.  Yet, it could be ignored in forwarding (just another
>> component) and perhaps have a still-meaningful sort order (key, then
>> value).
>>
>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>