[Ndn-interest] any comments on naming convention?

[Massimo Gallo]

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).

Max

On 16/09/2014 16:05, Mark Stapp wrote:
> And that seems like a reasonable place to start. there's a small 
> number of types that are in wide use. The UTF8 convention should be 
> eliminated, and they should be assigned component types.
>
> Now, I would want a way for applications to be able to use 
> app-specific components, because they may want to do so to improve 
> their own processing. that'd be an area opened up for experimentation 
> by making the initial move to typed components. and as you say, 
> there's no need to standardize/publicize component types that are 
> application-specific, we'd just want to identify the code-point 
> boundary between 'common' and 'app-specific'.
>
> -- Mark
>
> On 9/16/14 9:56 AM, Massimo Gallo wrote:
>> Hi Dave,
>>
>> Just to clarify, what i wanted to say is just said that we should
>> specify name's component types if and only if layer three needs to
>> understand them (e.g., segment, versioning?, ...).
>> What is the advantage of having components' types at layer three if it
>> NEVER uses them?
>>
>> Max
>>
>>
>>
>>
>> On 16/09/2014 15:35, Dave Oran (oran) wrote:
>>> On Sep 16, 2014, at 5:12 AM, Massimo Gallo
>>> <massimo.gallo at alcatel-lucent.com> wrote:
>>>
>>>> Dear all,
>>>>
>>>> Interesting discussion!
>>>>
>>>> Here are my 2 cents to the discussion.
>>>>
>>>> I think we should avoid having explicit components' type.
>>> Below you seem to argue pretty much the opposite.
>>>
>>>> CCN/NDN are layer three technologies that allow an end host process
>>>> to retrieve some     named data. The networking layer does need only
>>>> to check local cache (exact match IMO), PIT (exact match IMO) and FIB
>>>> (LPM, I think we all agree on this :D!).
>>> I certainly wish we could agree on this change to the design, but I
>>> think it’s premature to say we all agree that LPM on the PIT and CS
>>> has proven to be highly problematic.
>>>
>>>>   The way a "consumer" requests the next in order segment is up to
>>>> the transport layer as Tarek said and not a layer three functionality.
>>> Agree, but we’re discussing the protocol encoding, not the fetch
>>> algorithm. Names as a data structure are “shared” across multiple
>>> layers (a good thing IMO) and hence defining their semantics once as
>>> opposed to having different interpretaitons in different layers seems
>>> a good tradeoff, even it “exposes” some things to layer 3 that are not
>>> strictly necessary for layer 3 operation and could be opaque. I’ll
>>> note that the semantics and encoding of the typed name components
>>> needs to be (and is in the current proposal) done in such a way that
>>> simple byte-wise compares do the right thing for all of exact match,
>>> LPM,  and anti-aliasing.
>>>
>>>> Moreover, adding components' types may introduce problems as type
>>>> explosion (also pointed by someone else in this thread).
>>> Type explosion is a concern, but frankly is equally a problem no
>>> matter whether typing is done by convention, markers, or types. What
>>> distinguishes the option in my opinion is resilience against aliasing,
>>> for which I think explicit typing has substantial advantages.
>>>
>>>> That said there might be some "special" components requiring
>>>> conventions:
>>>>
>>>> Segment: the most important one IMO because with that field many
>>>> segments can be identified as a single object and treated differently
>>>> for caching purposes. (i.e. a naming convention here can be that
>>>> Segment ID must be last name's component hence without an explicit
>>>> segment identification)
>>>>
>>> Precisely. Which means all applications have to agree on a convention,
>>> or this needs to be “baked” into the architecture somehow. There are
>>> multiple wats to do this, but typed name components seems utterly
>>> straightforward, and can leverage the exact registration policy and
>>> machinery that is used to control all architectural constants defined
>>> by the protocol.
>>>
>>>> Versioning and Timestamp: there might be a case for explicitly
>>>> identify those two components as suggested in the NDN-TR-22 but, IMO,
>>>> too many naming conventions will complexify layer three operations
>>>> that I would keep as simple as possible.
>>>>
>>> As long as L3 can treat these as opaque and is not required to be
>>> cognizant of name component types, their existence does not complicate
>>> L3 in any way.
>>>
>>>> Max
>>>>
>>>> _______________________________________________
>>>> Ndn-interest mailing list
>>>> Ndn-interest at lists.cs.ucla.edu
>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>>
>>>
>>
>> _______________________________________________
>> Ndn-interest mailing list
>> Ndn-interest at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>> .
>>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>
>