Appendix A. Implementer Guidelines (実装者ガイドライン)
A.1. Relationship with BSD Syslog (BSD Syslog との関係)
この文書は [RFC3164] の後継です。メッセージのフォーマットは BSD syslog フォーマットから変更され, 構造化データと明確に定義されたメッセージフォーマットを使用するようになりました。この付録ではいくつかの違いと下位互換性の懸念について説明します。
最も明白な違いは [RFC3164] が syslog メッセージフォーマットを形式化しなかったことです。[RFC3164] はパケットフォーマットを説明しましたが, それは既存の実装の観察に基づいていました。時間の経過とともに, 実装は異なる方向に進化しました。この仕様はこのフォーマットに従うデバイスが適切に相互運用できるように書かれています。同時に, フォーマットは古い BSD syslog 送信者と受信者と共存するように設計されています。
セクション 6.2 で説明されている HEADER フォーマットは PRI フィールドで始まり, その後に VERSION フィールドが続きます。PRI フィールドは [RFC3164] と同じ方法でフォーマットされます。VERSION フィールドにより, 新しい実装はこの仕様に従ってフォーマットされたメッセージを識別できます。また, [RFC3164] とのある程度の限定的な下位互換性も提供します。[RFC3164] を実装する受信者は VERSION 文字を HOSTNAME フィールドの最初の文字として解釈する可能性があります。これは望ましい動作である場合とそうでない場合があります。
TIMESTAMP フィールドは NILVALUE を使用する可能性があります。これは [RFC3164] とは異なり, 欠落している TIMESTAMP は受信時刻から推測されることになっていました。ただし, TIMESTAMP フィールドの NILVALUE は時刻が利用できないことを明示的に示します。
この仕様に準拠するメッセージは [RFC3164] に準拠するメッセージと区別できます。後者は PRI フィールドの直後に VERSION フィールドを含まないためです。
A.2. Message Length (メッセージ長)
syslog メッセージの最大メッセージ長について大きな混乱がありました。[RFC3164] は "パケットの全長は 1024 バイト以下でなければならない" と述べています。これは多くの実装がより長いメッセージを受け入れ, 1024 バイトの長さを尊重しようとするいくつかの実装がメッセージを切り詰めなければならなかったため, 相互運用性の問題につながりました。
この文書は最大メッセージ長を課しません。代わりに, トランスポートマッピングが最小限サポートされる最大メッセージ長を定義します。トランスポート受信者はより大きなメッセージを受け入れることができます。これにより, 最小限必要な長さとして 480 オクテットの定義につながりました。すべてのトランスポート受信者はこの長さのメッセージを受け入れることができなければなりません。トランスポート受信者は 2048 オクテットまでのメッセージを受け入れることができるべきです。より長いメッセージをサポートする必要がある場合, トランスポートマッピングはより長い最小限最大長を定義する可能性があります。
A.3. Severity Values (重大度値)
重大度値は [RFC3164] と BSD syslog 実装から取得されています。重大度値から実際の重要性への標準的または普遍的に受け入れられたマッピングはありません。表 2 で説明されている意味はガイドラインです。各実装は各重大度レベルに対して独自の定義を持つ可能性があります。
実際には, 重大度はフィルタリングによく使用されます。オペレーターは高い重大度レベルのメッセージのみを受信したい場合や, 特定の重大度のメッセージのみを保存したい場合があります。このため, メッセージオリジネーターはその操作のコンテキストで論理的に意味をなす適切な重大度レベルを選択すべきです。
A.4. TIME-SECFRAC Precision (TIME-SECFRAC 精度)
この文書は TIME-SECFRAC フィールドが最大 6 桁を持つことができることを指定します。これによりマイクロ秒の精度が提供されます。ただし, すべての桁が有意である必要はありません。オリジネーターはクロック解像度の制限である場合, 3 桁のみ (ミリ秒精度) を提供する可能性があります。あるいは, オリジネーターは 6 桁すべてを提供する可能性がありますが, 最初の 3 桁のみが正確であることを保証します。
メッセージの受信者は TIME-SECFRAC フィールドのみからクロックの精度を判断できません。クロック精度情報が重要である場合, オリジネーターはそのクロックに関する追加情報を提供するために timeQuality SD-ID (セクション 7.1) を含めるべきです。
A.5. Case Convention for Names (名前の大文字小文字規約)
SD-ID, PARAM-NAME, APP-NAME, および MSGID は大文字と小文字を区別します。これは "eventId" が "eventID" および "EventID" とは異なることを意味します。これは最大の柔軟性を提供するために決定されました。ただし, これは SD-ID と PARAM-NAME を定義する際に注意が必要であることも意味します。
SD-ID と PARAM-NAME には必須の大文字小文字規約はありません。ただし, ガイドラインとして, camelCase の名前が提案されます (例: "eventSource", "sequenceId")。これは多くのプログラミング言語で使用される一般的な規約と一致しています。
A.6. Syslog Applications Without Knowledge of Time (時刻の知識がない Syslog アプリケーション)
一部の syslog アプリケーションは現在の時刻を判断できない可能性があります。これはデバイスが時刻ソースを持たないため, または時刻ソースが一時的に利用できないためである可能性があります。そのような場合, TIMESTAMP フィールドに NILVALUE ("-") を使用しなければなりません。
リレーが TIMESTAMP フィールドに NILVALUE があるメッセージを受信した場合, 独自のタイムスタンプを挿入してもかまいません。これによりリレーはそれを持たないメッセージに時刻情報を追加できます。ただし, メッセージの意味を変更する場合, リレーはこれを行うべきではありません。たとえば, メッセージが特定の時刻に発生したイベントを説明している場合, NILVALUE をリレーの現在の時刻で置き換えることは不適切です。
A.7. Notes on the timeQuality SD-ID (timeQuality SD-ID に関する注記)
timeQuality SD-ID (セクション 7.1) はオリジネーターがそのクロックの品質に関する情報を提供できるように設計されています。この情報はログ分析に有用である可能性があります。
たとえば, ネットワークデバイスが NTP サーバーへの接続を失った場合, そのクロックが同期されなくなったことを示すために isSynced="0" を設定する可能性があります。デバイスのクロックが同期されていない間に大幅にドリフトする場合, 生成するタイムスタンプは不正確である可能性があります。timeQuality SD-ID によりデバイスはこの状況を示すことができます。
syncAccuracy パラメーターはタイムスタンプの予想精度を示すために特に有用です。これによりログ分析ツールは時刻情報が相関目的に十分正確であるかどうかを判断できます。
A.8. UTF-8 Encoding and the BOM (UTF-8 エンコーディングと BOM)
MSG フィールドは UTF-8 でエンコードされる可能性があります。UTF-8 でエンコードされている場合, UTF-8 バイトオーダーマーク (BOM) で始まらなければなりません。BOM はオクテットシーケンス %xEF.BB.BF です。
BOM は MSG が UTF-8 エンコードされていることを示すインジケーターとして使用されます。BOM が存在する場合, 受信者は MSG を UTF-8 として解釈すべきです。BOM が存在しない場合, エンコーディングはこの文書によって指定されていません。
BOM は MSG フィールドの先頭でのみ使用されることに注意することが重要です。メッセージの他の場所に出現してはなりません。BOM が他の場所に出現する場合, BOM としてではなくデータとして扱われるべきです。