[Ndn-interest] any comments on naming convention?

Burke, Jeff jburke at remap.ucla.edu
Mon Sep 15 18:11:53 PDT 2014

I guess I'm not following most of these questions - there are some musings
(at least) in the document that try to sketch an alternate perspective to
typed components, and most of these questions are covered in some way. I
should qualify that they just represent my attempt to provide another side
to the argument. 

On 9/15/14, 1:22 PM, "Ignacio.Solis at parc.com" <Ignacio.Solis at parc.com>

>What is this ³type explosion² the document is talking about?
>Whether it is a type for a component, a command marker, or a marker
>component, there needs to be some agreement on what the meaning of
>type/marker is.  If not, then it would just be a regular name component
>for a  single application.  So, like Dave says, there needs to be some
>registry or overall agreement in some form.
>Wouldn¹t there be the same number of types as command markers?  So you
>would basically have ³command marker explosion²? Or is there something
>special about command markers?
>What we are discussing here (I hope) is, what is the best way for
>applications to talk about specific meaning of components. (Versions,
>Segments, etc).  There are multiple ways to do this.
>- Typed named components are explicit and unambiguous. They always exist.
>They can be the Generic type or some special type (like Version).  The
>allow arbitrary binary data in a component.
>- Command markers may or may not exist. This leads to aliasing if you
>allow arbitrary binary data in a component.  If you don¹t allow arbitrary
>binary data in a component, then to solve aliasing you need to escape
>potentially ambiguous data.
>- Command components suffer from the same fate.
>If your data structures do not use component types, then you¹ll have to
>escape binary data to have a consistent type/marker system.
>Can somebody describe the disadvantage they see of using typed named
>components?  Is it the potential requirement to register? Is it the
>limited type space? Is it the extra bytes?
>What is the benefit of command markers over typed named components?
>Is it possible for applications to follow a convention that doesn¹t create
>aliasing? Yes, you could start creating rules that don¹t allow binary data
>of some value in some components if followed by some components, etc.  So
>now, any application that wants to put binary data has to check it¹s own
>data to make sure it doesn¹t break other apps.
>Sometimes it seems to me that people assume that these names will be human
>readable most of the time. Where is this assumption coming from?  For all
>we know everything will be binary.
>Taking my convert-to-CCN hat off for a second I think that it¹s in your
>best interest to use component markers, that way if you keep using prefix
>matching at least you can request  /foo/bar/v_/* and at least force the
>network to get you something that is a version. Having said that, I still
>think you¹ll end up doing exact matching soon, but in the meantime might
>as well take advantage of it.
>On 9/15/14, 12:12 PM, "Burke, Jeff" <jburke at remap.ucla.edu> wrote:
>>Hi all,
>>On 9/15/14, 11:33 AM, "Mark Stapp" <mjs at cisco.com> wrote:
>>>On 9/15/14 1:41 PM, Tai-Lin Chu wrote:
>>>> I think for naming convention, the community should come up with a
>>>> solution that people "want" to use.
>>>I think that we should work toward specifying something that does what
>>>we've learned (over several years of work) we need to do, and that does
>>>not add any additional pain or unnecessary complexity.
>>So - just to poke at this a bit - who's the "we" here, and whose pain and
>>complexity?  Application developers, network architects, equipment mfrs,
>>or ?  (And do they agree?) As you know, NDN takes an
>>approach to the development and evaluation of the architecture, and NSF
>>has asked for this explicitly in their most recent RFP.  If we could
>>discuss some pros/cons from that perspective - perhaps via quick examples
>>or case studies that have led you to this conclusion, it would be helpful
>>(in my mind) to this current discussion.
>>Attached are some previously shared thoughts on segmenting and versioning
>>conventions related to this discussion, and some arguments against types,
>>after page 2. Though Junxiao's marker type is an interesting new twist, I
>>am so far unconvinced that it addresses all of the concerns in this doc.
>>Note - these were not originally intended for a public discussion, at
>>least not in this form, so be kind. :) I can also imagine that some of
>>discussion could be dismissed via "drop selectors and add manifests" but
>>would suggest addressing the spirit of argument in light of the current
>>NDN architecture instead.
>>(Unfortunately I am on the road so not sure I can keep up with the
>>discussion, but wanted to inject some other perspectives. :)
>>>> Could you describe the ambiguous case? I think I know what you mean by
>>>> ambiguous, but I just want to make sure. (I remembered someone from
>>>> cisco mentioned this in ndncomm 2014.)
>>>> To avoid ambiguity, I will start from name component tlvs and allocate
>>>> more types for different meanings.
>>>> 8 = regular name component
>>>> <type> = segmented name component
>>>yes, this is the approach I favor. typed name components allow us to
>>>identify the 'infrastucture' data in name components, while allowing us
>>>to set aside some number space for application-defined components. code
>>>that just wants to compare names or identify component boundaries needs
>>>to be able to treat the components as 'opaque', of course.
>>>Ndn-interest mailing list
>>>Ndn-interest at lists.cs.ucla.edu
>Nacho (Ignacio) Solis
>Protocol Architect
>Principal Scientist
>Palo Alto Research Center (PARC)
>Ignacio.Solis at parc.com

More information about the Ndn-interest mailing list