Comment on draft-santoni-timestampeddata-02

Bill McQuillan <McQuilWP@pobox.com> Fri, 08 February 2008 21:33 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietfarch-ietf-archive@core3.amsl.com
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6930D28C572; Fri, 8 Feb 2008 13:33:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lKJUNCUh2fH; Fri, 8 Feb 2008 13:33:28 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F3F128C47A; Fri, 8 Feb 2008 13:33:28 -0800 (PST)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8BC428C47A for <ietf@core3.amsl.com>; Fri, 8 Feb 2008 13:33:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ETS2IQVGkoC for <ietf@core3.amsl.com>; Fri, 8 Feb 2008 13:33:26 -0800 (PST)
Received: from sasl.smtp.pobox.com (a-sasl-quonix.sasl.smtp.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id CEDBB28C418 for <ietf@ietf.org>; Fri, 8 Feb 2008 13:33:26 -0800 (PST)
Received: from a-sasl-quonix (localhost [127.0.0.1]) by a-sasl-quonix.pobox.com (Postfix) with ESMTP id 4DB3E4CDD; Fri, 8 Feb 2008 16:34:53 -0500 (EST)
Received: from MCQWP2 (ip72-197-112-82.sd.sd.cox.net [72.197.112.82]) by a-sasl-quonix.pobox.com (Postfix) with ESMTP id 47BC34CD6; Fri, 8 Feb 2008 16:34:43 -0500 (EST)
Date: Fri, 08 Feb 2008 13:34:39 -0800
From: Bill McQuillan <McQuilWP@pobox.com>
X-Priority: 3 (Normal)
Message-ID: <1299763745.20080208133439@pobox.com>
To: IETF Discussion <ietf@ietf.org>, Adriano Santoni <adriano.santoni@actalis.it>
Subject: Comment on draft-santoni-timestampeddata-02
MIME-Version: 1.0
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <http://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <http://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Perusing this draft I came upon a paragraph that seemed to need comment:

     3. Compliance requirements 

        ...

        Compliant applications SHALL always populate the fileName field of 
        TimeStampedData structure with a non-empty string, which is supposed 
        to be the real name of the time-stamped file. Path information MUST 
        NOT be included. A valid example is "patent123.doc". An invalid 
        example is "c:\Documents and settings\John\Desktop\patent123.doc". 

It seems to me that the MUST for a non-null filename presumes that there
will never be a situation where the data has no natural filename and the
identity of the data is known from other context information. If it ever
becomes necessary for a convention to arise where data, that doesn't have a
natural filename, gets some name like "unknown.name", I believe that it
would be better to allow a null name to be given.

Note that some sort of validation must be done by the consumer of the
TimeStampedData anyway to prevent a filename being used that has invalid
syntax for the consumers filesystem or would overwrite another file that
happens to have the same name, etc.

Further, it seems to me that "path information MUST NOT be included" makes
too many assumptions about the larger context. If the file happens to have
a natural name which, for instance, has date information in the path, like:
"/logs/2008/02/08/transaction.log" and is routinely sent each day, the
so-called "real name" of the file (transaction.log) is useless since it
would be the same for every version of the file.

A more appropriate requirement for both of these situations would be to put
text in the Security Considerations section requiring any consumer of
TimeStampedData to validate the entire filename according the rules of its
local filesystem and its intended usage before using some or all of the
name to store the data.

-- 
Bill McQuillan <McQuilWP@pobox.com>

_______________________________________________
Ietf mailing list
Ietf@ietf.org
http://www.ietf.org/mailman/listinfo/ietf