BG5UWQ
第一点，文中提到的：
需要注意：文末不应有任何多余字符（含换行、空格、制表符等）, 即<EOR>后不含有任何字符.
若一张 QSL 卡片上含有多个 QSO , 则对应的 ADIF 文件应按照通联的时间顺序, 直接拼接各个 QSO 的 ADIF 数据，文末不应有任何多余字符（含换行、空格、制表符等）, 即, 以最后一个 QSO 的 <EOR> 后不含有任何字符.
此处的 “最后一个 QSO 的 <EOR> 后不含有任何字符”，实际情况可能无法满足，大多数会带有回车符，这时候是不是需要额外的程序处理。
其实就算带有回车符，考虑到CRLF等不同的行结尾格式，往往也需要额外程序处理，相比之下不带任何字符可能会略微简单一点，比如在shell里面
echo -n "xxxxx"
就足够生成不含文末回车的字符串了。
第二点，文中的签名，似乎是以 单条 的方式，对 ADIF 文件中的一条 QSO 进行签名，例如读取了 <EOR> 标识，而不是 <EOH> 标识，那么如果是一份 500 条 QSO 信息的 ADIF 文件，对应的签名信息我要放置哪里保存呢。
文中有提到，将所有QSO按时间顺序拼接即可。
这里考虑的场景是少量的QSO、点对点签名的情况。考虑到QSL的现实使用，一般不含公开全部的QSO细节，因此一次签名数百条QSO的场景可能不是特别适合这一情况（因为几乎不可能会对其中单条进行验证）。
本文提到的方式，更多的考虑是接收方可以方便的构造原始ADIF来验签，一次签名500条的话，几乎不会由QSO的对方来验签，此时直接对大ADIF签名即可。
（和第一点一起）我在设计的时候有考虑过里面ADIF的具体格式，经过一番脑内思考，最终将设计目标定为“机器构造，兼顾人工”，主要的场景是人工录入之后QSO信息-机器读取签名-机器验签。
第三点，文中的 6.2.1 构造 ADIF，缺少了 FREQ 字段，是有意为之吗。
是的，首先FREQ跟BAND本来就有一定冗余关系，必然是二选一。
其次，考虑到目前比对QSL（包括比赛当中）一般只对频段进行校验，而不对具体频点进行比较。因此文中选择了BAND而非FREQ。
目前对这一问题我持开放态度，只是本人更倾向于使用BAND。
在我实际通联当中，我也遇到了对于QSL内容有特殊要求的情况（最常见的是包含网格坐标），关于其他字段的选择或许也值得讨论。
第四点，我想讨论一个场景，签名信息提取的是 ADIF 的报文摘要，不可逆，我看楼主在评论区提到了 二维码 展现在卡片上，那么如果此时能够通过扫码直接展现对应源的 QSO 载荷信息，这样，是否有实现的可能或必要性呢。
可能性有，必要性我认为无。
在文中我提到了“7. 附加原始QSO数据”，即简单描述如何在里面嵌入原始QSO载荷，为了二维码体积做了较多取舍，同时这一章我没有做过于认真的设计，目前我关于这一话题是希望能有另外的RFC来专注这一主题。
最后，有关排版，我还是推荐来自掘金的翻译计划提供的 译文排版规则指北 - 统一中文文案、排版的相关用法，降低沟通成本，增强译文的规范性和气质，使其更加易读。
谢谢，我没有做太多排版调整，输入法给的标点选项除了引号正反之外也没有太多关心。我简单阅读了一下文章但因为我十二分依赖排版引擎，因此我倾向于——
- 中文与西文之间统统不加空格，加空格这一操作由排版引擎来完成；
- 考虑科技文献惯例，使用半角标点（引号除外），如有需要，也交由排版引擎完成必要转换（但句末使用句点）；
- 汉字用楷体而非加粗代替斜体，这一操作依然由排版引擎完成。
这主要是为了在不同的地方发布时有单一版本的源文件。
（或许后续我可以自己在GitHub上放正文来进行审阅，这里依然不做精细排版，适时同步两边的内容）
（但我承认这篇RFC基本没有照做）
闽ICP备2021006864号-7
闽公网安备35020602002794号