<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><DIV><DIV><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Please post any comments, suggestions, or concerns regarding these<SPAN class="Apple-converted-space"> </SPAN></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">proposals (or any other suggestions for improving the Standard document)</DIV></BLOCKQUOTE><BR></DIV><DIV>Good job. Time well spent. Thanks to all involved.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Comments indexed to the summary:</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>1.4) Extensions ARE special records from the point of view of classic FITS readers. Rather than deprecating or attempting to ban them, perhaps just explicitly state that new uses for special records require IAUFWG approval. (But see 1.10 below.)</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>1.5) Unenforceable in the absence of some explicit mechanism tagged to the DATE keyword (for instance). On the other hand, such a mechanism would be equivalent to explicitly versioning each file. This would be a change to the basic philosophy of FITS. I think of opening old Word files with new editions of MS Office - or worse - trying to do the reverse.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>1.6) Harmless, but also unenforceable. Not just an attempted constraint on software, but also on humans editing headers manually using IRAF hedit, for instance.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>1.7) No, but there are many headers that unintentionally repeat keywords. They should not therefore be rendered unconforming FITS.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>1.9) Few users will choose 64 bits when 16 will do. Those that do may well have a good reason.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>1.10) This is a requirement placed by the IAU, not FITS per se. Might such policies better be concentrated in a common section? On the other hand, it is eminently practical to manipulate unknown but conforming extensions. In particular, software we write today can skip and list and otherwise manhandle conforming extensions from tomorrow.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><SPAN class="Apple-style-span">3.1) Italicizing these words <I>may</I> be distracting. <I>Must</I> it be done? I <I>should</I> not <I>recommend</I> it. <I>Shall</I> it be <I>optional</I>?</SPAN></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>In general, as with the previous comment about the EXTEND keyword, we should be careful what we attempt to require regarding new data since it may place unfunded mandates on old software. Deprecation of a feature is not equivalent to requiring its converse.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>A couple of other general comments:</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Any chance of blessing checksums on this go-around? Then we could fret about using "one's-complement" versus "one's complement", too.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>There is a very real possibility that UTC will be turned into something other than a flavor of Universal Time, i.e., other than an approximation to Greenwich Mean Time. Perhaps we should consider how best to deal with such a situation. A generic "UT"? Use raw UT1? Define a UTA (Astronomical) retaining IAU mediated leap seconds? This is a broader issue than FITS, but we would have to start somewhere.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Rob</DIV></DIV><BR></BODY></HTML>