RFC720 日本語訳

Network Working Group                                         D. Crocker  (ISI)
Request for Comments: 720                                              Aug 1976
NIC #36337
References: RFC #680

クロッカー(ISI)がコメントのために要求するワーキンググループD.をネットワークでつないでください: 720 1976年8月のNIC#36337の参照箇所: RFC#680

          Address Specification Syntax for Network Mail

ネットワークメールのためのアドレス指定構文

Experience with processing mail on the Arpanet has pointed up many
addressing issues, including:

以下を含んでいて、Arpanetに関する処理メールの経験は多くの問題提示を強調しました。

1. People's names are not the same as their addresses;

1. 人々の名前はそれらのアドレスと同じではありません。

2. Mailing lists can get quite long;

2. メーリングリストはかなり長くなることができます。

3. To allow responding, messages often need to carry all of their
mailing list with them;

3. 応じるのを許容するために、メッセージは、しばしばそれらでそれらのメーリングリストのすべてを運ぶ必要があります。

4. It would be very useful to be able to send mail to files other
than the person's primary mailbox.

4. 人の第一のメールボックス以外のファイルにメールを送ることができるのは非常に役に立つでしょう。

The current mail syntax, specified in RFC 680, does not provide a
convenient mechanism for distinguishing between a person's name and
their mailing address. In cases of shared directories, the ATTN: clause
is marginally adequate; however it is completely inappropriate for
single-user mailboxes in which the address specification is simply
cryptic. CMU's identification tags are good examples of this problem,
since they tend to appear to be random character sequences; the use of
initials as tags also points up the problem. If you doubt the
referential ambiguity of addresses, then try to use only the information
presented, rather than random personal knowledge, to discern who
Micro@ISI, JFH@ISI, or Greep@ISD are. By having a formal syntax for
separately specifying names and addresses, mail display software can
printout out name lists which only contain human names...makes things
friendlier.

RFC680で指定された現在のメール構文は人の名前とそれらの郵送先住所を見分けるのに便利なメカニズムを提供しません。 共有ディレクトリに関するケース、ATTNで: 節はわずかに適切です。 しかしながら、アドレス指定が単に不可解であるシングルユーザーメールボックスに、それは完全に不適当です。 無作為のキャラクタシーケンスであるように見える傾向があるので、米カーネギーメロン大学の識別票はこの問題の好例です。 また、タグとしてのイニシャルの使用は問題を強調します。 アドレスの参考のあいまいさを疑うなら無作為の自分自身での認識よりむしろ提示された情報だけを使用するようにして、 Micro@ISI 、JFH@ISI、または Greep@ISD がだれであるか明察してください。 別々に名前とアドレスを指定するための正式な構文を持っていることによって、人間の名前を含むだけである缶のプリントアウトの出ている人名簿を表示ソフトウェアに郵送してください…事態をより好意的にします。

The problem with long mailing lists is that, if included in the text of
a message, they often are longer than the main part of the message.
Group names are allowed in address fields primarily to circumvent this
problem. However the advent of semi-automated message answering, in
which a receiver's message system prepares address lists for reply
messages by copying appropriate fields from the original message, makes
the current mechanism deficient: having the group name means that the
receiver does not have the names/addresses of the members of the group.
A convention is generally followed, now, which has the group name be a
pathname to the file containing the list. Though facilitative, this
does not represent an adequate solution.

長いメーリングリストに関する問題はメッセージのテキストに含まれているならそれらがメッセージの主部よりしばしば長いということです。 グループ名はアドレス・フィールドで主としてこの問題を回避できます。 しかしながら、受信機のメッセージシステムが応答メッセージのためにオリジナルのメッセージから適切な分野をコピーすることによって住所録を準備する半自動化しているメッセージ回答の到来で、現在のメカニズムは不十分になります: グループ名を持っているのは、受信機にはグループのメンバーの名前/アドレスがないことを意味します。 一般に、グループ名がパス名であることをリストを含むファイルに持っているコンベンションは今、続かれています。 facilitativeですが、これは適切な解決法を表しません。

And lastly is the issue of multiple mailboxes for a single user. This
feature is probably has the largest potential for teleconferencing
applications, with messages for an on-going discussion automatically
placed into a separate mailbox. In the case of shared directories, this
mechanism also would allow easy channeling into each person's own
mailbox.

