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