[Nfd-dev] Naming conventions for "sequence number"

[Alex Afanasyev]

Please check the first draft for the naming conventions memo (http://redmine.named-data.net/attachments/download/100/convention.pdf  or  git at git.irl.cs.ucla.edu:papers/ndn-memos-naming-conventions.git)

The primary intention for the document is to just define the encoding format and several (4 to be exact) markers.  In future we may include more discussions, motivations, and examples.

---
Alex

On Jul 20, 2014, at 8:01 AM, Burke, Jeff <jburke at remap.ucla.edu> wrote:

> 
> Hi,
> 
> As I mentioned before, I think this is a really useful conversation.
> 
> I'd suggest that conventions be captured and proposed in a spec document
> rather than by email, so that there can be examples / motivations and a
> little deeper discussion.  I think this is also a good way to share the
> results of the dialogue.
> 
> For example, it may also be necessary (and interesting) to define a
> convention for the FinalBlockId depending on whether something is a
> sequence or a segment, if we indeed make that distinction. (As an aside, I
> notice that the tlv 0.2 spec still shows "NumberComponent" as a potential
> type for FinalBlockID.  From talking with Lixia, I thought that we have
> decided that there will not be typed components in the architecture.  If
> that is true, then all such references should be removed.  If not, this
> should be discussed, too.)
> 
> Some thoughts below in addition to the ones sent earlier.
> 
> 
>>> Hi Jeff and all,
>>> 
>>> We had a follow up discussion today about naming conventions and in
>>> particular we got to one question about "sequence numbers".   The CCNx
>>> naming convention that we going to revert for now defines markers for
>>> segments (sequential and non-sequential) and marker for version.  What
>>> this convention is missing is the marker for sequential sequence numbers
>>> for "infinite" collection.  Examples of this could be stream of
>>> generated notifications n NFD, dataset in ChronoSync, frames in webrtc
>>> (?).  In the past, we kind of used "segment" convention to represent
>>> such numbers, but during our discussion we agreed that there is
>>> different semantics for "segments" and "sequence numbers" and it is
>>> useful to explicitly distinguish between them:
>>> 
>>> - "Segment" is a Data packet that is a part of a bigger data blob
>>> (e.g., segments of one frame).  If third party (repo, cache, library?)
>>> understands this semantics, than it can try request all the segments and
>>> stop when finished.
> 
> Yes, this makes sense to me.  And then FinalBlockID indicates the end
> segment if known?  
> 
>>> 
>>> - "Sequence number" (for "infinite" collections) denotes that the
>>> particular Data object is part of the collection, but is independent
>>> piece of this collection (individual frame).   It is also possible that
>>> such a piece can be further segmented.   If third parties understand
>>> this semantics, they can perform very different actions compared to
>>> segments.  
> 
> So is the idea that individual segments are not useful, but sequence
> elements are?  Or that segments *could* be useful on their own, but the
> application does not declare them that way?
> 
> Another useful thing here would be whether ordering matters - sequence
> implies ordering, perhaps we need a notion of an unordered collection?
> Would be nice to perhaps sketch out a paper with these conventions and
> elaborate on them and potential use cases.
> 
>>> 
>>> 
>>> The proposal at hand is that we not just define markers for "segment"
>>> (%00 prefix) and "version" (%FD) as it is in NFD, but also add a new
>>> notion of sequence numbers (say, %FE for now).
>>> 
>>> This definition doesn't imply we need to do any immediate change in any
>>> of the application we have.  It is just for the future
>>> applications/updates we use a more semantically correct ways to mark out
>>> sequence numbers.
> 
> 
> How is "semantically correct" defined?  Maybe we need use cases to be
> discussed? 
> 
> 
> Thanks,
> Jeff
> 
> 
>>> This will also prepare libraries for any convention change later.  The
>>> place where we plan to use it right away is in NFD notification stream
>>> protocol (http://redmine.named-data.net/projects/nfd/wiki/Notification).
>>> 
>>> Can you give opinions about this proposal?
>>> 
>>> ---
>>> Alex
>>> 
>>> 
>>> _______________________________________________
>>> Nfd-dev mailing list
>>> Nfd-dev at lists.cs.ucla.edu
>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>> 
>