<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><DIV>Hi Bill,</DIV><DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">I've�revised the documentation about this convention to try to address all�the comments that have been received so far.� Please see the new PDF (or�postscript) documentation file available from the FITS Registry at</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><A href="http://fits.gsfc.nasa.gov/fits_registry.html">http://fits.gsfc.nasa.gov/fits_registry.html</A>.</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV>Certainly an improvement.� If we can agree that a broader discussion of implementing long string support within the standard will follow, I withdraw any objections from this end to the convention being registered.</DIV><DIV><BR><BLOCKQUOTE type="cite"><BLOCKQUOTE type="cite"></BLOCKQUOTE></BLOCKQUOTE><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">I don't really see any technical problem with�writing the CHECKSUM keyword as a continuation over 2 (or more)�keywords.� The algorithm for initializing the header and calculating the�CHECKSUM keyword value(s) would need to be modified slightly, but it�would still follow the same basic procedure.</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV>Indeed, the FITS checksum encoding could accommodate such a complication, but both writers (or generalized keyword editors) and readers would have to know about the 32-bit alignment requirements for CHECKSUM keywords.� To modify my previous example a bit, this keyword:</DIV><DIV><BR><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><FONT class="Apple-style-span" color="#000000"><FONT class="Apple-style-span" face="Courier"><SPAN class="Apple-tab-span" style="white-space:pre"> </SPAN>CHECKSUM= 'nADTnADQnADQnADQ'� � /� ASCII 1's complement checksum</FONT></FONT></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><FONT class="Apple-style-span" color="#000000"><FONT class="Apple-style-span" face="Courier"><BR style=""></FONT></FONT></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; ">is not the same as this expression of overtly the same value:<FONT class="Apple-style-span" color="#000000"><FONT class="Apple-style-span" face="Courier"><BR style=""></FONT></FONT></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR class="khtml-block-placeholder"></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><FONT class="Apple-style-span" color="#000000"><FONT class="Apple-style-span" face="Courier"><SPAN class="Apple-tab-span" style="white-space:pre">  </SPAN>CHECKSUM= 'nADTnADQn& � � �'� � /� ASCII 1's complement checksum</FONT></FONT></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><FONT class="Apple-style-span" color="#000000"><FONT class="Apple-style-span" face="Courier"><SPAN class="Apple-tab-span" style="white-space:pre"> </SPAN>CONTINUE� 'ADQnADQ'</FONT></FONT></DIV><DIV><FONT class="Apple-style-span" color="#000000"><FONT class="Apple-style-span" face="Courier"><BR class="khtml-block-placeholder"></FONT></FONT></DIV><FONT class="Apple-style-span" color="#000000"><FONT class="Apple-style-span" face="Courier"><FONT class="Apple-style-span" face="Helvetica">The 32-bit integer alignment is different, breaking the 1's complement legerdemain.� Other keywords won't have this peculiar requirement, but additional semantic or logistical complications can be anticipated.</FONT><BR></FONT></FONT></DIV><FONT class="Apple-style-span" color="#000000"><BR></FONT><DIV>- Rob</DIV><DIV><BR class="khtml-block-placeholder"></DIV></BODY></HTML>