R: Comment on draft-santoni-timestampeddata-02

"Santoni Adriano" <Adriano.Santoni@actalis.it> Sat, 16 February 2008 22:12 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 CD56628C2FA; Sat, 16 Feb 2008 14:12:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.722
X-Spam-Level:
X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJ0MeyOqhbz2; Sat, 16 Feb 2008 14:12:20 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AA9F28C2BF; Sat, 16 Feb 2008 14:12:20 -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 32F293A6AB6 for <ietf@core3.amsl.com>; Mon, 11 Feb 2008 01:19:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAmd9-qpFkGq for <ietf@core3.amsl.com>; Mon, 11 Feb 2008 01:19:47 -0800 (PST)
Received: from Frontmail1.itmaster.local (pop3out.finsiel.it [193.43.104.48]) by core3.amsl.com (Postfix) with ESMTP id 202D33A695D for <ietf@ietf.org>; Mon, 11 Feb 2008 01:18:48 -0800 (PST)
Received: from POSTA02.itmaster.local ([193.43.104.10]) by Frontmail1.itmaster.local with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Feb 2008 10:20:13 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: R: Comment on draft-santoni-timestampeddata-02
Date: Mon, 11 Feb 2008 10:20:11 +0100
Message-ID: <FF374A5075949C4D87367831AAAFD421010AF2EB@POSTA02.itmaster.local>
In-Reply-To: <1299763745.20080208133439@pobox.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Comment on draft-santoni-timestampeddata-02
Thread-Index: AchqmnKXh7qSoAG+RP2bmRrXfJyVbQB9Iw+A
References: <1299763745.20080208133439@pobox.com>
From: Santoni Adriano <Adriano.Santoni@actalis.it>
To: Bill McQuillan <McQuilWP@pobox.com>
X-OriginalArrivalTime: 11 Feb 2008 09:20:13.0640 (UTC) FILETIME=[4EB0EC80:01C86C8F]
X-Mailman-Approved-At: Sat, 16 Feb 2008 14:12:18 -0800
Cc: Bob Braden <braden@ISI.EDU>, IETF Discussion <ietf@ietf.org>
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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

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

I agree. I will revise my draft accordingly.

Thank you,
  Adriano


-----Messaggio originale-----
Da: Bill McQuillan [mailto:McQuilWP@pobox.com] 
Inviato: venerdì 8 febbraio 2008 22.35
A: IETF Discussion; Santoni Adriano
Oggetto: Comment on draft-santoni-timestampeddata-02

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