送信は厳格に，受信は寛容に

C言語で

いきなりですが問題です．以下の文章で，[5]〜[9]に入る適切な語句，数値またはプログラムコードを答えてください．

C言語には多彩な演算子が提供されている．論理演算のための演算子もあり，論理積(AND)は &&，論理和(OR)は [5]，否定(NOT)は [6] である．これら3つの中で最も [7] が高いのは，単項演算子である [6] である．論理演算子を適用した結果は，必ず [8] か0のいずれかであり，それぞれ真と偽に対応する．論理演算のオペランドや，if文などでの条件判定では，整数型の0，浮動小数点型の0.0，ポインタについては [9] のいずれかと等しい値が偽であり，そうでない値が真となる．

これは今年2月に出した試験問題の一部です．少々探せば見つかりますので，答えそのものを示すのは，避けることにします．
この中で，[8] に「0以外のすべて」と書く答案がそこそこありました．それで，学生向けの解答・解説では，以下のように書きました．

誤答例(「／」以降はコメント)
(略)
[8] 0以外のすべて／論理演算子の真理値表を確認のこと．論理演算のオペランドと評価結果の違いは，「送信は厳格に，受信は寛容に」(RFC 1958) というインターネットの原則に通じるものがある．

「RFC」は授業で取り上げていなかったので，最初にこれを読んだ受講生は面食らったことでしょう．もちろん，「送信は厳格に，受信は寛容に」でも，「RFC 1958」でも，Googleで調べればすぐに出典が見つかる今の世の中です．
論理演算子を一つの処理（プロセス）とみなしたとき，そのオペランドが「受信」，評価値が「送信」となります．そうして見ると，受信可能な値の広さと，送信となる値の狭さ（たった2つ!）を，確認できるでしょう．

メールで

2人以上の学生とミーティングをするとき，原則として誰かに議事録を書いてもらいます．その議事録にはよく，単純ミス，見解の相違などがあって，そのままにして次回ミーティングで「前回は確か…」と見直したときに，表記あるいは意味のところで，引っかかりを覚えます．そういうことにならないように，議事録案を受け取ったら，できるだけすぐに読み，修正指示を出します*1．
かつて読んだ，ある議事録案では，誤変換や，“てにをは”*2すなわち助詞の使い方のおかしさが，目につきました．
大学教育の範囲や水準で，学生には，正しい日本語を書け，話せるよう，知識・技能を身に着けてから，大学を出てもらいたいものです*3．ビジネスの場で使用する日本語表現の集合は，とりとめのないおしゃべりなどを含む，コミュニケーションのための日本語表現の集合の，真部分集合になるはずです．
理屈はどうでもいいや．返信しときましょう．

人に見てもらう文章を書き上げたら，全体を最低2回，見直してください．そして誤変換などの単純ミスを，取り除いてください．

と書きたかったのですが，我ながらチェックが不十分な状態で送信．

人に見てもらう文章を書き上げたら，全体を最低2回，見直してください．そして誤変換などの単純みすを，取り除いてください．

学生は「みす」に対して特に申し立てることなく，指示通りに修正してくれました．軽く冷や汗ものの出来事でした．

References

3.9 Be strict when sending and tolerant when receiving. Implementations must follow specifications precisely when sending to the network, and tolerate faulty input from the network. When in doubt, discard faulty input silently, without returning an error message unless this is required by the specification.
3.9 送信時には厳格で、受信時には寛大であるべきです。実装はネットワークに送信する時に正確に仕様書に従い、ネットワークからの欠陥がある入力を大目に見なくてはなりません。疑いがあれば、仕様書に要求されない限り、エラーメッセージを返さないで問題のある入力を静かに捨ててください。
RFC1958 インターネット構築の原則

