RFC724 日本語訳
0724 Proposed official standard for the format of ARPA Networkmessages. D. Crocker, K.T. Pogran, J. Vittal, D.A. Henderson. May 1977. (Format: TXT=75554 bytes) (Obsoleted by RFC0733) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
RFC # 724
NIC #37435 12 May 1977
RFC#724NIC#37435 1977年5月12日
Proposed Official Standard for the
Format of ARPA Network Messages
アーパネットメッセージの形式の提案された公式の規格
by
by
Ken Pogran, MIT-LCS/CSR (Pogran at MIT-Multics)
John Vittal, BBN (Vittal at BBN-TENEXA)
Dave Crocker, RAND-ISD (DCrocker at Rand-Unix)
Austin Henderson, BBN (Henderson at BBN-TENEXD)
ケンPogran、MIT-LCS/CSR(MIT-MulticsのPogran)ジョンVittal、BBN(BBN-TENEXAのVittal)デーヴ・クロッカー、底ならし革-ISD(底ならし革unixにおけるDCrocker)オースチンヘンダーソン、BBN(BBN-TENEXDのヘンダーソン)
Proposed Standard for Message Format / ii
Message Format/iiのための提案されたStandard
PREFACE
序文
ARPA's Committee on Computer-Aided Human Communication
(CAHCOM) wishes to promulgate an official standard for the format
of ARPA Network mail headers which will adequately meet the needs
of the various message service subsystems on the Network today.
The authors of this RFC constitute the CAHCOM subcommittee
charged with the task of developing this new standard; this
document presents our current thoughts on the matter and a
specific proposal.
コンピュータで支援されたHuman Communication(CAHCOM)の上のARPAのCommitteeは今日Networkで適切に様々なメッセージサービスサブシステムの需要を満たすアーパネットメールヘッダの形式の公式の規格について公表したがっています。 このRFCの作者はこの新しい規格を開発するタスクを課されたCAHCOM小委員会を構成します。 このドキュメントはその件と明確な提案に関する私たちの現在の考えを提示します。
This document is organized as follows: First, we present a
history, of the development of what has become known as the ARPA
Network "mail" or "message" service, and the issues which we feel
are most pressing -- problems for which solutions are lacking
today, inhibiting the further development of message subsystems.
We then present the specification for the new ARPA Network
Message Header standard. This is followed by a References
section.
このドキュメントは以下の通りまとめられます: 私たちが感じる問題は最も押されています--最初に私たちはアーパネット「メール」か「メッセージ」サービスとして知られるようになったことに関する開発の歴史を提示します、そして、メッセージサブシステムのさらなる開発を抑制して、ソリューションが今日欠けている問題。次に、私たちは新しいアーパネットMessage Header規格のための仕様を提示します。 これはReferences部によって続かれています。
Essentially, we propose a revision to Request for Comments
(RFC) 561, "Standardizing Network Mail Headers", and RFC 680,
"Message Transmission Protocol". This revision removes and
compacts portions of the previous syntax and adds several
features to network address specification. In particular, we
focus on people and not mailboxes as recipients and allow
reference to stored address lists. We expect this syntax to
provide sufficient capabilities to meet most users' immediate
needs and, therefore, give developers enough breathing room to
produce a new mail transmission protocol "properly". We believe
that there is enough of a consensus in the Network community in
favor of such a standard syntax to make possible its adoption at
this time.
本質的には、Comments(RFC)561、「ネットワークメールヘッダを標準化します」、およびRFC680、「メッセージトランスミッションプロトコル」のために私たちはRequestに改正を提案します。 この改正は、取り外して、前の構文の部分を固まらせて、いくつかの特徴をネットワークアドレス指定に追加します。 私たちは、特に、受取人としてメールボックスではなく、人々に焦点を合わせて、保存された住所録に参照を許します。 私たちは、この構文が「適切に」新しいメールトランスミッションプロトコルを作成する余地を吸い込みながらユーザの即座の需要を最も満たして、したがって、十分を開発者に与えることができるくらいの能力を提供すると予想します。 私たちは、今回の採用を可能にするそのような標準の構文を支持してNetwork共同体のコンセンサスが十分あると信じています。
We would like to make clear the status of this proposed
standard: The CAHCOM Steering Committee has replaced the Message
Service Committee as the ARPANET standards-setting organization
in the area of message services. It is expected that the
proposal of this CAHCOM subcommittee, when in its final form,
will be adopted as an ARPANET standard by CAHCOM. In the
interests of making this standard the best possible one, we are
distributing this proposal as an RFC.
この提案された標準の状態を明らかにしたいと思います: CAHCOM Steering Committeeは規格を設定するアルパネット組織としてメッセージサービスの領域でMessage Service Committeeに取って代わりました。 最終形態にあるとき、このCAHCOM小委員会の提案がアルパネット規格としてCAHCOMによって採用されると予想されます。 この規格を可能な限り良い方にすることのために、私たちはRFCとしてこの提案を広げています。
Please send any comments and criticisms to any of the
authors of this RFC by 15 June 1977. It is planned that the
standard will be officially adopted by 1 September 1977, with
hosts expected to accept its syntax by 1 January 1978.
1977年6月15日までにこのRFCの作者のいずれにもあらゆるコメントと批評を送ってください。 それは計画されています。規格がホストと共に1977年9月1日までに公式に採用されるのが1978年1月1日までに構文を受け入れると予想しました。
Proposed Standard for Message Format / iii
Message Format/iiiのための提案されたStandard
CONTENTS
コンテンツ
I. PROBLEMS WITH ARPANET
MESSAGE STANDARDS
アルパネットメッセージ規格に関するI.問題
A. Background and History
B. Issues and Conclusions
C. Message Parts
D. Adoption of the Standard
規格のA.バックグラウンド、歴史B.問題、および結論C.メッセージ部品D.採用
II. STANDARD FOR THE FORMAT
OF ARPA NETWORK MESSAGES
II。 アルパネットワークメッセージの形式において、標準です。
A. Framework
B. Syntax
C. Semantics
D. Examples
A.フレームワークB.構文C.意味論D.の例
III. REFERENCES
III。 参照
APPENDIX
付録
A. Alphabetical Listing of Syntax Rules
シンタックス・ルールに関するA.アルファベット順リスト
I. Problems with ARPANET Message Standards / 1
A. Background and History
アルパネットメッセージ規格/1A.バックグラウンドと歴史に関するI.問題
I. PROBLEMS WITH ARPANET MESSAGE STANDARDS
アルパネットメッセージ規格に関するI.問題
A. BACKGROUND AND HISTORY
A.バックグラウンドと歴史
Today's ARPA Network "mail" or "message" service uses, for
its delivery mechanism, two special commands of the File Transfer
Protocol. Viewed from within the structure of FTP, the entire
message, both header and text, is data for the FTP MAIL and MLFL
commands. This facility was added to the File Transfer Protocol
as an afterthought; it was an interim solution to be used only
until a separate mail transmission protocol was specified.
Several versions of such a protocol have been proposed, but none
has yet received general acceptance. Meanwhile, attempts have
been made to improve upon the original interim facility.
今日のアーパネット「メール」か「メッセージ」サービスは排紙機構にFile Transferプロトコルの2つの特別なコマンドを使用します。 FTPの構造から見られます、全体のメッセージ(ヘッダーとテキストの両方)はFTPメールのためのデータであり、MLFLは命令します。 この施設は思いついたようにFile Transferプロトコルに追加されました。 初めて、別メールトランスミッションプロトコルが指定されたときしか、使用されるのは、当座のソリューションでした。 そのようなプロトコルのいくつかのバージョンが提案されましたが、まだなにも一般的な承認を受けていません。 その間、オリジナルの当座の施設を改良するのを試みをしました。
As message service subsystems on various host systems
(especially TENEX) developed to the point where rudimentary
parsing of incoming messages was being done, it became clear that
it would be desirable to standardize the format and content of
the headers of messages transmitted between hosts using these FTP
commands. To this end, an ad hoc committee wrote RFC 561, which
suggested a standard message header format. The committee was
unofficial, so it could not legislate a standard, it could only
recommend. However, the standard it suggested adequately met an
urgent need, and was generally adopted.
様々なホストシステム(特にTENEX)の上のメッセージサービスサブシステムが入力メッセージの初歩的な構文解析が行われていたポイントに展開したとき、形式を標準化するのが望ましいだろうというのが明確になって、メッセージのヘッダーの内容は、ホストの間をこれらのFTPコマンドを使用することで伝わりました。 このために、専門委員会はRFC561に書きました。(RFCは標準のメッセージヘッダー形式を勧めました)。 それは、委員会が非公式であったので規格を制定できなかったことを勧めるだけであるかもしれません。 しかしながら、それが示した規格は、適切に緊急の需要を満たして、一般に、採用されました。
Several salient points should be noted:
顕著な数ポイントは注意されるべきです:
1. RFC 561 defined the concept of a message header, and
specified the syntax which delimited it from the actual
text of a message;
1. RFC561はメッセージヘッダーの概念を定義して、メッセージの実際のテキストからそれを区切った構文を指定しました。
2. It proposed a standard format for the most obvious and
most urgently-needed header items: "From:", "Date:", and
"Subject:";
2. それは最も明白で緊急に最も必要なヘッダーの品目のために標準書式を提案しました: 「From:」、「日付:」、および「Subject:」。
3. It proposed that a general standard syntax be used for
all other header items;
3. 一般規格構文が他のすべてのヘッダーの品目に使用されるのは提案しました。
4. RFC 561 is still, today, an unofficial standard, adhered
to by most because of its utility;
4. RFC561は今日、それでもユーティリティのために大部分によって固く守られた非公式の規格です。
5. Its syntax was designed to allow humans to read the text
easily, without the aid of special message processing
systems.
5. 構文は、人間が特別教書処理システムの補助なしでテキストを容易に読むのを許容するように設計されました。
I. Problems with ARPANET Message Standards / 2
A. Background and History
アルパネットメッセージ規格/2A.バックグラウンドと歴史に関するI.問題
As message services grew in sophistication, the need for
specific header items in RFC 561's "miscellaneous" category grew:
"To:" and "cc:", especially, were generated and recognized by
several different message services. However, there was no
specific standard for the syntax of the contents of these items.
The message service subsystems on TENEX developed a particular
format for these items; since more messages originated from the
TENEX hosts on the Network than from any other type of host
system, the TENEX format for these fields soon became a de facto
standard. Message service subsystems on TENEX began to parse
these fields, expecting them to be in the TENEX-generated format.
Message service subsystems on other hosts -- Multics, for example
-- began to dabble with other formats for these fields, since
there was no standard for them, only to receive complaints from
users of TENEX message service subsystems that their "non-
standard" message headers could not be parsed according to the
(de facto) "standard" syntax.
メッセージサービスが洗練で成長したとき、RFC561の「種々雑多な」カテゴリにおける特定のヘッダーの品目の必要性は成長しました: 「To:」 そして、「cc:」は、いくつかの異なったメッセージサービスで特に生成されて、認識されました。 しかしながら、これらの項目のコンテンツの構文のどんな特定の規格もありませんでした。TENEXの上のメッセージサービスサブシステムはこれらの項目のための特定の形式を発生しました。 より多くのメッセージがいかなる他のタイプのホストシステムよりもNetworkにTENEXホストから発したので、これらの分野へのTENEX形式はすぐ、デファクトスタンダードになりました。 TENEXが発生している形式にはそれらがあると予想して、TENEXの上のメッセージサービスサブシステムはこれらの分野を分析し始めました。 他のホストの上のメッセージサービスサブシステム(例えば、Multics)はこれらの分野に他の形式をちょっとかじり始めました、それらの規格が全くなかったので、彼らの「非標準」のメッセージヘッダーがTENEXメッセージサービスサブシステムのユーザであるかもしれませんが、(事実上)の「標準」の構文によると、分析されて、苦情を受けるために、唯一です。
Recognizing that the time had come to make an attempt to
standardize the additional header fields that had come into use
since RFC 561 was published, ARPA's Message Service Committee
chartered a small group in 1975 to develop a revised version of
RFC 561 which would define the syntax of these additional message
header fields. Several things should be noted about this small
group of people: first, they were TENEX-oriented; when the
functionality of the message header items they desired was
matched by the functionality of an already-existing message
header item of the TENEX message subsystems, they adopted the
syntax used by the TENEX message subsystems. Second, they based
additional header items not already found on TENEX message
subsystems on the deliberations of the Message Service Committee.
Third, they were not familiar with the procedure for publication
of a document as a Network RFC.
時間が追加ヘッダーを標準化する試みをRFC561が発行されて以来使用に入っていた分野にするようになったと認めて、ARPAのMessage Service Committeeは、1975年にこれらの追加メッセージヘッダーフィールドの構文を定義するRFC561の改訂版を開発するために小さいグループをチャーターしました。 いくつかのことが人々のこの小さいグループに関して注意されるべきです: まず最初に、それらはTENEX指向でした。 彼らが望んでいたメッセージヘッダーの品目の機能性がTENEXメッセージサブシステムの既に既存のメッセージヘッダーの品目の機能性によって合わせられたとき、彼らはTENEXメッセージサブシステムで使用される構文を採用しました。2番目に、それらは既に見つけられなかった追加ヘッダーの品目をMessage Service Committeeの熟考でのTENEXメッセージサブシステムに基礎づけました。 3番目に、ドキュメントの公表には、それらはNetwork RFCとして手順になじみ深くはありませんでした。
The document which this group produced, labelled RFC 680,
"Message Transmission Protocol", received only limited
distribution. Matters were further confused because its title
was misleading, since it was not a protocol for the transmission
of messages between ARPA Network hosts, but rather a standard for
the format of messages transmitted via the standard File Transfer
Protocol. Some, including the Message Service Committee,
believed that RFC 680 became a Network Standard. This was not
strictly true, because it never received proper distribution, and
it had never been "officially blessed" by anyone, to turn it from
a request for comments into an accepted official ARPA Network
standard document. Reflecting this confusion over the status of
the document are the facts that the document DOES currently
reside in the "official" ARPANET Protocol Handbook, and most
users and message system implementors remain unaware that this is
so.
ラベルされたRFC680、「メッセージトランスミッションプロトコル」というこのグループが製作したドキュメントは限定販路だけを受けました。 タイトルが紛らわしかったので、件はさらに混乱しました、それがアーパネットホストの間のメッセージの伝達のためのプロトコルではなく、むしろ標準のFile Transferプロトコルで送られたメッセージの形式の規格であったので。 Message Service Committeeを含む或るものは、RFC680がNetwork Standardになったと信じていました。 これは厳密に本当ではありませんでした、適切な分配を決して受けないで、それがそれをコメントを求める要求から受け入れられた公式のアーパネット標準のドキュメントにターンするためにだれによっても一度も「公式に祝福されたことがなかった」ので。 ドキュメントの状態の上のこの混乱を反映するのは、ドキュメントDOESが現在「公式」のアルパネットプロトコルHandbookに住んでいるという事実です、そして、これがそうであるのを気づかないほとんどのユーザとメッセージシステム作成者はままです。
I. Problems with ARPANET Message Standards / 3
A. Background and History
アルパネットメッセージ規格/3A.バックグラウンドと歴史に関するI.問題
For all its shortcomings, RFC 680 has performed a needed
service, just as did RFC 561 before it. It defined additional
message header items at a time when this needed to be done.
Unfortunately, since the group had not sought ideas and input
from others, the specification did not adequately respond to a
sufficient set of community needs. In addition, the manner in
which the document was promulgated -- or not promulgated -- left
a great deal to be desired. Implementators of message-processing
subsystems who had not received RFC 680 proceeded to go their own
ways, feeling justified in doing so, while those who accepted RFC
680 as a standard felt justified in complaining to -- and about
-- those whom they considered to be maverick implementors of
idiosyncratic message service subsystems.
すべての短所のために、RFC680はそれの前にちょうどRFC561のように必要なサービスを実行しました。 これがする必要があったとき、それは追加メッセージヘッダーの品目を定義しました。 残念ながら、グループが他のものからの考えと入力を求めていなかったので、仕様は適切に十分な地域のニーズに応じませんでした。 さらに、ドキュメントが公表されたか、または公表されなかった方法は、多くが望まれているのを残しました。 RFC680を受けていなかったメッセージ処理サブシステムのImplementatorsがそうするのにおいて正当であると感じて、それら自身の道がものと、そして、彼らが特有のメッセージサービスサブシステムの一匹おおかみ作成者であると考えたものの周りに関して不平を言いながら正当であると感じられた規格としてRFC680を認めたものをゆったり過ごす碁に続きました。
Perhaps because of the ad-hoc nature of the interim mail
facility, users have not, until recently, attempted to push the
system to the limits of their imagination. Presently, however,
several different sites are using the "interim" mail facility for
more than it was designed and in ways which are incompatible both
with each other and with the original intent of the facility.
Mail subsystem implementors are increasingly being asked to
provide for the handling of mail from idiosyncratic hosts. Also,
it has become clear that there are a few very specific features,
too useful to ignore, which cannot reasonably be specified within
the syntax of RFC 680.
恐らく当座の郵便施設の臨時の本質のために、ユーザは、最近まで彼らの想像の限界にシステムを押すのを試みていません。 しかしながら、現在、いくつかのそれが設計されていて互いと施設の当初の意図と両立しない方法であったのと異なったサイトが以上に「当座」の郵便施設を使用しています。 メールサブシステム作成者が特有のホストからメールの取り扱いに備えるようにますます頼まれています。 また、RFC680の構文の中で合理的に指定できないいくつかの非常に特定の無視できないくらい役に立つ特徴があるのは明確になりました。
B. ISSUES AND CONCLUSIONS
B.問題と結論
At first glance, it would seem that a resolution of today's
somewhat chaotic situation could best be obtained by immediately
junking the existing "interim" mail facility, and adopting a true
mail transmission protocol. We strongly believe that this would
be ill-advised at this time, for we feel that there is no general
understanding within the Network community today of how to
specify and implement a full and adequate mail transmission
protocol. However, we are convinced that there is, finally, a
strong commitment within the Network community to attack this
problem (which there was not at the time the "interim" mail
transmission facility was specified and developed).
一見したところでは、すぐにまでに既存の「当座」の郵便施設を廃棄して、正しいメールトランスミッションプロトコルを採用しながら今日のいくらか混沌の状況の解決を得ることができたのが最も良いように思えるでしょう。 私たちは、これがこのときあさはかであると強く信じています、私たちが、今日の完全で適切なメールトランスミッションプロトコルを指定して、どう実装するかに関するNetwork共同体の中に一般的な意味解釈が全くないと感じるので。 しかしながら、私たちはこの問題を攻撃するためにNetwork共同体の中に強い委任が最終的にある(どれが当時でない、「当座」のメール通信施設があったかは指定されて、開発された)と確信しています。
The frontal attacks on the mail protocol problem have, so
far, resulted in at least two suggestions for a mail transmission
protocol. Why should not one of these protocols be adopted
immediately? We feel that, in general, there has been a tendency
for experimental Network software to be prematurely treated as
though it were adequately designed and fully operational.
Typically, the system or protocol proposed is so much better than
what was previously available that its experimental nature is
disregarded, and it is pressed into service before it has had a
メールプロトコル問題の正攻法は今までのところ、メールトランスミッションプロトコルのための少なくとも2つの提案をもたらしました。 なぜすぐに、これらのプロトコルの1つを採用しないべきですか? 私たちは、一般に、まるでそれが適切に設計されていて完全に操作上であるかのように実験用Networkソフトウェアが早まって扱われる傾向があったと感じます。 通常、提案されたシステムかプロトコルがそのように無視されるほうがよいです、そして、aがある前にそれはサービスに押し込まれます。
I. Problems with ARPANET Message Standards / 4
B. Issues and Conclusions
アルパネットメッセージ規格/4B.問題と結論に関するI.問題
chance to properly develop and mature. We are very concerned
that this phenomenon not afflict the Network mail system any more
than it already has.
適切に開発して、たまたま熟してください。 私たちは非常に関係があります。この現象は既に苦しめるほどNetworkメールシステムを苦しめません。
While it is true that there are several sites in the ARPA
Community which have mail systems that understand the syntax
specified in RFC's 561 and 680, in addition to some of the "non-
standard" syntax provided by the mail generating programs at
several other sites, most mail systems do not parse much of the
contents of received messages. A consideration of the syntax
specified here is that messages which are sent to people should
be easily read by people. Parsers which can turn an ugly,
syntactically expedient form into something which is easy to read
are the exception, rather than the rule, in today's message
systems. Also, the modifications to the existing "non-standard"
syntax should be kept to a minimum, enhancing the probability
that the requirement of small perturbations to existing software
will be accepted.
いくつかのサイトがRFCの561と680で指定された構文を理解しているメールシステムを持っているARPA Communityにあるのが、本当である間、他のいくつかのサイトでプログラムを生成するメールによって提供された「非標準」の構文のいくつかに加えて、ほとんどのメールシステムは受信されたメッセージのコンテンツの多くを分析しません。 ここで指定された構文の考慮は人々に送られるメッセージが人々によって容易に読まれるべきであるということです。 醜くて、シンタクス上好都合なフォームを読みやすい何かに変えることができるパーサは規則よりむしろ例外です、今日のメッセージシステムで。また、既存の「標準的でない」構文への変更は最小限に保たれるべきです、既存のソフトウェアへの小さい摂動の要件を受け入れるという確率を高めて。
With this syntax, we introduce mechanisms so that:
したがって、この構文で、私たちがメカニズムを紹介する、それ:
1. Users of mail systems can have multiple mailboxes, either
on one machine or multiple machines, all of which are
treated identically; the default mailbox for a user is
not necessarily associated (directly) with his login
name.
1. メールシステムのユーザは複数のメールボックスを持つことができます、1台のマシンか複数のマシンの上でそれのすべてが同様にマシンのために扱われます。 ユーザのためのデフォルトメールボックスは必ず(直接)彼のログイン名に関連づけられるというわけではありません。
2. Mail for a person can be sent to other than a single,
default mailbox.
2. 単一のデフォルトメールボックスを除いて、人のためのメールに発信できます。
3. Named groups may consist of both individuals and
(possibly) other named groups (i.e., nesting within
groups is permitted).
3. 命名されたグループは個人と(ことによると)他の命名されたグループの両方から成るかもしれません(すなわち、グループの中で巣ごもるのは受入れられます)。
4. Address lists may contain references to other, stored,
lists. The complete path with which one can retrieve the
stored list may be specified in order to allow either
manual or automatic retrieval of the stored list.
4. 住所録は他の、そして、保存されたリストの参照を含むかもしれません。 どれが保存されたリストを検索できるかで完全な経路は、保存されたリストの手動の、または、自動である検索を許すために指定されるかもしれません。
5. Address lists may contain references to addresses which
are not accessible through the standard ARPANET message
system. For example, U.S. Postal system addresses can
be specified. Such addresses are, of course, expected to
be ignored by the ARPANET system, although individual
sites may provide services for using the information
(e.g., automatically sending a copy of the message to a
line printer, in preparation for transmission through the
Postal system).
5. 住所録は標準のアルパネットメッセージシステムを通して理解できないアドレスの参照を含むかもしれません。 例えば、米国Postalシステムアドレスを指定できます。 アルパネットシステムによってそのようなアドレスが無視されるともちろん予想されます、個々のサイトは情報(例えば、自動的に、Postalシステムを通したトランスミッションに備えてメッセージのコピーをラインプリンタに送る)を使用するためのサービスを提供するかもしれませんが。
6. Parenthetical remarks, or comments, can be included and
syntactically recognized as such within some header
items.
6. 挿入句的な発言、またはコメントを含んでいて、いくつかのヘッダーの品目の中でシンタクス上そういうものとして認識できます。
I. Problems with ARPANET Message Standards / 5
B. Issues and Conclusions
アルパネットメッセージ規格/5B.問題と結論に関するI.問題
7. Received messages are capable of being read by humans
without a program having to parse the message (or parts
of it) before presenting the message to the user; however
there is sufficient formal syntax to enable a parsing
program to modify the appearance and content of material
presented to users. Although message-display software
may exercise considerable control over message
appearance, the degree to which a message's actual format
is PLEASANT for humans to read is entirely the
responsibility of the message creation program.
7. 人間は受信されたメッセージはユーザにメッセージを提示する前にメッセージ(または、それの部品)を分析しなければならないプログラムなしで読むことができます。 しかしながら、構文解析プログラムがユーザに寄贈された材料の外観と内容を変更するのを可能にすることができるくらいの正式な構文があります。 メッセージディスプレイソフトウェアはかなりのコントロールをメッセージ外観に及ぼすかもしれませんが、メッセージの実際の形式が読む人間のためのPLEASANTである度合いは完全にメッセージ作成プログラムの責任です。
No mechanism for authentication is provided, since the Network
provides no mechanisms for enforcing mail security. The syntax
does provide for one aspect of "correctness": a distinction is
made between an address which is claimed to be a valid network
address and one which is simply free text, included for the
convenience of the human participants.
Networkがメールセキュリティを実施するのにメカニズムを全く提供しないので、認証のためのメカニズムを全く提供しません。 構文は「正当性」の1つの局面に備えます: 有効なネットワーク・アドレスであると主張されるアドレスと人間の関係者の都合のために含まれていた単に無料のテキストであるものの間で区別をします。
C. MESSAGE PARTS
C.メッセージの部品
Some confusion has existed over the roles played by
different message parts. Einar Stefferud has suggested using the
perspective of envelope, letter head, and letter content. The
presence of structured portions in messages additionally requires
reference to "headers".
何らかの混乱が異なったメッセージの部品によって果たされた役割の上に存在しました。 Einar Stefferudは、封筒、レターヘッド、および手紙内容の見解を使用するのを示しました。 メッセージでの構造化された部分の存在はさらに、「ヘッダー」の参照を必要とします。
In computer-based message systems, human users do not
generally encounter "envelopes", which are often constructed
automatically, to be used by the participating system(s) to
deliver the message. For example on TENEX, the envelope is the
name of the file containing a message awaiting transmission. For
FTP servers, it is the data portion of the MAIL or MLFL command
line. Some systems attach "envelope-like" information to the
message header, such as time-stamp and originating host name.
一般に、コンピュータベースのメッセージシステムでは、人間のユーザは「封筒」に遭遇しません。(それは、メッセージを参加システムによって使用されて、提供するためにしばしば自動的に組み立てられます)。 例えば、TENEXの上では、封筒はトランスミッションを待つメッセージを含むファイルの名前です。 FTPサーバのために、それはメールかMLFLコマンドラインのデータ部です。 いくつかのシステムがメッセージヘッダーへの「封筒のような」情報、タイムスタンプや起因することなどのホスト名を付けます。
In paper-based communications, headers occur both before
(e.g., "To:" and "From:" and after (e.g., "cc:" and "enclosure:")
the body of the message. Within this standard, all headers occur
before the body of the message, although local message display
programs may choose to alter that ordering.
そして、紙のベースのコミュニケーションでは、ヘッダーが起こる、ともに以前、(例えば、「To:」と「From:」、後、(例えば、「cc:」、「包囲:」、)、メッセージ欄. この規格の中では、すべてのヘッダーがメッセージ欄の前に起こります、ローカルのメッセージディスプレイプログラムは、その注文を変更するのを選ぶかもしれませんが。
Wayne Hathaway has pointed out that ARPANET message format
does not support specification of letterheads, since these are a
type of organizational public relations symbol. Some
idiosyncrasies are supported, however, by way of choosing special
field names.
ウェインハザウェイは、アルパネットメッセージ・フォーマットがレターヘッドの仕様をサポートしないと指摘しました、これらが一種の組織的な広報シンボルであるので。 しかしながら、特別なフィールド名を選ぶことを通していくつかの特異性がサポートされます。
In general, it is important to realize that the header
portion of a message plays several roles during the life of a
一般に、メッセージのヘッダー部分がaの寿命の間いくつかの役割を果たすとわかるのは重要です。
I. Problems with ARPANET Message Standards / 6
C. Message Parts
アルパネットメッセージ規格/6C.メッセージの部品に関するI.問題
message, variously participating in each of the three functions
suggested by Stefferud.
さまざまにStefferudによって勧められたそれぞれの3つの機能に参加するメッセージ。
D. ADOPTION OF THE STANDARD
規格のD.採用
During the early phases of specifying this standard, a great
deal of concern was expressed over the problems which may be
experienced during the transition from the current standard to
this new one. We feel that the true problem is the lack of
realization that THERE IS NO CURRENT OFFICIAL STANDARD. Enough
systems have enough overlapping behaviors to allow the current
mail environment to function, but this in no way constitutes a
standard.
この規格を指定する早めの段階の間、多くの関心が現在の規格から新しいこれまでの変遷の間に経験されるかもしれない問題の上に述べられました。 私たちは、本当の問題が実現の不足であると感じます。そのTHERE IS NO CURRENT OFFICIAL STANDARD。 十分なシステムには、現在のメール環境が機能するのを許容できるくらいの重なっている振舞いがありますが、これは規格を決して構成しません。
In fact, we strongly believe that the new requirements
imposed by the proposed standard involve less complexity than the
ambiguities resulting from the current variations in system
behaviors.
事実上、私たちは、提案された標準によって課された新しい要件がシステムの振舞いにおける海流変化から生じるあいまいさより少ない複雑さを伴うと強く信じています。
II. Standard for the Format of Messages / 7
II。 メッセージ/7の形式において、標準です。
II. STANDARD FOR THE FORMAT
OF ARPA NETWORK MESSAGES
II。 アルパネットワークメッセージの形式において、標準です。
This standard supercedes the informal standards specified in
ARPANET Request for Comments numbers 561, "Standardizing Network
Mail Headers", and 680, "Message Transmission Protocol". In this
document, a general framework is described. The formal syntax is
then specified, followed by a discussion of the semantics.
Finally, a number of examples are given.
非公式の規格がComments No.561のためのアルパネットRequest、「ネットワークメールヘッダを標準化します」、および680、「メッセージトランスミッションプロトコル」で指定したこの標準のsupercedes。 本書では、一般的なフレームワークは説明されます。 そして、意味論の議論があとに続いていて、正式な構文は指定されます。 最終的に、多くの例が出されます。
This specification is intended strictly as a definition of
what is to be passed between hosts on the ARPANET. It is NOT
intended to dictate either features which systems on the Network
are expected to support, or user interfaces to message creating
or reading programs.
この仕様はアルパネットでホストの間で通過されることになっているべきものに関する定義として厳密に意図します。 それがNetworkの上のシステムがサポートすると予想される特徴かユーザインタフェースのどちらかをプログラムを作成するか、または読むメッセージに書き取ることを意図しません。
A distinction should be made between what the specification
requires and what it allows. Certain equivalences are defined,
such as between a space character <space> and an end-of-line
character <crlf>, which both facilitate the formal specification
and indicate what the OFFICIAL semantics are for messages.
Particular implementations may wish to preserve further
distinctions which the specification does not require.
仕様が必要とすることとそれが許容することの間で区別をするべきです。 ある等価性は定義されます、スペースキャラクタ<スペース>や行末文字<crlf>などのように。(>は形式仕様を容易にして、OFFICIAL意味論がメッセージのための何であるかを示します)。 特定の実装は仕様が必要としないさらなる区別を保存したがっているかもしれません。
A. FRAMEWORK
A.フレームワーク
Since there are many message systems which exist outside the
ARPANET environment, as well as those within it, it may be useful
to consider the general framework, and resulting capabilities and
limitations, of this standard.
それの中にアルパネット環境、およびそれらの外に存在する多くのメッセージシステムがあるので、一般的なフレームワーク、結果として起こる能力、および限界を考えるのはこの規格で役に立つかもしれません。
Messages are expected to consist of lines of text. No
special provisions are made, at this time, for encoding drawings,
facimile, speech, or structured text.
メッセージがテキストの系列から成ると予想されます。 特別条項は、全くこのとき、図面、facimile、スピーチ、または構造化されたテキストをコード化するために作られません。
No significant consideration has been given to questions of
data compression or transmission/storage efficiency. The
standard, in fact, tends to be very free with the number of bits
consumed. For example, field names are specified as free text,
rather than special terse codes.
データ圧縮かトランスミッション/ストレージ効率の質問に対してどんな重要な考慮も払っていません。 事実上、規格は、ビットの数が消費されている状態で非常に自由である傾向があります。 例えば、フィールド名は特別な簡潔なコードよりむしろ無料のテキストとして指定されます。
A general "memo" framework is used. That is, a message
consists of some information, in a rigid format, followed by the
main part of the message, which is text and whose format is not
一般的な「メモ」フレームワークは使用されています。 すなわち、メッセージは何らかの情報から成ります、メッセージの主部があとに続いたテキストと形式がだれのものでないということである堅い形式で
II. Standard for the Format of Messages / 8
A. Framework
II。 メッセージ/8A.フレームワークの形式において、標準です。
specified in this document. The syntax of several fields of the
rigidly-formated ("header") section is defined in this
specification; some of the header fields must be included in all
messages. In addition to the fields specified in this document,
it is expected that other fields will gain common use. User-
defined header fields allow systems to extend their functionality
while maintaining a uniform framework. Our approach is similar
to that of the TELNET protocol, in that we are defining a basic
standard which includes a mechanism for (optionally) extending
itself. The authors of this document will regulate the
publishing of specifications for these extensions.
このドキュメントでは、指定されています。 厳格にformatedされた(「ヘッダー」)セクションのいくつかの分野の構文はこの仕様に基づき定義されます。 すべてのメッセージにヘッダーフィールドのいくつかを含まなければなりません。 本書では指定された分野に加えて、他の分野が一般の使用を獲得すると予想されます。 ユーザの定義されたヘッダーフィールドで、システムは一定のフレームワークを維持している間、それらの機能性を広げることができます。 私たちのアプローチはTELNETプロトコルのものと同様です、私たちが(任意に)広がるためのメカニズム自体を含んでいる基本的な規格を定義しているので。 このドキュメントの作者はこれらの拡大のための仕様の出版を規制するでしょう。
Such a framework severely constrains document "tone" and
appearance and is primarily useful for most intra-organization
communications and relatively structured inter-organization
communication. A more robust environment might allow for multi-
font, multi-color, multi-dimension encoding of information. A
less robust environment, as is present in most single-machine
message systems, would more severely constrain the ability to add
fields and the decision to include specific fields. Relative to
paper-based communication, it is interesting to note that the
RECEIVER of a message can exercise an extraordinary amount of
control over the message's appearance. The amount of actual
control available to message receivers is contingent upon the
capabilties of their individual message systems.
そのようなフレームワークは、厳しく「トーン」というドキュメントと外観を抑制して、主としてほとんどのイントラ組織コミュニケーションと比較的構造化された相互組織コミュニケーションの役に立ちます。 より強健な環境は情報のマルチフォントの、そして、マルチ色の、そして、マルチ寸法のコード化を考慮するかもしれません。 ほとんどの単一マシンメッセージシステムでのプレゼントのように、それほど強健でない環境は、より厳しく、分野を加える能力と特定の分野を含んでいるという決定を抑制するでしょう。 紙のベースのコミュニケーションに比例して、メッセージのRECEIVERが並はずれた量のコントロールをメッセージの外観に及ぼすことができることに注意するのはおもしろいです。 メッセージ受信機に利用可能な実際のコントロールの量がそれらの個々のメッセージシステムのcapabilties次第であります。
II. Standard for the Format of Messages / 9
B. Syntax
II。 メッセージ/9B.構文の形式において、標準です。
B. SYNTAX
B.構文
This syntax is given in four parts. The first part
describes a base-level lexical analyzer which feeds the higher-
level parser described in the succeeding sections. The second
part gives a general syntax for messages and standard header
fields. The third part specifies the syntax of addresses. A
final section specifies some general syntax which supports the
other sections.
4つの部品でこの構文を与えます。 最初の部分は続くセクションで説明されたより高い平らなパーサを与える基準面の語彙分析器について説明します。 第二部はメッセージと標準のヘッダーフィールドのために一般的な構文を与えます。 3番目の部分はアドレスの構文を指定します。 最後のセクションは他のセクションをサポートする何らかの一般的な構文を指定します。
1. LEXICAL ANALYSIS OF MESSAGES
1. メッセージの字句解析
a. General Description
a。 概説
A message consists of headers and, optionally, a body (i.e.
the <message-text>). The <message-text> part is just a
sequence of ASCII characters; it is separated from the
headers by a null line (i.e., a line with nothing preceding
the <crlf>).
メッセージはヘッダーと任意にボディー(すなわち、<メッセージ・テキスト>)から成ります。 <メッセージ・テキスト>部分はただASCII文字の系列です。 空行(すなわち、何も<crlf>に先行していない系列)によってそれはヘッダーと切り離されます。
1) Folding and unfolding of headers
1) ヘッダーの折り重なりと開き
Each header item can be viewed as a single, logical, long
line of ASCII characters. For convenience, this
conceptual entity can be split into a multiple-line
representation (i.e., "folded"). The general rule is that
wherever there can be <linear-white-space> characters, you
can instead insert a <crlf> immediately followed by AT
LEAST one <linear-white-space> character. Thus, the
single line
ASCII文字の単一の、そして、論理的で、長い系列としてそれぞれのヘッダーの品目を見なすことができます。 便利において、この概念的な実体を複数の系列表現(すなわち、「折り重なる」)に分けることができます。 どこに<直線的な余白>キャラクタがあることができ、あなたが代わりにすぐにAT LEAST1<直線的な余白>キャラクタによって後をつけられた<crlf>を挿入できても、一般的な規則はそれです。 その結果、単線
To: "Joe Dokes & J. Harvey" <ddd at Host>, JJV at BBN
To: ホスト>、BBNのJJVの「ジョーDokesとJ.ハーヴェイ」<ddd
can be represented as
表すことができます。
To: "Joe Dokes & J. Harvey" <ddd at Host>,
JJV at BBN
To: ホスト>、BBNのJJVの「ジョーDokesとJ.ハーヴェイ」<ddd
and
そして
To: "Joe Dokes & J. Harvey"
<ddd at Host>,
JJV at BBN
To: ホスト>、BBNのJJVの「ジョーDokesとJ.ハーヴェイ」<ddd
II. Standard for the Format of Messages / 10
B. Syntax
1. Lexical Analysis
II。 メッセージ/10B.構文1の形式において、標準です。 字句解析
and
そして
To: "Joe Dokes
& J. Harvey" <ddd at Host>, JJV at BBN
To: ホスト>、BBNのJJVの「ジョーDokesとJ.ハーヴェイ」<ddd
The process of moving from this folded multiple-line
representation of a header field to its single line
representation will be called "unfolding". Unfolding is
accomplished by regarding <crlf> immediately followed by a
<linear-white-space-char> as equivalent to the <linear-
white-space-char>.
ヘッダーフィールドのこの折り重ねられた複数の系列表現から単線表現まで移行するプロセスは「開き」と呼ばれるでしょう。 開きは、すぐに<の直線的に白いスペース炭の>に同じくらい同等な<直線的に白いスペースの炭の>によって続かれた<crlf>を見なすことによって、実行されます。
2) Structure of header fields
2) ヘッダーフィールドの構造
Once header fields have been unfolded, they may be viewed
as being composed of a <field-name> followed by a ":"
(colon), followed by a <field-body>. The <field-name>
must be composed of printable ASCII characters (i.e.,
characters which have decimal values between 33 and 126)
and <linear-white-space> characters. The <field-body> may
composed of any ASCII characters (other than <cr> and
<lf>, which have been removed by unfolding).
「ヘッダーフィールドがいったん繰り広げられると、それらは>がa」を続けた<フィールド名で構成されるように見られるかもしれません」 (コロン), <分野はボディー>のあとに続いています。 印刷可能なASCII文字(すなわち、デシマル値を33と126の間持っているキャラクタ)と<直線的な余白>キャラクタで<フィールド名>を構成しなければなりません。 >がそうする<分野本体はどんなASCII文字(<cr>と<lf>を除いた)でも構成しました。>は、開くことによって、取り外されました。
Certain header fields may be interpreted according to an
internal syntax which some systems may wish to parse.
These fields will be referred to as structured fields.
Examples include fields containing dates and addresses.
Other fields, such as the subject field, are regarded
simply as a single line of text.
いくつかのシステムが分析したがっているかもしれない内部の構文によると、あるヘッダーフィールドは解釈されるかもしれません。 これらの野原は構造化された分野と呼ばれるでしょう。 例は日付とアドレスを含む分野を含んでいます。 対象の分野などの他の分野は単にただ一つのテキスト行と見なされます。
3) Field names
3) フィールド名
To aid in the creation and reading of <field-name>s, the
free insertion of <linear-white-space> characters is
allowed in reasonable places. Rather than obscuring the
syntax specification for <field-name> with the explicit
syntax for these <linear-white-space> characters, the
existence of a simple "lexical" analyzer is assumed. The
analyzer reinterprets the unfolded text which comprises
the <field-name> as a sequence of <atoms> separated by
<linear-white-space> characters. The field name may be
conveniently represented by the sequence of these atoms,
separated by a single ASCII space character.
<フィールド名>sの作成と読書で支援するために、<直線的な余白>キャラクタの無料の挿入は妥当な場所に許容されています。 これらの<直線的な余白>キャラクタのために明白な構文で<フィールド名>のための構文仕様をあいまいにするよりむしろ、簡単な「語彙」の分析器の存在は想定されます。 分析器は<直線的な余白>キャラクタによって切り離された<原子>の系列として<フィールド名>を包括する繰り広げられたテキストを解釈し直します。 フィールド名はただ一つのASCII間隔文字によって分離されたこれらの原子の系列によって便利に表されるかもしれません。
II. Standard for the Format of Messages / 11
B. Syntax
1. Lexical Analysis
II。 メッセージ/11B.構文1の形式において、標準です。 字句解析
4) Field bodies
4) 分野本体
To aid in the creation and reading of structured fields,
the free insertion of <linear-white-space> characters is
allowed in reasonable places. Rather than obscuring the
syntax specifications for these structured fields with
explicit syntax for these <linear-white-space> characters,
the existence of another simple "lexical" analyzer is
assumed. It provides an interpretation of the unfolded
text comprising the body of the field as a sequence of
lexical symbols. These include
構造化された分野の作成と読書で支援するために、<直線的な余白>キャラクタの無料の挿入は妥当な場所に許容されています。 これらの<直線的な余白>キャラクタのために明白な構文でこれらの構造化された分野のための構文仕様をあいまいにするよりむしろ、別の簡単な「語彙」の分析器の存在は想定されます。 それは語彙シンボルの系列として分野のボディーを包括する繰り広げられたテキストの解釈を提供します。 これらのインクルード
- individual special characters
- quoted strings
- comments
- atoms
- 個々の特殊文字--引用文字列--コメント--原子
The first three symbols are self-delimiting. Atoms are
not; they therefore are delimited by the self-delimiting
symbols and by <linear-white-space>.
最初の3つのシンボルは自己区切りです。 原子はそうではありません。 したがって、それらは自己を区切るシンボルと<の直線的な余白>によって区切られます。
So, for example, the folded body of an address field
そう、例えば、アドレス・フィールドの折り重ねられたボディー
":sysmail"@ Some-Host,
Muhammed(I am the greatest)Ali at WBA
「: sysmail」@Some-ホスト、WBAのマホメット(私は最も偉大である)・アリ
is analyzed into the following lexical symbols and types:
以下の語彙シンボルとタイプに分析されます:
":sysmail" quoted string
@ special
Some-Host atom
, special
Muhammed atom
(I am the greatest) comment
Ali atom
at atom
WBA atom
「: sysmail」引用文字列の@の特別なSome-ホスト原子、原子WBA原子の特別なマホメット原子(私は最も偉大である)コメントアリ原子
b. Formal Definition
b。 公式の定義
<field> ::= <field-name> ":" <field-body>
<field-name> ::= <atom>
| <atom> <field-name>
<分野>:、:= 「<フィールド名>」:、」 <分野本体><フィールド名>:、:= <原子>。| <原子><フィールド名>。
<field-body> ::= <field-body-contents>
| <field-body-contents> <crlf>
<linear-white-space-char>
<field-body>
<分野本体>:、:= <分野本体コンテンツ>。| <分野本体コンテンツ>の<のcrlfの>の<の直線的に白いスペース炭の><分野本体>。
II. Standard for the Format of Messages / 12
B. Syntax
1. Lexical Analysis
II。 メッセージ/12B.構文1の形式において、標準です。 字句解析
<field-body-contents> ::= <the TELNET ASCII characters making
up the <field-body>, as defined in
the following sections, and
consisting of combinations of
<atom>, <quoted-string>, <text-line>,
and <specials> tokens>
<分野本体コンテンツ>:、:= 以下のセクションで定義されて、<原子>、<引用文字列>、<テキスト線>、および<特別番組>象徴>の組み合わせから成るとして<分野本体>を作るTELNET ASCII文字の<。
<atom> ::= <a sequence of one or more TELNET
ASCII alpha-numeric or graphics
characters, excluding all control
characters (those characters with
a decimal value less than 33 or
equal to 127) and <delimeters> >
<原子>:、:= 1つ以上のTELNET ASCIIアルファベット数字式の<a系列かすべての制御文字を除いたグラフィックスキャラクタ(小数があるそれらのキャラクタは33未満か同輩を127に評価する)と<delimeters>>。
<quoted-string> ::= <double quote mark ("), decimal 34>
<a sequence of one or more TELNET
ASCII characters, where two
adjacent quotes are treated as a
single quote and part of the
string> <">
<引用文字列>:、:= <の二重引用符、(「)、1人以上のTELNET ASCII文字の10進34><a系列。(そこでは、2つの隣接している引用文がストリング><">"のただ一つの引用文と一部として扱われます)。
<text-line> ::= <a sequence of one or more TELNET
ASCII characters excluding <cr>
and <lf> >
<テキスト線>:、:= <は<cr>と<lf>>を除いた1人以上のTELNET ASCII文字の系列です。
<message-text> ::= <a sequence of zero of more TELNET
ASCII characters>
<メッセージ・テキスト>:、:= <は、より多くのTELNET ASCII文字>のゼロの系列です。
<delimeters> ::= <specials> | <comment>
| <linear-white-space> | <crlf>
<delimeters>:、:= <特別番組>。| <コメント>。| <直線的な余白>。| <crlf>。
<specials> ::= "(" | ")" | "<" | ">"
| "@" | "," | ";" | ":" | <">
<特別番組>:、:= "(" | ")" | "<"| ">"| "@" | "," | ";" | ":" | <">"
<comment> ::= "(" <TELNET ASCII characters, except
<crlf> > ")"
<コメント>:、:= 「(「<crlf>>以外の<TELNET ASCII文字」)」
<linear-white-space>::= <linear-white-space-char>
| <linear-white-space-char>
<linear-white-space>
<linear-white-space-char>::= <space> | <horizontal-tab>
<直線的な余白>:、:= <の直線的に白いスペース炭の>。| <の直線的に白いスペース炭の>の<の直線的な余白の>の<の直線的に白いスペース炭の>:、:= <スペース>。| <水平タブ>。
<space> ::= <TELNET ASCII space (decimal 32)>
<tab> ::= <TELNET ASCII tab (decimal 9)>
<cr> ::= <TELNET ASCII carriage return
(decimal 13)>
<lf> ::= <TELNET ASCII line feed (decimal 10)>
<crlf> ::= <TELNET ASCII carriage return/line
feed (decimal 13, followed by
decimal 10)>
<スペース>:、:= <TELNET ASCIIスペース(10進32)><タブ>:、:= <TELNET ASCIIは><cr>にタブを付けます(10進9):、:= <TELNET ASCII復帰(10進13)><lf>:、:= <TELNET ASCII改行(10進10)><crlf>:、:= <TELNET ASCII復帰/改行(10進13 10進10があとに続いていて、>。
II. Standard for the Format of Messages / 13
B. Syntax
1. Lexical Analysis
II。 メッセージ/13B.構文1の形式において、標準です。 字句解析
c. Clarifications
c。 明確化
1) Comments
1) コメント
Comments may appear only within <field-body>s of
structured fields. A comment is any set of TELNET ASCII
characters, which is not within a quoted string, and which
is enclosed in matching parentheses; parentheses nest, so
that if a left paren occurs in a comment string, there
must also be a matching right paren.
コメントは構造化された分野の<分野本体>sだけの中に現れるかもしれません。 コメントはTELNET ASCII文字のあらゆるセットです。(それは、引用文字列の中になくて、合っている括弧に同封されます)。 括弧巣、左のparenであるならコメントストリングに起こって、また、あるに違いないように、マッチング権利はparenされます。
Comments are NOT passed to the FTP server, as part of a
MAIL or MLFL command, since comments are not part of the
"formal" address.
コメントはFTPサーバに通過されません、メールかMLFLコマンドの一部として、コメントが「正式な」アドレスの一部でないので。
2) "White space"
2) 「余白」
Remember that in structured fields, MULTIPLE LINEAR WHITE
SPACE TELNET ASCII CHARACTERS (namely <tab>s and <space>s)
ARE TREATED AS SINGLE SPACES AND MAY FREELY SURROUND ANY
SYMBOL. In all header fields, at least one <space> is
REQUIRED only at the beginning of folded lines.
構造化された分野(MULTIPLE LINEAR WHITE SPACE TELNET ASCII CHARACTERS(すなわち、<タブ>sと<スペース>s)ARE TREATED AS SINGLE SPACES AND MAY FREELY SURROUND ANY SYMBOL)でそれを覚えていてください。 すべてのヘッダーフィールドでは、少なくとも1<のスペース>は単に折り重ねられた線の始めのREQUIREDです。
Writers of mail-sending (i.e. header generating) programs
should realize that there is no Network-wide definition of
the effect of <tab> TELNET ASCII characters on the
appearance of text at another Network host; therefore, the
use of <tab>s in message headers, though permitted, is
discouraged.
メール発信(すなわち、ヘッダー発生)プログラムの作家は、<タブ>TELNET ASCIIキャラクタのテキストの外観への効果のどんなNetwork全体の定義も別のNetworkホストにないとわかるべきです。 したがって、受入れられますが、メッセージヘッダーにおける<タブ>sの使用はお勧めできないです。
Note that the contents of messages are required to conform
with TELNET NVT conventions (e.g. <cr> must be followed
by either <lf>, making a <crlf>, or <null>, if the <cr> is
to stand alone).
メッセージの内容がTELNET NVTコンベンションに従うのに必要であることに注意してください(<lf>は例えば<cr>に続かなければなりません、<をcrlf>、または<のヌル>にして、<cr>が単独で立つつもりであるなら)。
3) Quoted strings
3) 引用文字列
Where permitted (i.e., in structured fields) quoted
strings are treated as a single symbol (i.e. equivalent
to an <atom> syntactically). However, if quoted strings
are to be "folded" onto multiple lines, then the syntax
for folding must be adhered to (See items II.B.1.a.1,
above, and II.B.1.c.6, below.) Note that the official
semantics do not encounter <crlf>s in quoted strings,
although particular parsing programs may wish to note
their presence.
受入れられる(すなわち、構造化された分野の)ところでは、引用文字列がただ一つのシンボルとして扱われる、(すなわち、<原子>に同等である、シンタクス上) しかしながら、「引用文字列が複数の線に折り重ねられる」ことであるなら、折り重ねのための構文を固く守らなければなりません(項目の上のII.B.1.a.1、および以下のII.B.1.c.6を見てください。)。 引用文字列の遭遇<crlf>sではなく、公式の意味論がそうする注意、特定の構文解析プログラムですが、それらの存在に注意することを願うかもしれません。
II. Standard for the Format of Messages / 14
B. Syntax
1. Lexical Analysis
II。 メッセージ/14B.構文1の形式において、標準です。 字句解析
4) Bracketing characters
4) 大括弧のキャラクタ
There are two types of brackets which must be well nested:
よく入れ子にしなければならない2つのタイプの括弧があります:
- Parentheses are used to indicate comments.
- 括弧は、コメントを示すのに使用されます。
- Angle brackets ("<" and ">") are used
where there is a question of the presence
of machine-usable code (e.g. deliminating
mailboxes).
- 角ブラケット("<"と">")はマシン使用可能なコード(例えば、メールボックスをdeliminatingする)の存在の問題があるところで使用されます。
5) Case independence of certain specials <atom>s
5) ある特別番組<原子>sからのケース独立
It should be assumed by all mail reading programs that
certain <atom>s can be represented in any combination of
upper and lower case. These are:
大文字と小文字のどんな組み合わせでもある<原子>sを表すことができるとすべてのメール読み込みプログラムで思われるべきです。 これらは以下の通りです。
- <field-name>s,
- "File", in a <path>,
- "at", in an <at-indicator>,
- <host-name>s,
- <day-of-week>s,
- <string-month>s, and
- <time-zone>s
- そして、<フィールド名>s--<経路の「ファイルしてください」という>--インディケータ>(<ホスト名>s)<日の<の“at"、-、-、週の>s--<ストリング月の>s、--、<時間帯の>s
For example, the <field-name>s "From", "FROM", "from", and
even "FroM" should all be treated identically. Note that,
at the level of this specification, case IS relevant to
other <word>s and <text-line>s. Also see Section
II.C.1.a.4, below.
例えば、<フィールド名>sの“From"、“FROM"、“from"、および“FroM"さえ同様にすべて扱われるべきです。 ケースがこの仕様のレベルで他の<単語>sと<テキスト線>sに関連していることに注意してください。 また、以下のセクションII.C.1.a.4を見てください。
6) Folding long lines
6) 折りたたみの長い線
Each header item (field of the message) may be represented
on exactly one line consisting of the name of the field
and its body, and this is what the parser sees. For
readability, it is recommended that the <field-body>
portion of long header items be "folded" onto multiple
lines of the actual header.
それぞれのヘッダーの品目(メッセージの分野)は分野とそのボディーの名前から成りながら、まさに1つの線の上に表されるかもしれません、そして、これはパーサが見るものです。 読み易さにおいて、長いヘッダーの品目のボディーをさばいている<>部分が実際のヘッダーの複数の線に「折り重ねられること」は、お勧めです。
7) Backspace characters
7) 後退文字
Backspace TELNET ASCII characters (ASCII BS, decimal 8)
may be included in <text-line> and <quoted-string> to
effect overstriking; however, any use of backspaces which
effects an overstrike to the left of the beginning of the
<text-line> or <quoted-string> is prohibited.
バックスペースキーを押して印字位置を一字分戻ってください。TELNET ASCII文字(ASCII BS、10進8)は<テキスト線>と<引用文字列>で効果「過剰-打撃」に含められるかもしれません。 しかしながら、いずれも使用する、バックスペースキー、どれが重ね打ちに<テキスト線の>か<引用文字列>の始まりの左まで作用するかは禁止されています。
II. Standard for the Format of Messages / 15
B. Syntax
2. Messages
II。 メッセージ/15B.構文2の形式において、標準です。 メッセージ
2. GENERAL SYNTAX OF MESSAGES:
2. メッセージの一般的な構文:
NOTE: The syntax indicates that items in <required-headers>
must be in a specific order and precede all other header
items. Header fields, in fact, are NOT required to occur in
any particular order. Required header items must be unique
(occur exactly once). This specification permits multiple
occurrences of most optional fields. However, the
interpretation of such multiple occurrences is not specified
here.
以下に注意してください。 構文は、<の必要なヘッダーの>の項目が特定のオーダーにあって、他のすべてのヘッダーの品目に先行しなければならないのを示します。事実上、ヘッダーフィールドは、どんな特定のオーダーにも起こるのに必要ではありません。 必要なヘッダーの品目はユニークであるに違いありません(まさに一度起こってください)。 この仕様はほとんどの任意の分野の複数の発生を可能にします。 しかしながら、そのような複数の発生の解釈はここで指定されません。
<message> ::= <headers>
| <headers> <crlf> <message-text>
<メッセージ>:、:= <ヘッダー>。| <ヘッダー><crlf><メッセージ・テキスト>。
<headers> ::= <required-headers>
| <required-headers> <optional-headers>
<required-headers> ::= <date-field> <originator>
<originator> ::= <mach-from-field>
| <mach-from-list> <sender-field>
| <mach-from-field> <reply-to-field>
| <any-from-field> <sender-field>
<reply-to-field>
<ヘッダー>:、:= <の必要なヘッダーの>。| 必要なヘッダーの<の<任意のヘッダーの><必要なヘッダーの>>:、:= <年月日欄><創始者><創始者>:、:= <mach、-、分野>。| <、-machに、リスト>から、<は>を送付者と同じくらいさばきます。| <mach、-、分野><回答から分野への>。| <、-いくらか、分野><から><回答から分野への>を送付者と同じくらいさばいてください。
<date-field> ::= "Date" ":" <date-time>
<mach-from-field> ::= "From" ":" <mach-addr-item>
<mach-from-list> ::= "From" ":" <mach-addr-list>
<any-from-field> ::= "From" ":" <address-list>
<sender-field> ::= "Sender" ":" <host-phrase>
<reply-to-field> ::= "Reply-To" ":" <mach-addr-list>
<年月日欄>:、:= 「「デートしてください」」:、」 <日付-時間><mach、-、分野>から:、:= ""From"":、」 <のmach-addr-品目><mach、-、リスト>から:、:= ""From"":、」 <mach-addr-リスト><、いくらか、-、分野>から:、:= ""From"":、」 <住所録><送付者分野>:、:= 「「送付者」」:、」 <ホスト句の><回答から分野への>:、:= 以下に「「答え」」、」 <mach-addr-リスト>。
<optional-headers>::= <optional-header-field>
| <optional-headers>
<optional-header-field>
<の任意のヘッダーの>:、:= <任意のヘッダーフィールド>。| <の任意のヘッダーの><任意のヘッダーフィールド>。
<optional-header-field> ::= <addressee-field>
| <extension-field>
<任意のヘッダーフィールド>:、:= <受け取り人分野>。| <拡張子分野>。
<addressee-field> ::= "To" ":" <address-list>
| "cc" ":" <address-list>
| "bcc" ":" <address-list>
| "Fcc" ":" <path-list>
<受け取り人分野>:、:= ""To"":、」 <住所録>。| 「「cc」」:、」 <住所録>。| 「"bcc"」:、」 <住所録>。| 「"Fcc"」:、」 <経路リスト>。
<extension-field> ::= "In-Reply-To" ":" <reference-list>
| "Keywords" ":" <phrase-list>
| "Message-Id" ":" <mach-host-phrase>
| "References" ":" <reference-list>
| "Subject" ":" <text-line>
| "Comments" ":" <text-line>
| <user-defined-field>
<拡張子分野>:、:= 以下、「「に対して」」」 <参考文献一覧表>。| 「「キーワード」」:、」 <句リスト>。| 「「メッセージイド」」:、」 <mach-ホスト句の>。| 「「参照」」:、」 <参考文献一覧表>。| 「「対象」」:、」 <テキスト線>。| 「「コメント」」:、」 <テキスト線>。| <のユーザによって定義された分野の>。
II. Standard for the Format of Messages / 16
B. Syntax
2. Messages
II。 メッセージ/16B.構文2の形式において、標準です。 メッセージ
<user-defined-field> ::= <A <field> which has a <field-name>
not defined in this specification>
<のユーザによって定義された分野の>:、:= <は>がこの仕様>で定義しなかった<フィールド名を持っている<分野>です。
The following syntax for the bodies of various fields should be
thought of as describing each field body as a single long string
(or line). The section on Lexical Analysis (section II.B.1)
indicated how such long strings can be represented on more than
one line in the actual transmitted message.
多岐のボディーのための以下の構文はそれぞれの分野本体をただ一つのロング・ストリングとして記述すると考えられるべきです(立ち並んでください)。 Lexical Analysis(セクションII.B.1)の上のセクションは実際の伝えられたメッセージの1つ以上の線の上にどうそのようなロング・ストリングを表すことができるかを示しました。
3. SYNTAX OF GENERAL ADDRESSEE ITEMS
3. 一般的な受け取り人項目の構文
<mach-addr-list> ::= <mach-addr-item>
| <mach-addr-item> "," <address-list>
<mach-addr-リスト>:、:= <のmach-addr-品目>。| 「<のmach-addr-品目>」、」 <住所録>。
<address-list> ::= <null>
| <address-item>
| <address-item> "," <address-list>
<address-item> ::= <mach-addr-item>
| <group-name> ":" <address-list> ";"
| <any-name>
| <path>
<住所録>:、:= <のヌル>。| <アドレス項目>。| 「<アドレス品目>」、」 <住所録><アドレス品目>:、:= <のmach-addr-品目>。| 「<グループ名>」:、」 「<住所録>」;、」 | <、いくらか名義の>。| <経路>。
<mach-addr-item> ::= <mailbox>
| <phrase> "<" <mailbox-list> ">"
<のmach-addr-品目>:、:= <メールボックス>。| <句の>"<"<メールボックスリスト>">"
<group-name> ::= <phrase>
<any-name> ::= <quoted-string>
<グループ名>:、:= <句の><、いくらか名義の>:、:= <引用文字列>。
<mailbox-list> ::= <mailbox>
| <mailbox> "," <mailbox-list>
<mailbox> ::= <host-phrase>
<メールボックスリスト>:、:= <メールボックス>。| 「<メールボックス>」、」 <メールボックスリスト><メールボックス>:、:= <ホスト句の>。
<path> ::= ":" "File" ":" <path-name>
<path-name> ::= <path-item>
| "<" <path-list> ">"
<path-list> ::= <path-item>
| <path-item> "," <path-list>
<path-item> ::= <host-phrase>
<経路>:、:= ":" 「「ファイルしてください」」:、」 <パス名><パス名>:、:= <経路項目>。| "<"<経路リスト>">"<経路リスト>:、:= <経路項目>。| 「<経路品目>」、」 <経路リスト><経路項目>:、:= <ホスト句の>。
II. Standard for the Format of Messages / 17
B. Syntax
4. Supporting Constructs
II。 メッセージ/17B.構文4の形式において、標準です。 構造物を支持します。
4. SUPPORTING SYNTAX
4. 構文をサポートします。
<reference-list> ::= <null>
| <reference-item>
| <reference-item> "," <reference-list>
<reference-item> ::= <phrase>
| <mach-host-phrase>
<参考文献一覧表>:、:= <のヌル>。| <参照項目>。| 「<参照品目>」、」 <参考文献一覧表><参照品目>:、:= <句の>。| <mach-ホスト句の>。
<mach-host-phrase>::= "<" <host-phrase> ">"
<host-phrase> ::= <phrase> <host-indicator>
<host-indicator> ::= <at-indicator> <host-name>
<at-indicator> ::= "at" | "@"
<host-name> ::= <atom>
| <decimal host address>
<mach-ホスト句の>:、:= "<"<ホスト句の>">"<ホスト句の>:、:= <句の><ホストインディケータ><ホストインディケータ>:、:= インディケータにおけるインディケータ><ホスト名><>の<:、:= "at"| "@"<ホスト名>:、:= <原子>。| <の10進ホスト・アドレス>。
<date-time> ::= <day> <date> <time>
<day> ::= <null>
| <day-of-week> ","
<day-of-week> ::= "Monday" | "Mon"
| "Tuesday" | "Tue"
| "Wednesday" | "Wed"
| "Thursday" | "Thu"
| "Friday" | "Fri"
| "Saturday" | "Sat"
| "Sunday" | "Sun"
<date> ::= <string-date>
| <slash-date>
<string-date> ::= <day-of-month> <string-month>
<4-digit-year>
<slash-date> ::= <numeric-month> "/" <date-of-month>
"/" <2-digit-year>
<numeric-month> ::= <one or two decimal digits>
<day-of-month> ::= <one or two decimal digits>
<string-month> ::= "January" | "Jan"
| "February" | "Feb"
| "March" | "Mar"
| "April" | "Apr"
| "May"
| "June" | "Jun"
| "July" | "Jul"
| "August" | "Aug"
| "September"| "Sep"
| "October" | "Oct"
| "November" | "Nov"
| "December" | "Dec"
<4-digit-year> ::= <four decimal digits>
<2-digit-year> ::= <two decimal digits>
<time> ::= <24-hour-time> "-" <time-zone>
<24-hour-time> ::= <hour> <minute>
<hour> ::= <two decimal digits>
<minute> ::= <two decimal digits>
<日付-時間>:、:= <日><日付の><時間><日>:、:= <のヌル>。| 「<日、-、週、>、」、」 <日、-、-、週の>:、:= 「月曜日」| 「月曜日」| 「火曜日」| 「火曜日」| 「水曜日」| 「水曜日」| 「木曜日」| 「木曜日」| 「金曜日」| 「金曜日」| 「土曜日」| 「座っています」| 「日曜日」| 「Sun」<は>とデートします:、:= <ストリング日付>。| <スラッシュ日付><ストリング日付>:、:= -月では、><ストリング月の><4ケタ年の><が>とスラッシュでデートする<日:、:= 」 「<の数値月の>」/<がデートされる、-、月、>、」 /」 <2ケタ>の<の数値月の年>:、:= 10進数字><<1日か2日、-、-、月の>:、:= <の10進数字><ストリング1カ月か2カ月の>:、:= 「1月」| 「1月」| 「2月」| 「2月」| 「3月」| 「3月」| 「4月」| 「4月」| 「5月」| 「6月」| 「6月」| 「7月」| 「7月」| 「8月」| 「8月」| 「9月」| 「9月」| 「10月」| 「10月」| 「11月」| 「11月」| 「12月」| 「12月」<4ケタ年の>:、:= <の4 10進数字><2ケタ年間の>:、:= <two10進数字><時間>:、:= <24時間-時間>「-」<時間帯の><24時間-時間>:、:= <>の<の微小な><一時間の時間>:、:= <の2の10進数字><微小な>:、:= <two10進数字>。
II. Standard for the Format of Messages / 18
B. Syntax
4. Supporting Constructs
II。 メッセージ/18B.構文4の形式において、標準です。 構造物を支持します。
<time-zone> ::= "GMT" | "Z" | "GDT"
| "AST" | "ADT"
| "EST" | "EDT" | "CST" | "CDT"
| "MST" | "MDT" | "PST" | "PDT"
| "YST" | "YDT" | "HST" | "HDT"
<の時間帯の>:、:= 「グリニッジ標準時」| 「Z」| "GDT"| "AST"| "ADT"| 「米国東部標準時」です。| 「東部夏時間」です。| "CST"| "CDT"| "MST"| "MDT"| 「太平洋標準時」です。| 「太平洋夏時間」です。| "YST"| "YDT"| "HST"| "HDT"
<phrase> ::= <word>
| <word> <phrase>
<phrase-list> ::= <null>
| <phrase>
| <phrase> "," <phrase-list>
<句の>:、:= <単語>。| <単語><句の><句リスト>:、:= <のヌル>。| <句の>。| 「<句の>」、」 <句リスト>。
<word> ::= <atom>
| <quoted-string>
<単語>:、:= <原子>。| <引用文字列>。
II. Standard for the Format of Messages / 19
C. Semantics
1. Address Fields
II。 メッセージ/19C.意味論1の形式において、標準です。 アドレス・フィールド
C. SEMANTICS
C.意味論
1. ADDRESS FIELDS
1. アドレス・フィールド
a. General
a。 一般
1) <path>s are used to refer to a location, on the ARPANET,
containing a stored address list. The <phrase> should
contain text which the referenced host can resolve to a
file. This standard is not a protocol and so does not
prescribe HOW data is to be retrieved from the file.
However, the following requirements are made:
1) 格納された住所録を含んでいて、<経路>sは、アルパネットで位置について言及するのに使用されます。 <句の>は参照をつけられたホストがファイルに決議できるテキストを含むはずです。 この規格はプロトコルとそうがHOWデータを定めないaがファイルから検索されることになっているということではありません。 しかしながら、以下の要件は作られています:
- the file must be accessible through the local
operating system interface (if it exists), given
adequate user access rights; and
- 適切なユーザアクセス権を考えて、ファイルは地方のオペレーティングシステムインタフェース(存在しているなら)を通してアクセス可能であるに違いありません。 そして
- if a host has an FTP server and a user is able to
retrieve any files from the host using that server,
then the file must be accessible through FTP, using
DEFAULT transfer settings, given adequate user access
rights.
- ホストにはFTPサーバがあって、ユーザがそのサーバを使用することでホストからのどんなファイルも取ることができるなら、ファイルはFTPを通してアクセス可能であるに違いありません、DEFAULT転送設定を使用して、適切なユーザアクセス権を考えて。
It is intended that this mechanism will allow programs to
retrieve such lists automatically.
プログラムがこのメカニズムで自動的にそのようなリストを検索できることを意図します。
The interpretation of a <path> follows. This is not
intended to imply any particular implementation scheme, but
is included to aid in understanding the notion of <path>s:
<経路>の解釈は続きます。 これは、どんな特定の実現計画も含意することを意図しませんが、<経路>sの概念を理解する際に支援するために含まれています:
- The contents of the file indicated by a <path-name> is
treated as an <address-list> and is inserted as an
<address-item> in the position of the <path-name> item
in the syntax. That is, the TELNET ASCII character
string of the <path-name> or, if present, the <path-
list> containing it, is replaced by the contents of
the file to which the <path-name> refers. Therefore,
the contents of the file indicated by a <path-name>
must be syntactically self-contained and must adhere
to the full syntax prescribed herein for <address-
list>.
- ファイルのコンテンツは、<パス名で>が<住所録>として扱われて、項目を記述している<>として構文で<パス名>の品目の位置に挿入されるのを示しました。 すなわち、<パス名>か存在しているときの<のTELNET ASCII文字列をそれを含む>を経路で記載して、<パス名>が参照されるファイルのコンテンツに取り替えます。 したがって、ファイルのコンテンツは、<パス名で>がシンタクス上自己充足的でなければならないことを示して、<アドレスリスト>のためにここに定められた完全な構文を固く守らなければなりません。
- <Path-item>s of a <path-list> are alternates and the
contents of ONLY ONE of them is to be included in the
resultant address list.
- a<経路リスト>の<経路項目>sは補欠です、そして、彼らのONLY ONEのコンテンツは結果の住所録に含まれることです。
2) The <phrase> part of a <mailbox> is understood to be
whatever the receiving FTP Server allows (for example,
2) 受信FTP Serverが何を許容しても<メールボックス>の<句の>部分による理解されている、(例えば。
II. Standard for the Format of Messages / 20
C. Semantics
1. Address Fields
II。 メッセージ/20C.意味論1の形式において、標準です。 アドレス・フィールド
TENEX systems do not now understand addresses of the form
"P. D. Q. Bach", but another system might).
TENEXシステムは現在、フォーム「P」のアドレスを理解していません。 D。 Q。 しかし、「バッハ」、別のシステム力)
Note that a <mailbox> is a conceptual entity which does not
necessarily pertain to file storage. For example, some
sites may choose to print mail on their line printer and
deliver the output to the addressee's desk.
<メールボックス>が必ずファイル記憶装置に関係するというわけではない概念的な実体であることに注意してください。 例えば、いくつかのサイトが、それらのラインプリンタにメールを印刷して、受け取り人の机に出力を届けるのを選ぶかもしれません。
A user may have several mailboxes. The use of the second
alternative of <mach-addr-item> (<phrase> "<" <mailbox-
list> ">") indicates that a copy of the message is to be
sent to EACH mailbox named.
ユーザは数個のメールボックスを持っているかもしれません。 <のmach-addr-品目>(<句の>"<"<メールボックスリスト>">")の2番目の代替手段の使用は、メッセージのコピーが指定された各メールボックスに送られることであることを示します。
3) <any-name> may contain any sequence of "words". This
sequence of words, used as an <address-item>, is used to
facilitate reference to non-standard (e.g. non-Network)
addresses. Such an address might be one which is
acceptable to the U.S. Postal Service.
3) <、-いくらか、名前>は「単語」のどんな系列も含むかもしれません。 単語のこの項目>が<アドレスとして使用された続きは、標準的でない(例えば、非ネットワーク)アドレスの参照を容易にするのに使用されます。 そのようなアドレスは米国Postal Serviceに許容できるものであるかもしれません。
4) The <host-name> in a <host-phrase> must be THE official
name of a Network host, or else a decimal number indicating
the Network address for that host. The USE OF NUMBERS IS
STRONGLY DISCOURAGED and is permitted only due to the
occasional necessity of bypassing local host-name tables.
4) <ホスト句の<ホスト名>>はNetworkホストの正式名称、またはそのホストのためにNetworkアドレスを示す10進数であるに違いありません。 そして、USE OF NUMBERS IS STRONGLY DISCOURAGED、支払われるべきものだけが地方のホスト名テーブルを迂回させるという時々の必要性に受入れられます。
The <phrase> in a <host-phrase> is intended to be
meaningful only to the indicated host. To all other hosts,
the <phrase> is treated as a literal string. No case
transformations should be (automatically) performed on the
<phrase>. The <phrase> is passed to the local host's mail
sending program; it is the responsibility of the
destination host's mail receiving (distribution) program to
perform case mapping on this <phrase>, if required, to
deliver the mail.
句をホスティングしている<>の<句の>が示されたホストだけに重要であることを意図します。 他のすべてのホストに、<句の>は文字通りのストリングとして扱われます。 変化が(自動的に)<句の>に実行されるべきであるのは、ケースではありません。 <句の>はローカル・ホストのメール送付プログラムに渡されます。 それはあて先ホストのメール受信(分配)プログラムがケースを実行する必要なら、郵便を配達するためにこの<句で>を写像する責任です。
b. Originator Fields
b。 創始者分野
WARNING: The standard allows only a subset of the
combinations possible with the From,
Sender, and Reply-to fields. The
limitation is intentional; the permitted
alternatives have been carefully chosen
and are adequate for the purposes of this
standard.
警告: そして、規格がFrom、Senderで可能な組み合わせの部分集合だけを許容する、Reply、-、分野。 制限は意図的です。 受入れられた代替手段は、慎重に選ばれて、この規格の目的のために適切です。
II. Standard for the Format of Messages / 21
C. Semantics
1. Address Fields
II。 メッセージ/21C.意味論1の形式において、標準です。 アドレス・フィールド
1) From:
1) From:
This field contains the identity of the person(s) who
wished this message to be sent. The message-creation
process should default this field to be a single machine
address, indicating the user entering the message; if and
only if this is done, the "Sender:" field need not be
present.
この分野はこの送られるべきメッセージを願っていた人のアイデンティティを含んでいます。 メッセージ創造の過程がデフォルトとするべきである、メッセージを入力するユーザを示す単一マシンアドレスであるこの分野。 そして、これが完了している場合にだけ「送付者:」 分野は存在している必要はありません。
2) Sender:
2) 送付者:
This field contains the identity of the person who sends
the message. It need not be present in the header of the
message if it is the SAME as the "From:" field.
この分野はメッセージを送る人のアイデンティティを含んでいます。 それが「From:」としてSAMEであるならメッセージのヘッダーに存在している必要はありません。 さばきます。
The <sender-field-body> includes a <phrase> which must
correspond to a user, rather than a standard <address-
item>, to indicate the expectation that the field will
refer to the PERSON responsible for sending the mail and
not simply include the name of a mailbox, from which the
mail was sent. For example in the case of a shared login
name, the name, by itself, would not be adequate. The
<phrase> (user) is a system entity, not a generalized
person reference.
<送付者分野本体>は項目を記述している標準の<>よりむしろユーザに文通されなければならない<句の>を含んでいて、分野が言及する期待を示すために、簡単ではなく、メールを送るのに責任があるPERSONはメールボックスの名前を含んでいます。(メールはメールボックスから送られました)。 例えば、共有されたログイン名の場合では、名前はそれ自体で適切でないでしょう。 <句の>(ユーザ)は一般化された人の参照ではなく、システム実体です。
3) Reply-to:
3) reply-to
This field provides a general mechanism for indicating any
mailbox(es) to which responses are to be sent. Three
different uses for this feature can be distinguished. In
the first case, the author(s) may not have regular
machine-based mailboxes and therefore wish to indicate an
alternate machine address. In the second case, an author
may wish additional persons to be made aware of, or
responsible for, responses; responders should send their
replies to the "Reply-to:" mailbox(es). More interesting
is a case such as text-message teleconferencing in which an
automatic distribution facility is provided and a user
submitting an "entry" for distribution only needs to send
their message to the mailbox(es) indicated in the "Reply-
to:" field.
この分野は送られる応答がことであるどんなメールボックス(es)も示すのに一般的機構を提供します。 この特徴への3つの異なった用途を区別できます。 前者の場合、作者は、通常のマシンベースのメールボックスを持って、したがって、交互の機械語アドレスを示したがっていないかもしれません。 作者が2番目の場合では、追加人々を意識する、または責任があるようにしたがっているかもしれない、応答。 応答者は「reply-to」に彼らの回答を送るべきです。 メールボックス(es)。 よりおもしろいのが、自動分配施設が提供されるテキストメッセージ電子会議などのケースであり、分配のための「エントリー」を提出するユーザは、「以下に関する回答」で示されたメールボックス(es)にそれらのメッセージを送る必要があるだけです。 さばきます。
If there is no <reply-to-field>, then the <from-field> MUST
contain AT LEAST ONE machine address. In all cases when
used and even if a <sender> field is present, the Reply-to
field must contain at least one machine address.
<回答から分野への>が全くなければ、分野>からの<はAT LEAST ONE機械語アドレスを含まなければなりません。 使用され、<送付者>分野が存在していても中に、すべてがいつをケースに入れるか、Reply、-、分野、少なくとも1つの機械語アドレスを含まなければなりません。
NOTE: For systems which automatically generate address lists
for replies to messages, the following requirements are made:
以下に注意してください。 回答のための住所録をメッセージに自動的に発生させるシステムにおいて、以下の要件は作られています:
II. Standard for the Format of Messages / 22
C. Semantics
1. Address Fields
II。 メッセージ/22C.意味論1の形式において、標準です。 アドレス・フィールド
- The receiver, when replying to a message, must NEVER
automatically include the <sender-field-body> in the
reply's address list
- メッセージに答えるとき、受信機は回答の住所録に自動的に<送付者分野本体>を決して含んではいけません。
- If the <reply-to-field> exists, then the reply should
go ONLY to the <reply-to-field-body> addressees.
- <回答から分野への>が存在しているなら、回答は<回答から分野本体への>受け取り人のものになるだけであるべきです。
(Extensive examples are provided in Section II.D.) This
recommendation is intended only for <originator-field>s and in
no way is intended to reflect that replies should not be sent,
also, to the other recipients of this message. It is up to
the respective mail handling programs as to what additional
facilities will be provided.
(セクションII.D.によく知られている例を提供します) この推薦は、<創始者分野>sだけに意図して、また、回答が送られるべきでないのを反映することをこのメッセージの他の受取人に決して意図しません。 それはどんな追加の便宜供与を提供するかに関するそれぞれのメール取り扱いプログラム次第です。
c. Receiver Fields
c。 あて先欄
1) To:
1) To:
This field contains the identity of the primary recipients
of the message.
この分野はメッセージの第一の受取人のアイデンティティを含んでいます。
2) cc:
2) cc:
This field contains the identity of the secondary
recipients of the message.
この分野はメッセージの二次受取人のアイデンティティを含んでいます。
3) Bcc:
3) Bcc:
This field contains the identity of additional recipients
of the message who are to remain hidden from the primary
and secondary recipients. Some systems may choose to
include the text of the "Bcc:" field only in the
author(s)'s copy, while others may include it in the text
sent to all those indicated in the "Bcc:" list.
この分野は第一の、そして、二次の受取人隠されたままで残ることになっているメッセージの追加受取人のアイデンティティを含んでいます。 いくつかのシステムが、「Bcc:」のテキストを含んでいるのを選ぶかもしれません。 作者のものだけでコピーをさばいてください、他のものは「Bcc:」で示されたすべてのものに送られたテキストでそれを入れるかもしれませんが 記載してください。
4) Fcc:
4) Fcc:
This field contains the identity of any message files in
which copies of this message are being placed by the
originator. Note that the presence of this field does NOT
guarantee long-term availability of the message in any of
the indicated files.
この分野はこのメッセージのコピーが創始者によって置かれているどんなメッセージファイルのアイデンティティも含んでいます。 この分野の存在が示されたファイルのどれかのメッセージの長期の有用性を保証しないことに注意してください。
II. Standard for the Format of Messages / 23
C. Semantics
2. Reference Specification Fields
II。 メッセージ/23C.意味論2の形式において、標準です。 関連仕様書分野
2. REFERENCE SPECIFICATION FIELDS
2. 関連仕様書分野
a. Message-Id:
a。 メッセージイド:
This field contains a unique identifier (the <phrase>) to
refer to this version of this message. The uniqueness of the
message identifier is guaranteed by each host. This
identifier is intended to be machine readable, and not
necessarily meaningful to humans. A message-id pertains to
exactly one instantiation of a particular message; subsequent
revisions to the message should receive new message-id's.
この分野はこのメッセージのこのバージョンを示すユニークな識別子(<句の>)を含んでいます。 メッセージ識別子のユニークさは各ホストによって保証されます。 この識別子は読み込み可能で、人間には、必ず重要であるというわけではないマシンであることを意図します。 メッセージイドはまさに特定のメッセージの1つの具体化に関係します。 メッセージへのその後の改正は新しいイドのメッセージものを受け取るべきです。
b. In-Reply-To:
b。 以下に対して
The contents of this field identify previous correspondence
which this message answers. If message identifiers are used
in this field, they should be enclosed in angle brackets (<>).
この分野の内容はこのメッセージが答える前の通信を特定します。 メッセージ識別子がこの分野で使用されるなら、それらは角ブラケット(<>)に同封されるべきです。
c. References:
c。 参照:
The contents of this field identify other correspondence which
this message references. If message identifiers are used,
they should be enclosed in angle brackets (<>).
この分野の内容はこのメッセージが参照をつける他の通信を特定します。 メッセージ識別子が使用されているなら、それらは角ブラケット(<>)に同封されるべきです。
d. Keywords:
d。 キーワード:
This field contains keywords or phrases, separated by commas.
この分野はコンマによって切り離されたキーワードか句を含んでいます。
3. OTHER FIELDS AND SYNTACTIC ITEMS
3. 他の分野と構文の項目
a. Subject:
a。 Subject:
The "subject:" field is intended to provide as much
information as necessary to adequately summarize or indicate
the nature of the message.
「subject:」 分野が適切にメッセージの本質をまとめるか、または示すために必要なだけの情報を提供することを意図します。
b. Comments:
b。 コメント:
Permits adding text comments onto the message without
disturbing the contents of the message's body.
メッセージのボディーのコンテンツを擾乱しないでテキストコメントをメッセージに追加する許可証。
II. Standard for the Format of Messages / 24
C. Semantics
4. Dates
II。 メッセージ/24C.意味論4の形式において、標準です。 日付
4. DATES
4. 日付
It is recommended that, because of differing international
interpretations, the <string-day> option be used instead of
the <slash-day> option in the specification of a <day>.
異なった国際的な解釈による日を結んでいる<>オプションが<日の仕様に基づく日の>オプションをなでぎりしている<>の代わりに使用されるのは、お勧めです。
If included, <day-of-week> must be the day implied by the
<date> specification.
含まれているなら、-週では、>が日でなければならない<日は、<で仕様と>をデートするように含意しました。
<Time-zones> allow reference to Greenwich and to each of the
zones in the United States. The zone references beginning
with "A" are for Atlantic time which are one hour faster than
the corresponding Eastern times. "Y" indicates Yukon time in
Alaska, which is one hour slower than the corresponding
Pacific times, and "H" indicates Hawaiian times, which are two
hours slower.
<時間帯の>はグリニッジと合衆国のそれぞれのゾーンの参照を許します。 「A」と共に始まるゾーン参照が大西洋時間、あります(対応するイースタン回よりある時間速いです)。 (アラスカは、対応する太平洋の回より1時間遅いです)。「Y」はアラスカでユーコンテリトリー時間を示します、そして、「H」はハワイの時勢を示します。(時勢は2時間より遅いです)。
II. Standard for the Format of Messages / 25
D. Examples
II。 メッセージ/25D.の例の形式において、標準です。
D. EXAMPLES
D.の例
1. ADDRESSES
1. アドレス
a. Alfred E. Newman <Newman at BBN-TENEXA>
Newman@BBN-TENEXA
a。 BBN-TENEXA> Newman@BBN-TENEXA のアルフレッド・E.ニューマン・<ニューマン
These two "Alfred E. Newman" examples have identical
semantics, as far as the operation of the local host's mailer
and the remote host's FTP server are concerned. In the first
example, the "Alfred E. Newman" is ignored by the mailer, as
"Newman at BBN-TENEXA" completely specifies the recipient.
The second example contains no superfluous information, and,
again, "Newman@BBN-TENEXA" is the intended recipient.
これらの2つの「アルフレッド・E.ニューマン」の例には、同じ意味論があります、ローカル・ホストの郵送者とリモートホストのFTPサーバの操作に関する限り。 最初の例では、「アルフレッド・E.ニューマン」は郵送者によって無視されます、「BBN-TENEXAのニューマン」が受取人を完全に指定するとき。 2番目の例はどんな余計な情報も含んでいません、そして、一方、" Newman@BBN-TENEXA "は意図している受取人です。
b. Al Newman at BBN-TENEXA
b。 BBN-TENEXAのアル・ニューマン
This is identical with "Al Newman<Al Newman at BBN-TENEXA>."
That is, the full <phrase>, "Al Newman", is passed to the FTP
server. Note that not all FTP servers accept multi-word
identifiers; and some that do accept them will treat each word
as a different addressee (in this case, attempting to send a
copy of the message to "Al" and a copy to "Newman").
これは「BBN-TENEXA>のアル・ニューマン・<アル・ニューマン」と同じです。 「アル・ニューマン」というすなわち、完全な<句の>はFTPサーバに渡されます。すべてのFTPサーバが句動詞識別子を受け入れるというわけではないことに注意してください。 そして、それらを受け入れる或るものが異なった受け取り人(この場合「アル」へのメッセージのコピーと「ニューマン」へのコピーを送るのを試みる)として各単語を扱うでしょう。
c. "George Lovell, Ted Hackle" <Shared-Mailbox at Office-1>
c。 「ジョージ・ラベル、テッド首回りの毛」 オフィス-1における<の共有されたメールボックス>。
This form might be used to indicate that a single mailbox is
shared by several users. The quoted string is ignored by the
originating host's mailer, as "Shared-Mailbox at Office-1"
completely specifies the destination mailbox.
このフォームは、単一のメールボックスが数人のユーザによって共有されるのを示すのに使用されるかもしれません。 引用文字列が送信元ホストの郵送者によって無視される、「共有されたメールボックス、オフィス1インチ、完全である、あて先メールボックスを指定する、」
d. Wilt (the Stilt) Chamberlain at NBA
d。 NBAのウィルト(竹馬)・チェンバレン
The "(the Stilt)" is a comment, which is NOT included in the
destination mailbox address handed to the originating system's
mailer. The address is the string "Wilt Chamberlain", with
exactly one space between the first and second words. (The
quotation marks are not included.)
「(竹馬)」はコメントです。(そのコメントは由来しているシステムの郵送者に手渡されたあて先メールボックスアドレスに含まれていません)。 アドレスはストリングちょうど1番目と2番目の間のスペースが言い表す1がある「ウィルト・チェンバレン」です。 (引用符は含まれていません。)
II. Standard for the Format of Messages / 26
D. Examples
II。 メッセージ/26D.の例の形式において、標準です。
2. ADDRESS LISTS
2. 住所録
Gourmets: Pompous Person <WhoZiWhatZit at Cordon-Bleu>,
Cooks: Childs at WGBH, Galloping Gourmet at
ANT (Australian National Television);
Wine Lovers: Drunk at Discount-Liquors,
Port at Portugal;;,
Jones at SEA
グルメ: 青綬>、コックのもったいぶっている人の<WhoZiWhatZit: WGBHのアリ(オーストラリアの全国テレビ放送)でグルメを駆けさせるチャイルズ ワインラヴァーズ: 割り引き酒、ポルトガルのポートの酔っぱらい。, 海のジョーンズ
This group list example points out the use of comments, the
nesting of groups, and the mixing of addresses and groups.
Note that the two consecutive semi-colons preceding "Jones at
SEA" mean that Jones is NOT a member of the Gourmets group.
このグループリストの例はコメントの使用、グループの巣篭もり、およびアドレスとグループの混合を指摘します。 「海のジョーンズ」に先行する2つの連続したセミコロンが、ジョーンズがGourmetsグループのメンバーでないことを意味することに注意してください。
3. ORIGINATOR ITEMS
3. 創始者項目
a. George Jones logs into his Host as "Jones". He sends mail
himself.
a。 ジョージ・ジョーンズは「ジョーンズ」として彼のHostにログインします。 彼は自分でメールを送ります。
From: Jones at Host
or
From: George Jones <Jones at Host>
From: ホストかFrom:のジョーンズ ホスト>のジョージ・ジョーンズ・<ジョーンズ
b. George Jones logs in as Jones on his Host. His secretary, who
logs in as Secy on her Host (SHost) sends mail for him.
Replies to the mail should go to George, of course.
b。 ジョージ・ジョーンズはジョーンズとして彼のHostでログインします。 彼の秘書。(彼女のHost(SHost)の上のSecyが彼へのメールを送るとき、その秘書はログインします)。 メールに関する回答がジョージのものになるべきである、もちろん。
From: George Jones <Jones at Host>
Sender: Secy at SHost
From: ホスト>送付者のジョージ・ジョーンズ・<ジョーンズ: SHostのSecy
c. George Jones logs in as Group at Host. He sends mail himself;
replies should go to the Group mailbox.
c。 ジョージ・ジョーンズはGroupとしてHostでログインします。 彼は自分でメールを送ります。 回答はGroupメールボックスに行くべきです。
From: George Jones <Group at Host>
From: ホスト>のジョージジョーンズ<グループ
d. George Jones' secretary sends mail for George in his capacity
as a member of Group while logged in as Secy at Host. Replies
should go to Group.
d。 SecyとしてHostでログインされている間、ジョージ・ジョーンズの秘書はGroupのメンバーとして彼の立場でジョージへのメールを送ります。 回答はGroupに行くべきです。
From: George Jones<Group at Host>
Sender: Secy at Host
From: ホスト>送付者のジョージジョーンズ<グループ: ホストのSecy
Note that there need not be a space between "Jones" and the
"<", but adding a space enhances readability (as is the case
in other examples).
読み易さが「ジョーンズ」と"<"の間のスペースではなく、スペースが高める付加でなければならないことに注意してください(他の例でそうであるように)。
e. George Jones asks his secretary (Secy at Host) to send a
message for him in his capacity as Group. He wants his
secretary to handle all replies.
e。 ジョージ・ジョーンズは、彼のためにGroupとして彼の立場でメッセージを送るように彼の秘書(HostのSecy)に頼みます。 彼は、彼の秘書にすべての回答を扱って欲しいです。
II. Standard for the Format of Messages / 27
D. Examples
II。 メッセージ/27D.の例の形式において、標準です。
From: George Jones <Group at Host>
Sender: Secy at Host
Reply-to: Secy at Host
From: ホスト>送付者のジョージジョーンズ<グループ: ホストreply-toのSecy ホストのSecy
f. A non-ARPANET user friend of George's, Sarah, is visting.
George's secretary sends some mail to a friend of Sarah in
computer-land. Replies should go to George, whose mailbox is
Jones at Host.
f。 ジョージの非アルパネットユーザ友人(サラ)はvistingしています。 ジョージの秘書はコンピュータ陸で何らかのメールをサラの友人に送ります。 回答はジョージのものになるべきです。(ジョージのメールボックスはHostのジョーンズです)。
From: Sarah Friendly
Sender: Secy at Host
Reply-to: Jones at Host
From: サラFriendlyの送付者: ホストreply-toのSecy ホストのジョーンズ
g. George is a member of a committee. He wishes to have any
replies to his message go to all committee members.
g。 ジョージは委員会のメンバーです。 彼は、彼のメッセージに関するどんな回答もすべての委員のものになるのを持ちたがっています。
From: George Jones
Sender: Jones at Host
Reply-To: Big-committee: Jones at Host,
Smith at Other-Host,
Doe at Somewhere-Else;
From: ジョージジョーンズSender: ホストReply-Toのジョーンズ 大きい委員会: 他のどこかのホスト(他のホストのスミス)ドウで欲求してください。
Note that if George had not included himself in the
enumeration of Big-committee, he would not have gotten a
reply; the presence of the "Reply-to:" field SUPERSEDES the
sending of a reply to the person named in the "From:" field.
ジョージがBig-委員会の列挙で自分を入れなかったなら、彼が回答を得なかったことに注意してください。 「reply-to」の存在 人への回答の送付が「From:」で命名した分野SUPERSEDES さばきます。
h. (Example of INCORRECT USE)
h。 (不正確な使用に関する例)
George desires a reply to go to his secretary; therefore his
secretary leaves his mailbox address off the "From:" field,
leaving only his name, which is not, itself, a mailbox
address.
ジョージは、回答が彼の秘書のものになることを望んでいます。 したがって、彼の秘書は「From:」から彼のメールボックスアドレスを出ます。 分野、彼の名前だけを残して、どれがないか、それ自体、メールボックスアドレス。
From: George Jones
Sender: Secy at SHost
From: ジョージジョーンズSender: SHostのSecy
THIS IS NOT PERMITTED. Replies are NEVER implicitly sent to
the "Sender:"; George's secretary should have used the
"Reply-to:" field, or the mail creating program she was using
should have forced her to.
これは受入れられません。 それとなく回答を決して送らない、「送付者:」、。 ジョージの秘書は「reply-to」を使用するべきでした。 彼女が使用していたプログラムを作成すると彼女が強制されるべきであった分野、またはメール。
i. George's secretary sends out a message which was authored
jointly by all the members of the "Big-committee".
i。 ジョージの秘書は「大きい委員会」のすべてのメンバーによって共同で書かれたメッセージを出します。
From: Big-committee: Jones at Host,
Smith at Other-Host,
Doe at Somewhere-Else;
Sender: Secy at SHost
From: 大きい委員会: 他のどこかのホスト(他のホストのスミス)ドウで欲求してください。 送付者: SHostのSecy
II. Standard for the Format of Messages / 28
D. Examples
II。 メッセージ/28D.の例の形式において、標準です。
4. COMPLETE HEADERS
4. 完全なヘッダー
a. Minimum required:
a。 最小限が必要です:
Date: 26 August 1976 1429-EDT
From: Jones at Host
日付: 東部夏時間の1429年の1976年8月26日のFrom: ホストのジョーンズ
b. Using some of the additional fields:
b。 追加のいくつかを使用すると、以下はさばかれます。
Date 26 August 1976 1430-EDT
From: George Jones<Group at Host>
Sender: Secy at SHOST
To: Al Newman at Mad-Host,
Sam Irving at Other-Host
Message-id: some string at SHOST
東部夏時間の1430年の日付の1976年8月26日のFrom: ホスト>送付者のジョージジョーンズ<グループ: SHOST To:のSecy 気が狂ったホストのアル・ニューマン、他のホストメッセージイドにおけるサム・アービング: SHOSTの何らかのストリング
c. About as complex as you're going to get:
c。 以下を得るためにあなたが行く予定であるのとほぼ同じくらい複雑です。
Date: 27 Aug 1976 0932-PDT
From: Ken Davis <KDavis at Other-Host>
Sender: KSecy at Other-Host
Reply-to: Sam Irving at Other-Host
Subject: Re: The Syntax in the RFC
To: George Jones <Group at Host>,
Al Newman at Mad-Host
cc: Tom Softwood <Balsa at Another-Host>,
Sam Irving at Other-Host,
Standard Distribution:
:File:
</main/davis/people/standard at Other Host,
"<Jones>standard.dist.3" at Tops-20-Host>
In-Reply-to: <some string at SHOST>
Message-ID: 4231.629.XYzi-What at Other-Host
Comment: Sam is away on business. He asked me to handle
his mail for him today. He'll be able to
provide a more accurate explanation tomorrow
when he returns.
日付: 太平洋夏時間の0932年の1976年8月27日のFrom: 他のホストの>送付者のケンデイヴィス<KDavis: 他のホストreply-toのKSecy 他のホストSubject:のサム・アービング Re: RFC To:の構文 Host>のジョージジョーンズ<Group、Mad-ホストcc:のアル・ニューマン 別ホストの>のトム軟材<バルサ、他のホストの、そして、標準の分配におけるサム・アービング: :以下をファイルしてください。 他のホストの</main/davis/people/standard、「<ジョーンズ>standard.dist、以下に対して先端-20ホストの>の0.3インチ、」 或るものがSHOST>Message-IDで結ぶ<: 4231.629. XYzi、-ことはもう一方ホストで以下について論評します。 サムは商用で遠くにいます。 彼は、今日彼のために彼のメールを扱うように私に頼みました。 明日戻るとき、彼は、より正確な説明を提供できるでしょう。
III. References
III。 参照
III. REFERENCES
III。 参照
--- TELNET Protocol Specification. Network Information Center
No. 18639; Augmentation Research Center, Stanford Research
Institute: Menlo Park, August 1973.
--- telnetプロトコル仕様。 インフォメーション・センターNo.18639をネットワークでつないでください。 増大リサーチセンター、スタンフォード研究所: Menloは1973年8月に駐車します。
Bhushan, A.K. The File Transfer Protocol. ARPANET Request for
Comments, No. 354, Network Information Center No. 10596;
Augmentation Research Center, Stanford Research Institute:
Menlo Park, July 1972.
A. K. Bhushan、ファイル転送プロトコル。 コメントを求めるアルパネット要求、No.354はインフォメーション・センターNo.10596をネットワークでつなぎます。 増大リサーチセンター、スタンフォード研究所: Menloは1972年7月に駐車します。
Bhushan, A.K. Comments on the File Transfer Protocol. ARPANET
Request for Comments, No. 385, Network Information Center No.
11357; Augmentation Research Center, Stanford Research
Institute: Menlo Park, August 1972.
Bhushan、A.K.はファイル転送プロトコルを批評します。 コメントを求めるアルパネット要求、No.385はインフォメーション・センターNo.11357をネットワークでつなぎます。 増大リサーチセンター、スタンフォード研究所: Menloは1972年8月に駐車します。
Bhushan, A.K., Pogran, K.T., Tomlinson, R.S., and White, J.E.
Standardizing Network Mail Headers. ARPANET Request for
Comments, No. 561, Network Information Center No. 18516;
Augmentation Research Center, Stanford Research Institute:
Menlo Park, September 1973.
Bhushan、A.K.、Pogran、K.T.、トムリンスン、R.S.、およびホワイト、J.E.標準化はメールヘッダをネットワークでつなぎます。 コメントを求めるアルパネット要求、No.561はインフォメーション・センターNo.18516をネットワークでつなぎます。 増大リサーチセンター、スタンフォード研究所: Menloは1973年9月に駐車します。
Feinler, E.J. and Postel, J.B. ARPANET Protocol Handbook.
Network Information Center No. 7104; Augmentation Research
Center, Stanford Research Institute: Menlo Park, April 1976.
(NTIS AD A003890).
FeinlerとE.J.とポステル、J.B.アルパネットはハンドブックについて議定書の中で述べます。 インフォメーション・センターNo.7104をネットワークでつないでください。 増大リサーチセンター、スタンフォード研究所: Menloは1976年4月に駐車します。 (NTIS AD A003890。)
McKenzie, A. File Transfer Protocol. ARPANET Request for
Comments, No. 454, Network Information Center No. 14333;
Augmentation Research Center, Stanford Research Institute:
Menlo Park, February 1973.
マッケンジー、A.ファイル転送プロトコル。 コメントを求めるアルパネット要求、No.454はインフォメーション・センターNo.14333をネットワークでつなぎます。 増大リサーチセンター、スタンフォード研究所: Menloは1973年2月に駐車します。
Myer, T.H. and Henderson, D.A. Message Transmission Protocol.
ARPANET Request for Comments, No. 680, Network Information
Center No. 32116; Augmentation Research Center, Stanford
Research Institute: Menlo Park, 1975.
マイヤーとT.H.とヘンダーソン、D.A.メッセージ送信は議定書を作ります。 コメントを求めるアルパネット要求、No.680はインフォメーション・センターNo.32116をネットワークでつなぎます。 増大リサーチセンター、スタンフォード研究所: メンローパーク、1975。
Neigus, N. File Transfer Protocol. ARPANET Request for
Comments, No. 542, Network Information Center No. 17759;
Augmentation Research Center, Stanford Research Institute:
Menlo Park, July 1973.
Neigus、N.ファイル転送プロトコル。 コメントを求めるアルパネット要求、No.542はインフォメーション・センターNo.17759をネットワークでつなぎます。 増大リサーチセンター、スタンフォード研究所: Menloは1973年7月に駐車します。
Postel, J.B. Revised FTP Reply Codes. ARPANET Request for
Comments, No. 640, Network Information Center No. 30843;
Augmentation Research Center, Stanford Research Institute:
Menlo Park, June 1974.
ポステル、J.B.はFTP回答コードを改訂しました。 コメントを求めるアルパネット要求、No.640はインフォメーション・センターNo.30843をネットワークでつなぎます。 増大リサーチセンター、スタンフォード研究所: Menloは1974年6月に駐車します。
Appendix / 30
Alphabetical Listing of Syntax Rules
シンタックス・ルールに関する付録/30アルファベット順リスト
APPENDIX
付録
A. ALPHABETICAL LISTING OF SYNTAX RULES
シンタックス・ルールのA.アルファベット順のリスト
<2-digit-year> ::= <two decimal digits>
<4-digit-year> ::= <four decimal digits>
<24-hour-time> ::= <hour> <minute>
<2ケタ年の>:、:= <の2 10進数字><4ケタ年間の>:、:= <fourの10進数字の><24時間-回の>:、:= <時間の>の<の微小な>。
<addressee-field> ::= "To" ":" <address-list>
| "cc" ":" <address-list>
| "bcc" ":" <address-list>
| "Fcc" ":" <path-list>
<address-item> ::= <mach-addr-item>
| <group-name> ":" <address-list> ";"
| <any-name>
| <path>
<address-list> ::= <null> | <address-item>
| <address-item> "," <address-list>
<受け取り人分野>:、:= ""To"":、」 <住所録>。| 「「cc」」:、」 <住所録>。| 「"bcc"」:、」 <住所録>。| 「"Fcc"」:、」 <経路リスト><アドレス項目>:、:= <のmach-addr-品目>。| 「<グループ名>」:、」 「<住所録>」;、」 | <、いくらか名義の>。| <経路><住所録>:、:= <のヌル>。| <アドレス項目>。| 「<アドレス項目>」、」 <住所録>。
<any-from-field> ::= "From" ":" <address-list>
<、いくらか、-、分野>から:、:= ""From"":、」 <住所録>。
<any-name> ::= <quoted-string>
<、いくらか名義の>:、:= <引用文字列>。
<at-indicator> ::= "at" | "@"
インディケータ>の<:、:= "at"| "@"
<atom> ::= <a sequence of one or more TELNET ASCII
alpha-numeric or graphics characters,
excluding all control characters
(those characters with a decimal value
less than 33 or equal to 127) and
<delimeters> >
<原子>:、:= 1つ以上のTELNET ASCIIアルファベット数字式の<a系列かすべての制御文字を除いたグラフィックスキャラクタ(小数があるそれらのキャラクタは33未満か同輩を127に評価する)と<delimeters>>。
<comment> ::= "(" <TELNET ASCII characters, except
<crlf> > ")"
<コメント>:、:= 「(「<crlf>>以外の<TELNET ASCII文字」)」
<cr> ::= <TELNET ASCII carriage return (decimal 13)>
<crlf> ::= <TELNET ASCII carriage return/line feed
(decimal 13, followed by decimal 10)>
<cr>:、:= <TELNET ASCII復帰(10進13)><crlf>:、:= <TELNET ASCII復帰/改行(10進13 10進10があとに続いていて、>。
<date> ::= <string-date> | <slash-date>
<date-field> ::= "Date" ":" <date-time>
<date-time> ::= <day> <date> <time>
<day> ::= <null> | <day-of-week> ","
<day-of-month> ::= <one or two decimal digits>
<day-of-week> ::= "Monday" | "Mon"
| "Tuesday" | "Tue"
| "Wednesday" | "Wed"
| "Thursday" | "Thu"
<日付>:、:= <ストリング日付>。| <スラッシュ日付><年月日欄>:、:= 「「デートしてください」」:、」 <日付-時間><日付-時間>:、:= <日><日付の><時間><日>:、:= <のヌル>。| 「<日、-、週、>、」、」 <日、-、-、月の>:、:= 10進数字><<1日か2日、-、-、週の>:、:= 「月曜日」| 「月曜日」| 「火曜日」| 「火曜日」| 「水曜日」| 「水曜日」| 「木曜日」| 「木曜日」
Appendix / 31
Alphabetical Listing of Syntax Rules
シンタックス・ルールに関する付録/31アルファベット順リスト
| "Friday" | "Fri"
| "Saturday" | "Sat"
| "Sunday" | "Sun"
| 「金曜日」| 「金曜日」| 「土曜日」| 「座っています」| 「日曜日」| 「Sun」
<delimeter> ::= <specials> | <comment>
| <linear-white-space> | <crlf>
<delimeter>:、:= <特別番組>。| <コメント>。| <直線的な余白>。| <crlf>。
<field> ::= <field-name> ":" <field-body>
<field-body> ::= <field-body-contents>
| <field-body-contents> <crlf>
<linear-white-space-CHAR> <field-body>
<field-body-contents> ::= <the TELNET ASCII characters making up
the field body, as defined in the
following sections and consisting of
combinations of <atom>, <quoted-
string>, <text-line>, and <specials>
tokens>
<分野>:、:= 「<フィールド名>」:、」 <分野本体><分野本体>:、:= <分野本体コンテンツ>。| <分野本体コンテンツ>の<のcrlfの>の<の直線的に白いスペース炭の><分野本体><分野本体コンテンツ>:、:= <が以下のセクションで定義されて、<原子>の組み合わせから成るとして引用した分野本体を作るTELNET ASCII文字の<ストリング>、<テキスト線>、および<特別番組>象徴>。
<field-name> ::= <atom> | <atom> <field-name>
<フィールド名>:、:= <原子>。| <原子><フィールド名>。
<group-name> ::= <phrase>
<グループ名>:、:= <句の>。
<headers> ::= <required-headers>
| <required-headers> <optional-headers>
<ヘッダー>:、:= <の必要なヘッダーの>。| <の必要なヘッダーの><任意のヘッダーの>。
<host-indicator> ::= <at-indicator> <host-name>
<host-name> ::= <atom> | <decimal host address>
<host-phrase> ::= <phrase> <host-indicator>
<ホストインディケータ>:、:= インディケータ><ホスト名><ホスト名>の<:、:= <原子>。| <の10進ホスト・アドレス><ホスト句の>:、:= <句の><ホストインディケータ>。
<hour> ::= <two decimal digits>
<時間>:、:= <two10進数字>。
<lf> ::= <TELNET ASCII line feed (decimal 10)>
<linear-white-space>::= <linear-white-space-char>
| <linear-white-space-char>
<linear-white-space>
<linear-white-space-char>::= <space> | <horizontal-tab>
<lf>:、:= <TELNET ASCII改行(10進10)><直線的な余白>:、:= <の直線的に白いスペース炭の>。| <の直線的に白いスペース炭の>の<の直線的な余白の>の<の直線的に白いスペース炭の>:、:= <スペース>。| <水平タブ>。
<mach-addr-item> ::= <mailbox> | <phrase> "<" <mailbox-list> ">"
<mach-addr-list> ::= <mach-addr-item>
| <mach-addr-item> "," <address-list>
<のmach-addr-品目>:、:= <メールボックス>。| <句の>"<"<メールボックスリスト>">"<mach-addr-リスト>:、:= <のmach-addr-品目>。| 「<のmach-addr-品目>」、」 <住所録>。
<mach-from-field> ::= "From" ":" <mach-addr-item>
<mach-from-list> ::= "From" ":" <mach-addr-list>
<mach、-、分野>から:、:= ""From"":、」 <のmach-addr-品目><mach、-、リスト>から:、:= ""From"":、」 <mach-addr-リスト>。
<mach-host-phrase>::= "<" <host-phrase> ">"
<mach-ホスト句の>:、:= "<"<ホスト句の>">"
<mailbox> ::= <host-phrase>
<mailbox-list> ::= <mailbox> | <mailbox> "," <mailbox-list>
<メールボックス>:、:= <ホスト句の><メールボックスリスト>:、:= <メールボックス>。| 「<メールボックス>」、」 <メールボックスリスト>。
<message> ::= <headers>
| <headers> <crlf> <message-text>
<メッセージ>:、:= <ヘッダー>。| <ヘッダー><crlf><メッセージ・テキスト>。
Appendix / 32
Alphabetical Listing of Syntax Rules
シンタックス・ルールに関する付録/32アルファベット順リスト
<message-text> ::= <a sequence of zero of more TELNET ASCII
characters>
<メッセージ・テキスト>:、:= <は、より多くのTELNET ASCII文字>のゼロの系列です。
<minute> ::= <two decimal digits>
<の微小な>:、:= <two10進数字>。
<numeric-month> ::= <one or two decimal digits>
<の数値月の>:、:= <1かtwo10進数字>。
<optional-headers>::= <optional-header-field>
| <optional-headers> <optional-header-field>
<optional-header-field> ::= <addressee-field> | <extension-field>
<の任意のヘッダーの>:、:= <任意のヘッダーフィールド>。| 任意のヘッダーの<の<任意のヘッダーフィールド><任意のヘッダーフィールド>>:、:= <受け取り人分野>。| <拡張子分野>。
<originator> ::= <mach-from-field>
| <mach-from-list> <sender-field>
| <mach-from-field> <reply-to-field>
| <any-from-field> <sender-field>
<reply-to-field>
<創始者>:、:= <mach、-、分野>。| <、-machに、リスト>から、<は>を送付者と同じくらいさばきます。| <mach、-、分野><回答から分野への>。| <、-いくらか、分野><から><回答から分野への>を送付者と同じくらいさばいてください。
<path> ::= ":" "File" ":" <path-name>
<path-item> ::= <host-phrase>
<path-list> ::= <path-item> | <path-item> "," <path-list>
<path-name> ::= <path-item> | "<" <path-list> ">"
<経路>:、:= ":" 「「ファイルしてください」」:、」 <パス名><経路項目>:、:= <ホスト句の><経路リスト>:、:= <経路項目>。| 「<経路品目>」、」 <経路リスト><パス名>:、:= <経路項目>。| "<"<経路リスト>">"
<phrase> ::= <word> | <word> <phrase>
<phrase-list> ::= <null> | <phrase>
| <phrase> "," <phrase-list>
<句の>:、:= <単語>。| <単語><句の><句リスト>:、:= <のヌル>。| <句の>。| 「<句の>」、」 <句リスト>。
<reference-item> ::= <phrase> | <mach-host-phrase>
<reference-list> ::= <null> | <reference-item>
| <reference-item> "," <reference-list>
<参照項目>:、:= <句の>。| <mach-ホスト句の><参考文献一覧表>:、:= <のヌル>。| <参照項目>。| 「<参照項目>」、」 <参考文献一覧表>。
<quoted-string> ::= <double quote mark ("), decimal 34>
<a sequence of one or more TELNET
ASCII characters, where two adjacent
quotes are treated as a single quote
and part of the string> <">
<引用文字列>:、:= <の二重引用符、(「)、1人以上のTELNET ASCII文字の10進34><a系列。(そこでは、2つの隣接している引用文がストリング><">"のただ一つの引用文と一部として扱われます)。
<reply-to-field> ::= "Reply-To" ":" <mach-addr-list>
<回答から分野への>:、:= 以下に「「答え」」、」 <mach-addr-リスト>。
<required-headers> ::= <date-field> <originator>
<の必要なヘッダーの>:、:= <年月日欄><創始者>。
<sender-field> ::= "Sender" ":" <host-phrase>
<送付者分野>:、:= 「「送付者」」:、」 <ホスト句の>。
<slash-date> ::= <numeric-month> "/" <date-of-month>
"/" <2-digit-year>
<space> ::= <TELNET ASCII space (decimal 32)>
<スラッシュ日付>:、:= 」 「<の数値月の>」/<がデートされる、-、-、」 /」 <2ケタ年><が>を区切る月の>:、:= <TELNET ASCIIスペース(10進32)>。
<specials> ::= "(" | ")" | "<" | ">"
| "@" | "," | ";" | ":" | <">
<特別番組>:、:= "(" | ")" | "<"| ">"| "@" | "," | ";" | ":" | <">"
<string-date> ::= <day-of-month> <string-month>
<string-month> ::= "January" | "Jan" | "February" | "Feb"
<ストリング日付>:、:= <日、-、-、月の><ストリング月の><ストリング月の>:、:= 「1月」| 「1月」| 「2月」| 「2月」
Appendix / 33
Alphabetical Listing of Syntax Rules
シンタックス・ルールに関する付録/33アルファベット順リスト
| "March" | "Mar" | "April" | "Apr"
| "May" | "June" | "Jun"
| "July" | "Jul" | "August" | "Aug"
| "September"| "Sep" | "October" | "Oct"
| "November" | "Nov" | "December" | "Dec"
| 「3月」| 「3月」| 「4月」| 「4月」| 「5月」| 「6月」| 「6月」| 「7月」| 「7月」| 「8月」| 「8月」| 「9月」| 「9月」| 「10月」| 「10月」| 「11月」| 「11月」| 「12月」| 「12月」
<tab> ::= <TELNET ASCII tab (decimal 9)>
<タブ>:、:= <TELNET ASCIIタブ(10進9)>。
<text-line> ::= <a sequence of one or more TELNET ASCII
characters excluding <cr> and <lf> >
<テキスト線>:、:= <は<cr>と<lf>>を除いた1人以上のTELNET ASCII文字の系列です。
<time> ::= <24-hour-time> "-" <time-zone>
<time-zone> ::= "GMT" | "Z" | "GDT" | "AST" | "ADT
| "EST" | "EDT" | "CST" | "CDT"
| "MST" | "MDT" | "PST" | "PDT"
| "YST" | "YDT" | "HST" | "HDT"
<時間>:、:= <24時間-時間>「-」<時間帯の><の時間帯の>:、:= 「グリニッジ標準時」| 「Z」| "GDT"| "AST"| "ADT"| 「米国東部標準時」です。| 「東部夏時間」です。| "CST"| "CDT"| "MST"| "MDT"| 「太平洋標準時」です。| 「太平洋夏時間」です。| "YST"| "YDT"| "HST"| "HDT"
<user-defined-field> ::= <A <field> which has a <field-name> not
defined in this specification>
<のユーザによって定義された分野の>:、:= <は>がこの仕様>で定義しなかった<フィールド名を持っている<分野>です。
<word> ::= <atom> | <quoted-string>
<単語>:、:= <原子>。| <引用文字列>。
一覧
スポンサーリンク
