[Ndn-interest] any comments on naming convention?

[Burke, Jeff]

Nacho, 
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. 
Jeff

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

>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.
>
>Nacho
>
>
>
>
>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:
>>
>>>interesting:
>>>
>>>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
>>application-motivated
>>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
>>the
>>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. :)
>>
>>Thanks,
>>Jeff
>>
>>>
>>>>
>>>> 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.
>>>
>>>Thanks,
>>>Mark
>>>_______________________________________________
>>>Ndn-interest mailing list
>>>Ndn-interest at lists.cs.ucla.edu
>>>http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>
>
>--
>Nacho (Ignacio) Solis
>Protocol Architect
>Principal Scientist
>Palo Alto Research Center (PARC)
>+1(650)812-4458
>Ignacio.Solis at parc.com
>