In article <c7il8r$2r6c$1@fw.hamaint.co.jp>, Eiji KATSURA wrote:
>RFC-1036 の STATUS は UNKNOWN でしょ。
>( STANDARDでないRFCを根拠にされてもねぇ )

　２点確認したいと思います。

　１．桂氏は、STATUS が UNKNOWN であれば一切考慮する必要は
　　　無く、従う必然性は無いという立場ですか？
　　→ Yes なら、1036 の話を使わずに議論しますし、No なら、
　　　考慮する範囲を明確にしつつ議論しましょう

　２．桂氏は、<409c6347$1_2@127.0.0.1> を問題の無い
　　　Message-ID であると捉えていますか？
　　→ Yes なら、ここが論点になりますね。
　　→ No なら、どこに問題があるかが論点になりますね。
　　→ Unknown なら、論点を探す必要があります。

　以下、ここが明らかになるまでは、ぱらぱらと材料整理をして
おくことにします。

>少し譲って、RFC-822と書かれている部分をすべて RFC-2822と
>読みかえたとして、解釈したとしても、
>RFC2822の方は、FQDNであることはもはや要請していない。

　ちょっと長めですが、RFC2822 を引用しましょう。
　確かに、RECOMMENDED（推奨）であって要請ではありませんが、そ
もそもの主旨に反することが問題なのです。

 1]   The message identifier (msg-id) itself MUST be a globally unique
 2]   identifier for a message.  The generator of the message identifier
 3]   MUST guarantee that the msg-id is unique.  There are several
 4]   algorithms that can be used to accomplish this.  Since the msg-id has
 5]   a similar syntax to angle-addr (identical except that comments and
 6]   folding white space are not allowed), a good method is to put the
 7]   domain name (or a domain literal IP address) of the host on which the
 8]   message identifier was created on the right hand side of the "@", and
 9]   put a combination of the current absolute date and time along with
10]   some other currently unique (perhaps sequential) identifier available
11]   on the system (for example, a process id number) on the left hand
12]   side.  Using a date on the left hand side and a domain name or domain
13]   literal on the right hand side makes it possible to guarantee
14]   uniqueness since no two hosts use the same domain name or IP address
15]   at the same time.  Though other algorithms will work, it is
16]   RECOMMENDED that the right hand side contain some domain identifier
17]   (either of the host itself or otherwise) such that the generator of
18]   the message identifier can guarantee the uniqueness of the left hand
19]   side within the scope of that domain.
20]
21]   Semantically, the angle bracket characters are not part of the
22]   msg-id; the msg-id is what is contained between the two angle bracket
23]   characters.

# 余談ですが、山形パーレン (<>)は Message-ID の一部と思って
# いたのですが、この RFC2822 によると、違うようですね。これ
# は誤認していました。

　玉川氏は <409c6347$1_2@127.0.0.1> を「そんなにおかしくない
んじゃないの？」と言っていますが、私はおかしいと考えます。

　まず単なる事実として引用部16行目にある RECOMMENDED に従っ
ていない点が出発点です。で、従わないなら従わないでもいいので
すが、生成アルゴリズムは 2〜4行目 にある主旨を満たすものであ
る必要はあります。これは、MUST（要請）ですから。
　で、具体的には <409c6347$1_2@127.0.0.1> はその主旨を満たし
ているのか？
　はっきり言って分かりません。であれば、「危ない」とするのが
普通の判断というものでしょう。

　もうちょい補足すると、RECOMMENDED と強調するのは、他に同じ
ことが実現できるアルゴリズムがあるなら、これに従う必要はない
という意味であって、無条件に他の手段を許容するという意味では
ありません。そんな意味なら、RECOMMEND する意味が無いのですか
ら。
　そして、同じことが実現できるかどうかの証明、具体的には
127.0.0.1 が unique であると guarantee されることの証明は、
127.0.0.1 を生成したアルゴリズムを使っている者が行うべきこと
です。

　で、件の馬鹿がそれをしたという話は、寡聞にして聞きません。
　開き直っている姿は、何度も見ていますが。

# ほんとは 409c6347$1_2 の方もアルゴリズムを示して欲しい所で
# すね。

　以下は、1036 絡みなので、確認点１の状況によっては、単なる
ヨタになります。

>rfc1036 > In any situation where this standard conflicts with the
>rfc1036 > Internet standard, RFC-822 should be considered correct and this
>rfc1036 > standard in error.
>
>と書かれているのだから、(822を2822に読みかえれば) this standard is error
>ということだ。

　どこに conflicts があるんでしょう？

　[RFC1036 で要請しているが、RFC2822 で要請していない]とい
う状況は、RFC1036 では制約がきつくなっているという話で、こ
れは conflict とは普通は言わないでしょう。
　conflict とは、たとえば[RFC1036 で要請しているが、
RFC2822 でが禁止してる]というような、一方を守れば一方が守れ
なくなる状況を指します。

　ちなみに、桂氏が引用したちょっと上に、RFC1036 ではこう書
いてあります。

In RFC1036:
>    News standard is more restrictive than the Internet standard,
>    placing additional requirements on each message and forbidding use
>    of certain Internet features. 

　more restrictive と言っているわけで、上述の話と素直に繋がっ
ています。

-- 
頼光 mailto:raikou.j@jcom.home.ne.jp