security - 電子メール用のマークアップ言語を作成すると、どのような技術的問題が発生しますか?

Question

マークアップ言語を電子メールに関連付けることで、どのような技術的問題が発生するのだろうか? 言語を調べずに、次の条件を持つ架空のマークアップ言語が存在すると仮定します。

• 電子メールのコンテンツを適切に構造化および定義するためのユーザー エージェントのすべての可能なニーズを満たします。
• 複数の作成者が電子メール スレッドの表現に貢献できるように、1 つのドキュメント内のコミュニケーションを適切に認可します。
• マークアップ規則を使用して、RFC 5322 と同様のヘッダー データをドキュメント内の通信の各インスタンスに適切に関連付けます。
• アクセシビリティ、セマンティクス、およびマークアップ技術自体にのみ限定されるその他の問題に関連するすべての問題を解決します。
• アプリケーション層の処理に関して考えられるすべてのセキュリティ条件を解決し、送信に関連する問題はまったく解決しません。
• この言語は、XML から派生したもので書かれている場合とそうでない場合があり、すぐに利用できる XML 派生テクノロジです。
• 言語インスタンスは、電子メールとして送信できるようになる前に、ユーザー エージェントからの検証が必要です。

そうは言っても、そのようなプロジェクトに関連する技術的な問題は何ですか? これにより、ユーザーエージェントにプログラミングの問題が発生しますか? このようなプロジェクトは、コンテンツが 7 ビット ASCII のみである RFC 5322 形式の電子メールと互換性がないことが証明されますか? そのような技術は、電子メール サーバーに有害であることが証明されますか? そのようなプロジェクトに関連する追加のセキュリティ問題はありますか? そのようなプロジェクトについて、他のテクノロジー固有の一般的な考えは何ですか? 可能な限り技術/プログラミングに焦点を当てた回答と応答を維持してください。私は、ビジネス上の意見や採用に関連するコメントに反対票を投じます。

Answer 1

セマンティクスの専門家として言えば、最も厄介な問題の 1 つは、データの意味に対する適切な制約です。最後の文が示すように、無限の賛同と協力があると仮定します。:-) XML だけでは、最終的に必要となるセマンティクスを十分に強制することはできないと私は主張します。残念ながら、すぐに例を示すことはできませんが、率直に話します。

「GOK タグの内容は、先行する FLOIT タグ内に含まれる BREEP タグの総数を超えない整数でなければなりません」

は、XML 検証を通じてすぐに適用されるとは思わないルールです。（私は間違っているかもしれません。私にとっては早い時期です。）

これは致命的ではありませんが、難しいだけでなく、一見難しいです。一言で言えば、最終的にどのような試みでも実施する必要があるセマンティクスには、堅牢な記述言語を必要とする一次論理 (二次論理ではないにしても) に相当するものがすぐに必要になります。そのような言語は存在します (OWL Full と同様に、Common Logic がすぐに思い浮かびます) ... しかし、その場合、ルールを強制するための強力な推論エンジンが必要になります。

残念ながら、あなたの禁止されたビジネスの意見に近い理由で、一見難しいと思いますが、人的要因のためだけに言及する価値があります. つまり、私の経験では、ユーザーはデータ モデリングにアプローチするリレーショナル代数的な方法によって課せられる制限に慣れすぎているため、「このフィールドは整数でなければならない、そのフィールドは文字列」であり、本当のセマンティクスは人間の眼球によって強化されると無意識のうちに想定しています。言い換えれば、効果的に単なる構文強制以上のものの必要性を理解するのは難しいでしょう... しかし、それは私の経験です。あなたのものはかなり違うかもしれません。