Re: [icnrg] icnrg Digest, Vol 101, Issue 8

[Marc Mosko <[e-mail]>]

  >
  >On 8/8/20, 12:19 PM, "icnrg on behalf of Ken Calvert" <[e-mail] on behalf of calvert=[e-mail]> wrote:
  >
  >    Responding to a couple of points:
  >
  >    DaveO said:
  >
  >    > I’m still digesting this. Consider my comments more as questions, although all of you who know me also are aware of my predilection to couch questions as objections.
  >    > 
  >    > I also admit to not really understanding it completely after a couple of read-throughs. Some of this may be due to having to purge my translation cache of my usual understanding of some of the terms you have chosen. Feel free to respond, ponder for why the explanation isn’t getting through well to me, or just ignore.
  >
  >    I won't try to respond to your points (I'm already way behind), but I think maybe you and Christian are closer together than your reactions might indicate.
  >    For example, I interpreted his "virtual blob" in exactly the way you suggest.
  >
  >    Marc said:
  >
  >    > FLIC describes a single file.  No.  By definition, FLIC must always describe two files: the manifest and the data.
  >
  >    I think you mean to say "FLIC specification must always describe two types" here, right?

Well, the Manifest describes how to assemble all the pieces of the manifest into the correct order such that one can derive the correct order of data pointers from it.  The manifest is, at its base, an ordered list of pointers to data, plus a little extra for security context and maybe an annotation.  To me, that is the manifest file.  I could give you a single file (say json or binary) that conveys the same exact information as gets encoded in the manifest tree.  The manifest tree exists because we want to limit the size of the data transfer unit.

But this is a semantic point not really that important.  We could call it the manifest type or whatever.  My point is there's two things being conveyed: the manifest (data pointers) and the data itself.

  >
  >    > Inlining: Yes!  One use case we had for this was when someone wants to re-publish a manifest object (e.g. a content distributor wants to point its subscribers to local caches via locators), it would encapsulate the original root manifest in its re-written one so the consumer can verify in one step that they (a) got the thing they were asking for (from the interior manifest) and that someone they trust for such things (e.g. their ISP) tells them a good place to fetch it from.
  >
  >    Hmmm. This is different from my understanding of the "inlining" discussion.  As I said in my previous message, I interpreted it like what some filesystems do for inodes of small files: put application data directly in the inode/manifest structure.  I think the latter is a bad idea, for reasons I mentioned earlier.  OTOH, what you describe here, encapsulating metadata in other metadata, seems like just a normal thing you might do with a metadata-in-manifest facility.

Ok, I understand the distinction.  At some early point, it was decided that a Manifest should not carry application data in its payload.  I think that's fine.  

  >
  >    Ken
  >
  >    _______________________________________________
  >    icnrg mailing list
  >    [e-mail]
  >    https://www.irtf.org/mailman/listinfo/icnrg
  >