[wfc] CHECKSUM Proposal

[William Pence]

Arne Henden wrote:
> 
> 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.

There is no stated or implied requirement that the checksum keywords have be
updated or deleted whenever the file is modified.   These are optional
keywords so software can ignore them (and most existing software certainly
will).   The purpose of the CHECKSUM keywords is simply to be able to verify
if the file has changed since the time that the CHECKSUM keywords were
originally calculated.  If the checksum of an HDU no longer sums to zero
this does not necessarily indicate a problem or an error;  it simply means
the file has changed in some way.

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

To repeat what Rob said, we previously reserved a CHECKVER keyword and
recommended that the *absence* of this keyword implies the current
definition of the CHECKSUM keyword.  There is no reason, however, to reserve
this absent keyword until there is a need for it.  We think it is unlikely
that there will ever be a need for it because if someone invents an
alternate checksum scheme then they will most likely invent their own new
keywords for it.  There is no need to reuse CHECKSUM and DATASUM, and in
fact it would probably be more confusing to introduce alternate meanings for
the same set of keywords.

Finally, I'd just like to restate what I see as the strongest reason for
voting in favor of this proposal: Several major archive centers (NOAO,
HEASARC, CXC) have been using the checksum keywords for many years.  Even if
you don't think it is very useful, other groups have found it to be useful
and inexpensive to implement.  The CHECKSUM keyword now exists in a very
large number of FITS files.  The is no question about the technical 
feasibility or legality of the CHECKSUM keywords.  The only issue now is 
how to preserve the definition of this keyword convention for posterity.  
How will researchers 50 years from now know how to decode the CHECKSUM 
value?  The only safe way to preserve this information is to make it part 
of the FITS Standard.  Adding this keyword convention to the FITS Standard 
does not imply that other software packages must adopt it and it places no 
burden on other software providers to support it if they don't want to.

Bill Pence
-- 
____________________________________________________________________
Dr. William Pence                          William.D.Pence at nasa.gov
NASA/GSFC Code 662         HEASARC         +1-301-286-4599 (voice)     
Greenbelt MD 20771                         +1-301-286-1684 (fax)