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

Ken Calvert <calvert@netlab.uky.edu> Sun, 09 August 2020 23:26 UTC

Return-Path: <calvert@netlab.uky.edu>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 032123A0E68 for <icnrg@ietfa.amsl.com>; Sun, 9 Aug 2020 16:26:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=netlab.uky.edu
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYZglpE59D2M for <icnrg@ietfa.amsl.com>; Sun, 9 Aug 2020 16:26:56 -0700 (PDT)
Received: from mail.netlab.uky.edu (mail.netlab.uky.edu [128.163.140.42]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C07483A0E67 for <icnrg@irtf.org>; Sun, 9 Aug 2020 16:26:56 -0700 (PDT)
Received: from hardy.local (cpe-96-29-182-38.kya.res.rr.com [96.29.182.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netlab.uky.edu (Postfix) with ESMTPSA id BD8BE1809C; Sun, 9 Aug 2020 19:26:54 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netlab.uky.edu; s=default; t=1597015614; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sIXYczuOs/QtRKErIKam4dhjuuDCUDCmK+AFlVTlwZk=; b=ZbRSKnqsVegNS+2h3CYVjfV72D0O452TgcAJziO9WexfMWasSgfqmhAdMhk39q5YFLXNGc y/d3u1DNOAMo2f7nY+niBrrL5dw0gWEPei3896mXlyCLTXtpxF7Eu6rXxWsXr3w5EOZ+Tx 9xLHUqRxAr6ygpzYIKdv3j06KGzatowjjHuS+W1ro4t17FsDXqqC2WHAqOIqoSZ+nYxEsr AnT0USEnYI3LrIsVqcHg41uQysI2THGqY7g8JOJOM5kHgB7oAgsTaQn4U6bRJ/jNMUPdAm QFeo73m0vUju630Zdoy5RBk7H/PaLILRHFAnAB2uuOwCUpDcNF5LzBf2HJthsQ==
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Ken Calvert <calvert@netlab.uky.edu>
In-Reply-To: <A8A53463-3A1F-49AF-A4C4-4192E5749B4E@parc.com>
Date: Sun, 9 Aug 2020 19:26:52 -0400
Cc: "icnrg@irtf.org" <icnrg@irtf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <450A0D61-080A-4C7D-9ADC-A4581EAE48C6@netlab.uky.edu>
References: <mailman.835.1596746246.7280.icnrg@irtf.org> <B998AB47-A18A-4A6D-9AB0-541364B9B64F@netlab.uky.edu> <A8A53463-3A1F-49AF-A4C4-4192E5749B4E@parc.com>
To: Marc Mosko <mmosko@parc.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=netlab.uky.edu; s=default; t=1597015614; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sIXYczuOs/QtRKErIKam4dhjuuDCUDCmK+AFlVTlwZk=; b=k5rVCpwH9oAF/KpfxnDklWT4lmyf0Jgw2XYPK3PMJIUF5ltMvnVT69M1gwQLaeyVYChnNv 6mkluepLim0FyPjnQKN3LIqYmb2m4PDGSuxehzU8LMp7fFJdZZbgjq+KeN9dBQ/zh2l3Oj dL0Dmau3H4cxlwrkUV3xOCXOcqTBeNPW5/QuYsDCME1OUTxTP95cMx37j2aKbmdRv4RaLA PXM/dBpoyMAtsjTwMTipI6CHrWMRoq/vKHnDubtaGolmlpIpGCrjY2OSBw4Apbr2cltrVo tBN6HSlBA71Lv5ILzGJmGHWx5iQf1WJMkt1pGhvIPu4N1p5bbTQ0Y0viVey7ZA==
ARC-Seal: i=1; s=default; d=netlab.uky.edu; t=1597015614; a=rsa-sha256; cv=none; b=uKnNBsxBXbNUmw8l2icBnzI38blYHB+y7i9OzMdSD6X7zSTZtnPLjHKuYzS+AtNr8xu1Fv iYi2AGtMxhMfeRmEd5uY/ZO3xGySxbIPHTi8gbl4nb3KlpRXjPw1Gbvs5/0om8WX9546jM CvUr2AxKbUF32CRryyT3pT23quMMcX7cQ9s7BmoNt1+liqNTdqH+nvWme7cun1wqj8pBph vxb+FKS9nW/+FxacGNyugOwj0fdJoSGc+XUbYLIpnPZjUlKlDxJk5++By/3NriZTeCC00U 1ltSH+nqpwW+mNEwZOBGwqWigxeqPSYknLr0beplIrgP0ggdFCvp3nLBLJpzzA==
ARC-Authentication-Results: i=1; mail.netlab.uky.edu; auth=pass smtp.auth=calvert@netlab.uky.edu smtp.mailfrom=calvert@netlab.uky.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/WY7RN9db1FqYUzAiNip07JHn-70>
Subject: Re: [icnrg] icnrg Digest, Vol 101, Issue 8
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Aug 2020 23:26:58 -0000

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

My point was that I'm not sure the term "file" has a precise definition in this context - or at least, I'm not sure that I understand it the way you were using it.
(Perhaps this was why Christian introduced the "blob" terminology.  Networking has now been around long enough that many otherwise-useful terms have baggage that renders them problematic.)

But I agree that it's a minor point!

Ken