そして、最後に、シングルユーザーにとって複数のメールボックスの問題があります。 電子会議アプリケーションの最も大きい可能性を持って、継続している議論へのメッセージで自動的に別々のメールボックスの中に置かれて、この特徴はたぶんそうです。 共有ディレクトリの場合では、このメカニズムも各人の自身のメールボックスへの簡単な精神を集中を許すでしょう。

                                  -1-

-1-

With these needs in mind, and until a more robust mail syntax and
protocol is specified, the following general syntax is proposed to
augment the existing syntax specified in RFC 680, for address fields
specified by the user:

念頭のこれらの必要性、より強健なメール構文とプロトコルが指定されるまで、以下の一般的な構文はRFC680で指定された既存の構文を増大させるために提案されます、ユーザによって指定されたアドレス・フィールドに:

Name:(Person(User-Id(Mailbox) at Host),...),; ...

名前: (人(ホストのユーザイド(メールボックス))、…)。 ...

Where

どこ

"Name" is the name of the mailing list; "Person" presumably is
the name of the person receiving the mail;

「名前」はメーリングリストの名前です。 おそらく、「人」はメールを受け取る人の名前です。

"User-Id" is their online reference name (usually their signon
directory);

「ユーザイド」はそれらのオンライン・リファレンス名(通常それらのsignonディレクトリ)です。

"Mailbox" is a a secondary mailbox/file;

「メールボックス」はa二次メールボックス/ファイルです。

and the rest conforms to RFC 680, although "@" may be used in
place of " at " in the specification.

に代わってそして、残りはRFC680に従います、"@"が使用されるかもしれませんが「」 コネにおける仕様。

Parentheses may be replaced by other bracketing pairs ([], {}, <>).
Quotation marks must be used any time the string contains ambiquating
characters, such as space or parentheses. The brackets after Name are
used to request exclusion of the address list from the message, instead
using text which gives the pathname to the source of the list.

括弧を他の大括弧の組([]に取り替えるかもしれない、<>) ストリングがスペースか括弧などのambiquatingキャラクタを含む何時でも引用符を使用しなければなりません。 Nameがアドレスの除外を要求するのに使用された後に括弧はメッセージからリストアップされます、代わりにリストの源にパス名を与えるテキストを使用して。

The formal syntax for address specification, within network mail
actually sent, is included in the next section.

アドレス指定のための正式な構文は次のセクションに実際に送られたネットワークメールの中に含まれています。

Not all of a specification is required, so perhaps some examples will
clarify things:.

仕様のすべてが必要であるというわけではないので、恐らくいくつかの例がものをはっきりさせるでしょう:

A normal specification, as used currently: Walker at ISI

現在同じくらい中古の正常な仕様: ISIのウォーカー

A named list, to be carried with the message, with the last
address not a member of the list: List:Walker at
ISI,greep@rand-isd;Action@ISI

リストというA、メッセージ、最終で運ばれるには、リストのどんなメンバーにも演説しないでください: リスト: ISIのウォーカー、greep@rand-isd; 動作@ISI

A named list, NOT to be carried with the message; the list
contents will be replaced with a text string indicating the source

Aはメッセージで運ばれるためにリスト、NOTを命名しました。 リストコンテンツを出所を明らかにするテキスト文字列に取り替えるでしょう。

of the list -- not very useful if the list is typed in by the
user, rather than pulled from a file; therefore
List:(Walker@ISI,greep at rand); Action at ISi will be changed to
appear in the message as List:("/rnd/dcrocker/mail.list"); Action
at ISI

リストについて--、非常に役に立たない、リストがファイルから引かれるよりユーザによってむしろタイプされるなら。 したがって、List: ( Walker@ISI 、底ならし革のgreep)。 Listとしてメッセージに現れるようにISiでの動作を変えるでしょう: ("/rnd/dcrocker/mail.list") ISIでの動作

A list with personal names. separate from addresses: "Steve
Walker"[Walker at ISI], Bob<rha@isd>

アドレスから別々の個人名があるリスト: 「スティーブ・ウォーカー」[ISIのウォーカー]、 Bob<rha@isd 、gt。

A teleconferencing address list:
Talkers:"Dave C"(DCrocker(TC.msg)@isi),...;

