[Ndn-interest] any comments on naming convention?

[Mark Stapp]

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