[Ndn-interest] any comments on naming convention?

[Massimo Gallo]

Indeed each components' offset must be encoded using a fixed amount of 
bytes:

i.e.,
Type = Offsets
Length = 10 Bytes
Value = Offset1(1byte), Offset2(1byte), ...

You may also imagine to have a "Offset_2byte" type if your name is too long.

Max

On 18/09/2014 09:27, Tai-Lin Chu wrote:
>> if you do not need the entire hierarchal structure (suppose you only want the first x components) you can directly have it using the offsets. With the Nested TLV structure you have to iteratively parse the first x-1 components. With the offset structure you cane directly access to the firs x components.
> I don't get it. What you described only works if the "offset" is
> encoded in fixed bytes. With varNum, you will still need to parse x-1
> offsets to get to the x offset.
>
>
>
> On Wed, Sep 17, 2014 at 11:57 PM, Massimo Gallo
> <massimo.gallo at alcatel-lucent.com> wrote:
>> On 17/09/2014 14:56, Mark Stapp wrote:
>>> ah, thanks - that's helpful. I thought you were saying "I like the
>>> existing NDN UTF8 'convention'." I'm still not sure I understand what you
>>> _do_ prefer, though. it sounds like you're describing an entirely different
>>> scheme where the info that describes the name-components is ... someplace
>>> other than _in_ the name-components. is that correct? when you say "field
>>> separator", what do you mean (since that's not a "TL" from a TLV)?
>> Correct.
>> In particular, with our name encoding, a TLV indicates the name hierarchy
>> with offsets in the name and other TLV(s) indicates the offset to use in
>> order to retrieve special components.
>> As for the field separator, it is something like "/". Aliasing is avoided as
>> you do not rely on field separators to parse the name; you use the "offset
>> TLV " to do that.
>>
>> So now, it may be an aesthetic question but:
>>
>> if you do not need the entire hierarchal structure (suppose you only want
>> the first x components) you can directly have it using the offsets. With the
>> Nested TLV structure you have to iteratively parse the first x-1 components.
>> With the offset structure you cane directly access to the firs x components.
>>
>> Max
>>
>>
>>> -- Mark
>>>
>>> On 9/17/14 6:02 AM, Massimo Gallo wrote:
>>>> The why is simple:
>>>>
>>>> You use a lot of "generic component type" and very few "specific
>>>> component type". You are imposing types for every component in order to
>>>> handle few exceptions (segmentation, etc..). You create a rule (specify
>>>> the component's type ) to handle exceptions!
>>>>
>>>> I would prefer not to have typed components. Instead I would prefer to
>>>> have the name as simple sequence bytes with a field separator. Then,
>>>> outside the name, if you have some components that could be used at
>>>> network layer (e.g. a TLV field), you simply need something that
>>>> indicates which is the offset allowing you to retrieve the version,
>>>> segment, etc in the name...
>>>>
>>>>
>>>> Max
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 16/09/2014 20:33, Mark Stapp wrote:
>>>>>
>>>>>
>>>>> On 9/16/14 10:29 AM, Massimo Gallo wrote:
>>>>>>
>>>>>> I think we agree on the small number of "component types".
>>>>>> However, if you have a small number of types, you will end up with
>>>>>> names
>>>>>> containing many generic components types and few specific components
>>>>>> types. Due to the fact that the component type specification is an
>>>>>> exception in the name, I would prefer something that specify
>>>>>> component's
>>>>>> type only when needed (something like UTF8 conventions but that
>>>>>> applications MUST use).
>>>>>>
>>>>> so ... I can't quite follow that. the thread has had some explanation
>>>>> about why the UTF8 requirement has problems (with aliasing, e.g.) and
>>>>> there's been email trying to explain that applications don't have to
>>>>> use types if they don't need to. your email sounds like "I prefer the
>>>>> UTF8 convention", but it doesn't say why you have that preference in
>>>>> the face of the points about the problems. can you say why it is that
>>>>> you express a preference for the "convention" with problems ?
>>>>>
>>>>> Thanks,
>>>>> Mark
>>>>>
>>>> .
>>>>
>>>
>> _______________________________________________
>> Ndn-interest mailing list
>> Ndn-interest at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>