[Ndn-interest] any comments on naming convention?

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

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