電子会議住所録: 話し手: 「デーヴC」(DCrocker(TC.msg)@isi)…;

                                  -2-

-2-

Formal Specification
--------------------

形式仕様--------------------

The following modified BNF is to serve as a direct
addition/replacement for specifications within RFC 680. The fields
eliminated from the existing specification are: <addressee item>,
<address list>, <addressee>, <mailbox>, <host spec>, <attention spec>.
<user list>, <mailbox group>, <group numbers>, and <mailbox list>.

以下の変更されたBNFは仕様とのダイレクト添加/交換としてRFC680の中で機能することになっています。 既存の仕様から排除された分野は以下の通りです。 <受け取り人の品目>、<住所録>、<受け取り人>、<メールボックス>、<ホスト仕様>、<注意仕様>。 <ユーザリスト>、<メールボックスグループ>、<グループ番号>、および<メールボックスは>を記載します。

<Attention spec> can be performed through use of the person's name
and secondary file specification. Also, <Sender> should be modified
to be::

人の名前とセカンダリファイル仕様の使用で<注意仕様>を実行できます。 また、<Sender>はである:なるように変更されるべきです:

Sender = "SENDER: " Individual

送付者が等しい、「送付者:」 「個々です」。

And the added fields are:

そして、加えられた分野は以下の通りです。

Address-Field = Address-List / Address-List ,,:,
Address-Field

アドレス・フィールドが住所録/住所録と等しい、:、アドレス・フィールド

Address-List = Individual-List / Group-List

住所録=グループ個々のリスト/リスト

Group-List = Group-Name Group-Members

グループリスト=グループ名グループメンバー

Group-Name = / Name ":"

「グループ名=/名前」:、」

Group-Members = Individual-List / L-Bracket Pathname
R-Bracket

グループメンバー=L個々のリスト/ブラケットパス名R-ブラケット

Pathname = {A Name which can at least provide a
human with enough information to find
the file containing the Group-List}

パス名=Group-リストを含むファイルは見つけることができるくらいの情報を人間に少なくとも提供できるName

Individual-List = Individual / Individual
Individual-List
Address Specification Syntax for Network Mail

ネットワークメールのための個々のリスト=個々の個々の個人/リストアドレス指定構文

Individual = Mailbox / Name L-Bracket Mailbox
R-Bracket

個々の=メールボックス/名のL-ブラケットメールボックスR-ブラケット

L-Bracket = "(" / "[" / "{" / "<"

L-ブラケット=、「(「/、「[「/、「「/"<"」

R-Bracket = ")" / "]" / "}" / ">"

「R-ブラケット=」) 」 /、」、]、」 /、」、」 /">"

Mailbox = Id Secondary-File At Host

ホストのメールボックス=イドセカンダリファイル

Id = Name

イド=名

At = "" at "" / "@"

=、「「「「/"@"」

Host = {An acceptable host name}

ホスト=許容できるホスト名

                                 -3-

-3-

Secondary-File = / L-Bracket Filename R-Bracket

セカンダリファイルL=/ブラケットファイル名R-ブラケット

Filename = Name

ファイル名=名

Name = {An Ascii string without carriage
return, line feed, space, '"', ",",
";", or any L-Bracket or R-Bracket} /
'"' {An Ascii string with any double
quotation marks doubled} '"'

; 「=を命名してください、復帰のないアスキーストリング、改行、スペース、'、「'、」、」、」、」、どんなL-ブラケットやR-ブラケット、も/、'「'どんなダブル・クォーテーション・マークがあるASCIIストリングも倍増した'、「''」

The particular L-Bracket and R-Bracket characters used must match
each other. The requirement for quotation marks has been made more
severe than absolutely necessary in order to simplify software
requirments. Note also that the above specified syntax is for
inter-entity communications and is not necessarily indicative of what
the user types.

キャラクタが使用した特定のL-ブラケットとR-ブラケットは互いに合わなければなりません。 ソフトウェアrequirmentsを簡素化するために引用符のための要件を絶対に必要とするより厳しくしました。 また、上の指定された構文が相互実体コミュニケーションのためにあって、必ず、ユーザがタイプするものを暗示しているというわけではないことに注意してください。

                                  -4-

-4-