References

「この発言はあの発言へのコメントで、あれはそちらの...」といった議論の前後関係、つまり他ならぬthreadがこれにより形作られます。各発言（記事）はMessage-IDによって特定されるので、それが用いられています。

しかし時に、いや結構しばしばこのthreadingはうまく行かないのです。これはニュースサーバーの管理者（プロバイダーの担当者）に苦情を言うことで改善される余地はあります。

ところでReferencesにはこの例にあるようにMessage-IDが横にずらずら、または縦にずらずら、並んでいます。一番最後に付いているのが直接に関わる元発言。この直前の一発言だけ書いておけば十分とも思われます──実際自分でそう編集してしまう人もしばしばいます──が、記事が届く順序は不定、つまりフォローアップ（新しい記事）がフォローアップ対象の記事（古い記事）より先に（読者のところに）届くことは皆さんお気づきのようにごく日常ですので、もしReferencesが削られて直前の一つだけだとはぐれてしまいます^*1。ですから、長すぎる^*2という理由で鋭意削るにしても、到着順序は不定であることを理解・前提した上で削る、即ち多めに残して、直接の参照先ではないかもしれないが筋の近いところにthreadingされるようにしましょう。

*1　この場合どこにthreadingされるかはnews readers次第だが、サブジェクトを頼りに「同じサブジェクト」（と判定された記事）へ、時間順序も加味してthreadingするnews readersが多いか。ですから、「教えてください」が一杯あると、全然別のところにくっついてしまいますね。

*2　一行の長さは最大1024文字（us-ascii）。ただし、Message-IDが縦にずらずら並んでいる場合は、それぞれ別の行になっているので、この制約を逃れることになる。なお、Referencesフィールドがどうあるべきか求めたRFC1036では、（原則）元記事のReferencesを「そのまま original」継承するよう求めると共に、長すぎる場合は削ってよいと付記してあります。また、縦に並べるか横に並べるかについては特に約束はないようです。

なお、Referecesが続いていてもサブジェクトが変わると別threadとするnews readersもGNUSやForte Agentなど少なくありません。これはRFC1036からは逸脱しますが、この方が利便性が増すという判断だと思われます。筆者もこれに賛同します。RFCは規則ではないので、違反したからどうこうということではありません。従わないことが引き起こす影響を見極めつつインターネットを今後どうより便利に使ってゆくかの話です。もちろん、RFCを改定する努力も必要です。

このページでは、ネットニュースのあなたの記事の、普段目につかないところにはこんなことが書かれている、「ヘッダーとは何ぞや？」を説明しています。図はクリッカブル・マップになっています。