<NOFRAMES> が正しい。
→ http://www.w3.org/TR/REC-html40/present/frames.html
<NOFRAME> は、多くの HTML 本に見られる非常に有名な間違いである。
80字/行はパンチカードの仕様であり、計算機以前にまで遡るのかもしれない。
コンピューターが存在する以前に、IBM がパンチカードを使って計算する機械式計算機をすでに実用化しており、その頃から今のような 1行 80桁のパンチカードが使われていたそうだ。
http://XXX/hoge という URL を要求をするブラウザ/クライアント/ユーザは、自分が要求しているものがディレクトリだとは認識していないと見なせる。よって、それがディレクトリであれば、まずは認識を正してくれるよう、クライアントの要求をサーバが差し戻しするわけである。
具体的に言うと、クライアントが物理的なディレクトリである /a/b を要求してきたら、サーバは「ああそれなら /a/b/ のことですね。曖昧でないように、そのようにご用命して下さい、302」といったものを返す。それ以降は、クライアントも自分の現在地の認識を /a/b/ だと改めることができる。
この 302 という応答コードは、クライアントに目先を変えさせる汎用的なリダイレクション機能を含んだものであるが、大半は上のような用途で使用されているだろう。
結果的には、一往復分の余分な通信が行われていることになる。そのような URL を HTML や名刺等に書いて流している人は、クライアントにもサーバにも余計な負担をかけている、ということになってしまう。
記事のキャンセルというのは、「メッセージ ID でいうところのこれこれという記事を取り消してください」という "記事" を出すことである。そして、もしそのメッセージ ID の記事があれば取り消して、なければそれが来るまで待っているという振る舞いをする。(そのような記事は、"キャンセルメッセージ" と呼ばれる)。
つまり、ある記事を消すためにまた別の新たな記事を出しているわけであり、間違ってもその記事を出した事実自体がなくなるわけではない。さらにいえば、ほっとけばその記事だけなのに、さらによけいな記事を出していることになり、データ通信量の観点からいえば、あまり得な話ではない。
記事をキャンセルしなくても、ある程度の時間がたてばサーバから消える (Expire を設定していないサーバもあるかもしれないが...) ので、たとえば記事の内容に大きな問題がある (相手が内容を誤解しそうな誤り、法に触れるなど) 場合でない限り、わざわざキャンセルはすべきではないだろう。
キャンセルされた記事はフィードされないが、キャンセルメッセージはフィードされる。
通常ニュースサーバはそのサーバに存在しない記事に対するキャンセルが来た時は、「その記事が、どんなんものかはよく知らないが、あることにしておこう」という態度をとる。そして、あとからその記事がやってきても「私は知らない」として、受けとらないわけである。
このような制限を設ける理由は、迷惑なジャンクメールの中継点に使われないためである。そのような中継に使われてはサーバーも回線も持たないという現実的問題が大きいため、回線やサーバ資源の不正使用を禁止するといことが大きな理由だろう。
また、下手にサードパーティリレーをしてしまうと、ORBS
に登録されてしまい、ネットワークからサーバが浮いてしまう恐れがある。この件については下記のページで触れられている。
http://www.nanet.co.jp/rlytest/index.html
送信者制限のやりかたは複数あり
(http://www.ne.jp/asahi/cyber/taki/essay/auth-submission.html
参照)
プロバイダによって採用されている方式が違うので、どのような制限が行われているかは、一概には言えない。
メールヘッダの From 行だけをチェックする制限方法もあるが、これだけではあんまり制限の意味がないだろう。なぜなら、その ISP のユーザに見える From を付ければ済んでしまい、返信を受け取る気のない一方的なメールの中継をしようとする輩には何の制約にもならない。
他の制限手段として、メール受信 (POP) のユーザー認証に成功した後、一定時間はユーザー側のホストからのメールの転送 (SMTP) を許可する、"pop before smtp" という方法がある。POP で承認されるということは正式に ID とパスワードを受けているということなので、正規のユーザだと認定できる。短時間内に同じ IP アドレスから送信された場合には、正規のユーザからの送信だということなので送信を認めるわけである。商用プロバイダだと、IIJ4U や So-net などが採用している。
ローカルスプールにある mbox ファイルを、先頭が From で始まる行をメッセージの区切りとして扱うことから、スプールへの配送時に From を >From に変換する mail.local が存在する。
FreeBSD 3.2 の mail.local(8) より
大なり記号 (``>'') は ``From '' によって誤って別のメッセージとして 処理される可能性のある行の行頭に付加されます (それは、空白行に続く 行で ``From '' という 5 文字で始まる行です)。
sendmail 解説より。
F=E 余分な From を >From に変更する (中略) この F=E フラグが必要になることはほとんどありません。通常は、local 配信エージェント定義によって指定されるプログラムが From 行の変換を 処理します。
というわけで、mail.local の仕様によって、From が >From に変換されることがあり得る。
メールクライアントや POP サーバなどが取り込むときに > を外すことも考えられるが、もともと >From という行があった場合と区別はできないので無理だと言える。実際、多くの MUA は本文中の >From を From に変換しない。
しかし、qmail などは、mbox 形式の変種である、mboxrd 形式として扱っており、From_ 行や >From_行、>>From_行にそれぞれ > を付加することから、常にクォートを取り去って構わない。よって、スプールの mbox では >From になっていても、ユーザが取り込んだ時には From に戻っている。
また、Solaris 2.6 の mail.local は、mbox 配送時には Content-Length: で管理するので、From を >From に変換する必要が無い。
ニュースサーバによっては、トップカテゴリ別に異なる配送先・配送元を持っている場合がある。また、サイトによって購読しているカテゴリも異なるし、ローカルに用意したニュースグループを持っているかもしれない。よって、あるカテゴリが世界でたった一つしかないという保証はない。
例えば、ローカルではないグループと自サイトに閉じたローカルなニュースグループ (仮に X.Y とする) にクロスポストをしたとする。この記事は世界中を配送されて行き、その過程で、あるサイトのローカルにたまたま同じ X.Y というグループがあると、クロスポストの機能によってそのサイトの X.Y というグループに見覚えのない記事が入ってしまうことになる。
また、ポリシーが異なるカテゴリ間でクロスポストすると、一方のグループ側で見た人のフォローが他方のカテゴリの AUP に抵触する恐れがある。(AUP の異なる例としては、fj.* と tnn.* で商売が可能か否かというものがある)。
ただし、トップカテゴリ別にマルチポストされるケースもそれはそれで迷惑であり、トップカテゴリをまたがるクロスポストについては、マナーやルールとは別に思慮分別の問題として "自分で考える" というのが正解だと思われる。
管理されているということはない。
しかし以下のような記事が news.* に投稿されたり、その内容を Web で見ることも出来る。このリストには、fj や japan や tnn 等がきちんと収められている。
% From: leisen@pfx.on.ca (Lewis S. Eisen)
% Newsgroups: news.answers,news.admin.hierarchies,news.groups.questions
% Reply-To: leisen@pfx.on.ca
% Subject: Master List of Newsgroup Hierarchies, v5.36
% Message-ID: <leisen-0208992259520001@port193.magma.ca>
% Approved: news-answers-request@MIT.EDU
% URL: ftp://ftp.magma.ca/pub/misc/Master_List.txt;\
http://www.magma.ca/~leisen/mlnh/
% Posting-Frequency: every two weeks
% Archive-name: usenet/hierarchy-list
% Lines: 708
% Date: Tue, 03 Aug 1999 03:00:01 GMT
%
% Subject: Master List of Newsgroup Hierarchies
% Date: 1999 August 2
% Last revision: 1999 August 2
% Posted to: news.groups.questions,news.admin.hierarchies,news.answers
% Version: 5.36
このリストの目的は,
% The following is a list of newsgroup hierarchies, to help readers of the % news locate a hierarchy of interest. % % To help administrators avoid naming conflicts, both open and closed % hierarchies are now listed. The symbol <> following a description denotes % a closed hierarchy. % % Additions, changes and corrections should be sent to % <mailto:leisen@pfx.on.ca> (Lewis S. Eisen). Many thanks to those who have % made contributions to date.
の第二段落のように、名前の重複を避けることも含まれている。
URL (Uniform Resource Locator) というのは多くの場合、特定の "場所" (サーバのホスト名/フルドメイン名/IPアドレス等) が含まれる。これに対して URN (Uniform Resource Name) というのがあり、たとえば "HTML 4.0 の DTD" というふうにあるものに対して固有の名称がつけられ、どのサーバから取ってもいいようにする記法がある。そして、URI (Uniform Resource Identifier) というのは URL と URN を併せたものをいう。
URN のシンタクスについては RFC 2141 に規定がある。また、URN の実例としては、例えば RFC 2648 では RFC や Internet Draft といった IETF 文書の URN が、幾つか提案されている。記述例は以下のもの。
urn:ietf:rfc:2141 urn:ietf:std:50 urn:ietf:id:ietf-urn-ietf-06 urn:ietf:mtg:41-urn
RFC 2141 を URL で指定すると、例えば <http://www.ietf.org/rfc/rfc2141.txt> などになるが、<urn:ietf:rfc:2141> と記述することによって、それが IETF のサーバにあるかミラーサーバにあるかといった location に関わりなく、"RFC 2141" というリソースを特定できるわけである。
とりあえず概要をつかむには、<http://www.w3.org/Addressing> あたりを一読するとよいだろう。
RFC1036 の時代から NetNews の記事に Subject ヘッダは必須とされている。よって、Subject の無い記事を出すような壊れた news サーバは存在してはならない。
Subject の無い記事を INN でリジェクトしないようソースに手を入れることは可能であるが、世間一般と記事を配送しあうサーバの場合は、そういった修正自体止めるべきである。
例えばメーリングリストの記事をローカルの INN に投げているといった場合は、Subject 無しの記事にダミーの Subject: をつけるという対処で十分だろう。不正な message-id の記事についても同様である。
英語の be 動詞の過去形の "was" と同じものと考えてよい。「前は××だった」ことを示すものである。
参考までに、draft-ietf-usefor-article-03.txt には、以下のように説明されている。
5.4.1. Examples
In the following examples, please note that only "Re: " is mandated
by this standard. "was: " is a convention used by many English-
speaking posters to signal a change in subject matter. Software
should be able to deduce this information from References.
Subject: Film at 11
Subject: Re: Film at 11
Subject: Godwin's law considered harmful (was: Film at 11)
Subject: Godwin's law (was: Film at 11)
Subject: Re: Godwin's law (was: Film at 11)