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(_at_)pobox(_dot_)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(_at_)pobox(_dot_)com>
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/ietf