「私の文章の一部分だけを取り上げて批評するのでなく、全体の意味を理解してから批評せよ」という趣旨の発言を何箇所かで見ました。確かに、文章だけのコミュニケーションにおいては、こういうことで歯がゆい思いをすることはよくあります。
しかし、確かに「送信時には厳格で、受信時には寛大であるべき」ではあるけれど、自分が送信者であるときに、受信者に寛大さを求めちゃいけません。送信時には厳格であるべし。
キャッチボールの取れない原因を求める場合のように、これは突き詰めていけば程度問題になります。明らかに悪意をこめて文章を曲解したり、末節をあげつらう「揚げ足取り」をする人もいます。また、こちらがいくら分かりやすく書いても、それを読み取れない、読解力の足りない人も存在します。
でも、これといって悪意を抱く理由もなく、並程度の読解力もありそうな人に、自分の真意が伝わらなかったとすれば、それは自分の文章表現に問題があったということ。相手の能力を疑う前に、まずは潔くゴメンナサイと折れて、その後、誤解があるなら誤解を解くようにしたいものです。
http://www.heartlogic.jp/archives/2004/08/post_193.html

それから、ふと思ったのは、ネットリテラシーとネットワークプログラミングとは似ているということです。ネットワークプログラミングには、「送信時には厳格に、受信時には寛容に」(RFC1958) という原則があります。データを送信するときはRFCをきちんと守り、データを受信するときは、たとえそれがRFCを守っていなくても柔軟に対処する、という原則です。ネットリテラシーの極意も、何かを発信するときには、それを読む人がどのような印象を受けるかということに細心の注意を払い、誰かが発信したものについては、どんなに酷いことが書かれていても気にしないで読み流す、というところにあるように思われます。
2009-06-24

umiyosh コミュニケーションなんかRFC1958「送信時には厳格、受信時には寛容」の原則が思い浮かんだ。ネガティブなだけの言葉はうまくスルーして、自分はそういう言葉吐かないようにしよう。 2009/02/15
http://b.hatena.ne.jp/umiyosh/20090215#bookmark-12132808

もちろん、Ｐｅｒｌのカルチャーでは、ほとんど何も禁止されていない。この世はすでに禁止事項であふれている。Ｐｅｒｌのカルチャーで何かを禁止して、この世の禁止事項をこれ以上増やす必要はない。それが私の考えである。ついでながら、禁止事項を増やす必要がないのはプログラミングだけではない。人間関係においても禁止事項を増やす必要はない。私は、Ｐｅｒｌコミュニティの一部のメンバーを−主に、何かにつけて反抗的だという理由で−追放するよう求められたことが何度もあるが、いままで一貫して拒否してきた。そして、これが正しいやり方だと信じているし、いまのところ、このやり方が実際面でうまく機能していることは確かである。反抗的なメンバーは自分から去っていくか、おとなしくなって、他人と前向きにつきあうようになるかのどちらかである。コンピュータプログラマが意志を通じ合うためには、追放されたものに対して各人が厳格になり、受け入れられたものに対して寛大になることが最善の方法であることを、人びとは本能的に理解しているのである。これは不思議だ。しかし、奇妙なことに、人びとは、口を慎んだり聞く耳を貸したりすることに厳格であろうとはしない。これもまた自明のことだろう。我われは自己表現するように教育されている。
　というわけで、Ｐｅｒｌのカルチャーでは、何かを禁止する代わりに、一定の徳目を奨励するようにしている。使徒パウロが指摘しているように、愛、喜び、平和、忍耐、親切心、善、優しさ、柔和さ、自制といったものに対して禁止法を定める者はいない。だから、我われも、悪を禁じることに専念するよりも、善を奨励することに専念しようというわけである。(略)
“w—ÍA”E‘ÏAŒª‘»

どうしても「追放」と訳したいなら
「追放しようというときにはルールに厳格に、受け入れるときにはどんな人でもなるべく寛大に」
ぐらいか? (意訳過ぎるような気がするが)
でも正直、人間同士のコミュニケーションでこれを実践するのは大変そうな感じがする。なんでそう感じるのかな。疲れそう、っていうか。
「追放されたものに対しては厳格に」「受け入れられたものに対しては寛大に」
村社会の村八分っぽくて名訳だと思う。確かにこれが「最善」という感じ。
追放された者には厳格に。受け入れられた者に対しては寛大に。 - J0hn D0e の日誌