Recalling history, the 64-bit issue has come up before.

There was a significant discussion in 2001-09/10 which was led by
Bill Pence who produced the document seen here
http://heasarc.gsfc.nasa.gov/docs/he...bit/64bit.html

Bill took a poll and published these results on 2001-10-15:

YES 20 69%
NO 4 14%
UNDECIDED 3 10%
NO OPINION 2 7%
Total 29 100%

Prior to that, the topic arose in 1998-07 as part of the editing of
the NOST standard for FITS.

The proposals already posted are not far from being couched in formal
terms, the characters on either side of the issue have not changed
much.

How do we determine at what point the balance should tip?

Perhaps if there were an "official FITS feature registry" we could
create a new keyword to be inserted into the PHDU of a FITS file.
Repeated instances of that registry keyword could be used to describe
the features of FITS which must be supported if the reader is to
understand the FITS file fully.

By default a FITS file would conform to Wells et al. (1981)
Other features could have names and meaning like
GROUPS Greisen et al. (1981)
XTENSION Grosbol et al. (1988)
TABLE Harten et al. (1988)
IEEEFP IEEE floating point agreement (1990)
BINTABLE Cotton et al. (1995)
WCS1 Greisen & Calabretta (2002)
WCS2 Calabretta & Greisen (2002)
INT64 the current issue

And the registry should also contain significant unofficial things like

NOAOMOSAIC Valdes (1997)
GROUPING Jennings et al.
various Space Telescope conventions for FITS
lots of the content from
http://fits.gsfc.nasa.gov/fits_conventions.html
and anything else deemed relevant.

It would be relatively straightforward for a FITS reader to test its
capabilties against a set of such keywords and offer the option of
gracefully declining to interpret the full meaning of the file.

--
Steve Allen UCO/Lick Observatory Santa Cruz, CA 95064
Voice: +1 831 459 3046 http://www.ucolick.org/~sla
PGP: 1024/E46978C5 F6 78 D1 10 62 94 8F 2E 49 89 0E FE 26 B4 14 93