[wfc] CHECKSUM Proposal

[Arne Henden]

William Pence wrote:
> The objectors to the CHECKSUM proposal (see below) have argued that random
> transcription errors are so rare that there is no need for an additional
> layer of file validity checking at the FITS file level.  This overlooks what
> I regard as one of the most important uses of the CHECKSUM keywords: The
> CHECKSUM keywords provide a simple mechanism for putting a 'validity stamp'
> or 'seal of approval' on the FITS data files that are retrieved from large
> public archives like the HEASARC, MAST, or NRAO.  By verifying that the
> CHECKSUM in the FITS file is still correct, the end user can be reasonably
> assured that the local file is identical to the file in the archive, and
> that it has not been modified (either deliberately, or inadvertently) by
> subsequent data analysis software.  For this purpose, it is actually better
> if most data analysis software ignores the CHECKSUM keywords and does not
> automatically update or delete them.  Then the fact that the file fails the
> checksum test will clearly indicate that the current file is not the same as
> the file that was retrieved from the archive.  Failing the CHECKSUM test
> does not mean the file is not a valid FITS file.  It only means that the
> file is no longer the same as when the CHECKSUM was originaly computed.
> 

This feature of ignoring CHECKSUM is not part of your proposal, so
the assumption has to be that someone implementing the checksum will
update the checksum upon every modification.  If you want it generated
only once, you need to modify the proposal.

Rob wrote:

 >The original version of the proposal included a CHECKVER keyword.
 >After some discussion, we decided that this was unnecessary unless
 >and until a second per-HDU algorithm was identified.  Any checksum
 >contained within a separate extension will most likely be expressed
 >using a separate set of keywords and other data structures.

   One concern I have with adopting the current proposal, as I stated
earlier, is that it reserves the checksum keywords for one and only
one type of checksum.  In your proposal, for example, you state in
section A.6.2 that "One other checksum algorithm shows some promise
of being embeddable in an ASCII FITS header.  This is Fletcher's
checksum..."  That is why I suggested a third reserved keyword that
identifies the algorithm used, so that the checksum/datsum keywords
can be used for other forms of checksumming, but if used for your
algorithm, they have to be used in a specific manner.  That also
allows for modification of the original procedure if deemed necessary.

Arne