RFC680 日本語訳
0680 Message Transmission Protocol. T.H. Myer, D.A. Henderson. April 1975. (Format: TXT=11539 bytes) (Updates RFC0561) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Myer
Request for Comment: 680 D. Henderson
NIC: 32116 BBN-TENEX
April 30, 1975
コメントを求めるワーキンググループT.マイヤー要求をネットワークでつないでください: 680 D.ヘンダーソンNIC: 32116 1975年4月30日のBBN-TENEX
Message Transmission Protocol
メッセージトランスミッションプロトコル
Theodore H. Myer
セオドアH.マイヤー
D. Austin Henderson
D.オースチンヘンダーソン
BBN-TENEX
BBN-TENEX
This document defines a number of message fields beyond those discussed in RFC 561. The overall message format is compatible with RFC 561; it makes extensive use of the miscellaneous fileds defined within RFC 561. The purpose of this document is to establish ARPANET standards with regard to the syntax and semantics for these additional fields. It is fully expected that all fields discussed herein will not be automatically processed by all Message Servers; however, the standard is necessary so that sites which wish to make use of these fields have a standard to work with.
このドキュメントはRFC561で議論したものを超えた多くのメッセージ分野を定義します。 総合的なメッセージ・フォーマットはRFC561と互換性があります。 それで、RFC561の中で種々雑多なfiledsの大規模な使用を定義します。 このドキュメントの目的は構文と意味論に関してこれらの追加分野にアルパネット規格を確立することです。 ここに議論したすべての分野がすべてのMessage Serversによって自動的に処理されないと完全に予想されます。 しかしながら、規格が必要であるので、これらの分野を利用したがっているサイトが働いている規格を持っています。
This document attempts to tread the narrow line between features for human processing and features for machine processing. The general feeling is that the fields listed are useful to people even if automatic processing is not supplied. In most cases, machine- readable notations have been enclosed in angle brackets (<>) to allow easy non-ambiguous ways for automatic processes to know whether and where to look in any field. The entire specifications has been made excessively general to allow for experimentation. Future documents based on experience will try to be more specific. This is simply the next step following <RFC 561>.
このドキュメントは、人間の処理のための特徴とマシン処理のための特徴の間の細長い線を踏み均すのを試みます。 一般的な感じは自動処理が供給されないでも記載された分野が人々の役に立つということです。 多くの場合、中を見て何か野原のどこに中を見るかを知るために自動過程のための簡単な非あいまいな方法を許容するために角ブラケット(<>)にマシンの読み込み可能な記法を同封してあります。 全体の仕様を実験を考慮するために過度に一般的にしました。 経験に基づく将来のドキュメントは、より特有になろうとするでしょう。 これは単に<RFC561>に続く次のステップです。
This document is contained in two sections. Section I contains the relevant parts of RFC 561 which define the basic message syntax. Section II lists the new (and existing) header fields together with their proposed uses.
このドキュメントは2つのセクションで含まれています。 セクションIは基本的なメッセージ構文を定義するRFC561の関連部分を含みます。 セクションIIは彼らの提案された用途と共に新しくて(既存)のヘッダーフィールドを記載します。
[Page 1]
RFC 680
[1ページ] RFC680
SECTION I: BASIC MESSAGE SYNTAX
セクションI: 基本的なメッセージ構文
<message> ::= <header><crlf><body>
<header> ::= <required header><optional header>
<required header> ::= <date item><sender item>
<date item> ::= DATE:<sp><date><sp>AT<sp>
<time>-<zone><crlf>
<date> ::= <vdate> ! <tdate>
<vdate> ::= <dayofmonth><SP><vmonth><SP><vyear>
<tdate> ::= <tmonth>/<dayofmonth>/<tyear>
<dayofmonth> ::= one or two decimal digits
<vmonth> ::= JAN ! FEB ! MAR ! APR ! MAY ! JUN !
JUL ! AUG ! SEP ! OCT ! NOV ! DEC
<tmonth> ::= one or two decimal digits
<vyear> ::= four decimal digits
<tyear> ::= two decimal digits
<zone> ::= EST ! EDT ! CST ! CDT ! MST ! MDT !
PST ! PDT ! GMT ! GDT
<time> ::= four decimal digits
<sender item := SENDER: <sp><user><sp>AT<sp><host>
<crlf>
<optional header> ::= <subjects><optional items>
<subjects> ::= !<subject item> !
<subject item><subjects>
<subject item> ::= SUBJECT:<sp><line><crlf>
<optional items> ::= <optional item> ! <optional item>
<optional items>
<optional item> ::= <messid> ! <addressee item> !
<other item>
<addressee item> ::= <addressee keyword>:<sp><addressee
list><crlf>
<addressee keywork> ::= TO:! CC:! BCC:!
<messid> ::= Message-ID:<sp>[<Net
Address>}]<line>
<crlf>
<other item> ::= <other keyword>:<sp><line><crlf>
<other keyword> ::= FROM ! IN-REPLY-TO! REFERENCES!
KEYWORD ! PRECEDENCE !
MESSAGE-CLASS!
SPECIAL-HANDLING! AUTHENTICATION!
ACCESSION-KEY
<address list> ::= <addressee> ! <addressee><addressee
list>
<addressee> ::= <mailbox> ! <mailbox group>
<mailbox> ::= <user><host spec><attention spec>
<host spec> ::= !@<host>
<attention spec> ::= (ATTN:<sp><user list>)
<メッセージ>:、:= <ヘッダー><crlf><ボディー><ヘッダー>:、:= <の必要なヘッダー><任意のヘッダー><はヘッダー>を必要としました:、:= <データ項目><送付者項目><データ項目>:、:= 日付:<は>-<が><crlf><日付>を区分する><日付><sp><sp><時間に以下をspします:= <vdate>!<tdate><vdate>:、:= <dayofmonth><SP><vmonth><SP><vyear><tdate>:、:= <tmonth>/<dayofmonth>/<tyear><dayofmonth>:、:= 1か2の10進数字<vmonthな>:、:= 1月!の2月!の3月!の4月!の5月!の6月!の7月!の8月!の9月!の10月!の11月!の12月の<tmonth>:、:= 1か2の10進数字<vyearな>:、:= 4の10進数字<tyearな>:、:= 2 10進数字<は>を区分します:、:= 米国東部標準時!、東部夏時間、CST!CDT!MST!MDT!太平洋標準時!、太平洋夏時間、グリニッジ標準時のGDT<時間>:、:= 4 10進数字<送付者の品目:=SENDER: <sp><ユーザ><sp>AT<sp><ホスト>の<のcrlfの>の<の任意のヘッダー>:、:= <は>の任意の項目><対象<>をかけます:、:= <の対象の項目>!<対象の品目><は>の<の対象の品目>をかけます:、:= SUBJECT:<sp><は>のcrlfの>の<の任意の項目<>を裏打ちします:、:= 任意の<の>!<任意の項目>の<の任意の項目><任意の項目品目>:、:= <messid>!<受け取り人の品目>!<他の項目><受け取り人の品目>:、:= <受け取り人キーワード>: <sp><受け取り人リスト><crlf><受け取り人keywork>:、:= TO:!CC:BCC:!!<messid>:、:= Message ID: <sp>、[<ネットAddress>、]、<線><crlf><他の項目>:、:= <他のキーワード>: <sp><線><crlf><他のキーワード>:、:= in reply to 参照! キーワード!先行!メッセージクラス! 特別な取り扱い! 認証! ACCESSION-KEY<住所録>:、:= <受け取り人>!<受け取り人><受け取り人リスト><受け取り人>:、:= <メールボックス>!<メールボックスグループ><メールボックス>:、:= <ユーザ><ホスト仕様><注意仕様><ホスト仕様>:、:= @<ホスト><注意仕様>:、:= (ATTN: <sp><ユーザリスト>)
[Page 2]
RFC 680
[2ページ] RFC680
<user list> ::= <user> ! <user><user list>
<mailbox group> ::= <group name>:(<group numbers>)
<group numbers> ::= ! (<mailbox list>)
<mailbox list> ::= <mailbox> ! <mailbox>,<mailboxlist>
<body> ::= <line><CRLF> ! <line><CRLF><body>
<user> ::= <word>
<host> ::= a standard host name
<group name> ::= ! <word>
<line> ::= a string containing any of the 128
ASCII
characters except CR and LF
<word> ::= a string containing any of the 128
ASCII
characters except CR, LF, and SP
<CRLF> ::= CR LF
<SP> ::= space
<ユーザリスト>:、:= <ユーザ>!<ユーザ><ユーザリスト><メールボックスグループ>:、:= <グループ名>: (<グループ番号>) <グループ番号>:、:= ! (<メールボックスリスト>) <メールボックスリスト>:、:= <メールボックス>!<メールボックス>、<mailboxlist><ボディー>:、:= <線><CRLF>!<線><CRLF><ボディー><ユーザ>:、:= <単語><ホスト>:、:= 標準のホスト名<グループ名>:、:= ! <単語><線>:、:= CRを除いて、128人のASCII文字のいずれも含むストリングとLF<は>を言い表します:、:= CR、LF、およびSP<CRLF>を除いて、128人のASCII文字のいずれも含むストリング:、:= CR LF<SP>:、:= スペース
Notes:
注意:
1. A message may have at most one MESSAGE-ID item.
1. メッセージは1つのMESSAGE-ID項目に最も攻撃するかもしれません。
2. All items with the same keyword must be grasped together.
2. 同じキーワードがあるすべての項目を一緒に握らなければなりません。
Please note the following:
以下に注意してください:
(1) The case (upper or lower) of keywords -- specifically, 'FROM',
'DATE', 'SUBJECT', 'AT', <host>, <zone>, <vmonth> and <keyword> --
is insignificant. Although 'FROM', for example, appears in
upper-case in the formal syntax above, in the header of an actual
message it may appear as 'FROM', 'from', or 'From', etc.
(1) キーワードにおける(上側か下側)のケース(明確に'FROM'、'DATE'、'SUBJECT'、'AT'、<ホスト>、<ゾーン>、<vmonth>、および<キーワード>)は意味をなしません。 'FROMが'例えば、それが現れるかもしれない実際のメッセージのヘッダーに大文字の中に正式な構文で上に現れる'というFROM'、'from'、または'From'ですが、などです。
(2) No attempt has been made to legislate the format of <user>
except to exclude spaces from it.
(2) それに空間を入れないようにする以外に、<ユーザ>の形式を制定するのを試みを全くしていません。
(3) The time has no internal punctuation.
(3) 時間には、どんな内部の句読もありません。
[Page 3]
RFC 680
[3ページ] RFC680
SECTION II: MESSAGE HEADER FIELDS
セクションII: メッセージヘッダーフィールド
A. ORIGINATOR SPECIFICATION FIELDS
A。 創始者仕様分野
FROM
from
This field contains the identity of the person who wished this message to be sent. This is expected to be the originator field which is specified by the user in the case that the message is being entered by one person for another. The message-creation process should default this field to be the user entering the message. [The usage for FROM and SENDER differs from that of RFC 561.]
この分野はこの送られるべきメッセージを願っていた人のアイデンティティを含んでいます。 これはメッセージが別のもののために1人の人によって入力されていて、ユーザによって指定される創始者分野であると予想されます。 これがメッセージを入力するユーザになるようにさばく過程がそうするべきであるメッセージ創造デフォルト。 [FROMとSENDERのための用法はRFC561のものと異なっています。]
SENDER
送付者
This field contains the identity of the person who sends the message. This field is expected to be set by the message-creation process automatically. It is possible that some sites will not include this field in external communications.
この分野はメッセージを送る人のアイデンティティを含んでいます。 この分野によってメッセージ創造工程で自動的に設定されると予想されます。 いくつかのサイトが外部コミュニケーションにこの分野を含んでいないのは、可能です。
AUTHENTICATION
認証
This field contains a description of which originator fields have been authenticated, and by which operating systems. This field should be created by message transmission and/or reception processes (FTP/Operating System level).
この分野は創始者分野が認証されて、オペレーティングシステムこの分野がメッセージ送信で作成されるべきである記述、そして/または、レセプションの過程(FTP/作動Systemレベル)を含んでいます。
It is expected that current system will be able to authenticate only the SENDER field; however, later systems might have mechanisms to verify that the FROM actually authorized the SENDER to act on his/her behalf. It is expected that, when the FROM is authenticated, the SENDER will no longer be necessary for external distribution.
現在のシステムがSENDER分野しか認証できないと予想されます。 しかしながら、後のシステムには、確かめるFROMが、SENDERがその人の代理に行動するのを実際に認可したメカニズムがあるかもしれません。 FROMが認証されるとき、SENDERがもう社外分配に必要にならないと予想されます。
B. REFERENCE SPECIFICATION FIELDS
B。 関連仕様書分野
MESSAGE-ID
MESSAGE ID
This field contains a unique identifier to refer to this message. The format for a message identifier is:
この分野はこのメッセージを示すユニークな識別子を含んでいます。 メッセージ識別子のための形式は以下の通りです。
[Net Address]Text String CRLF
Examples:
[ISIB]7-DEC-74.14:23:45
[ARC]QLOURNAL 39274a3
[ネットのアドレス] テキスト文字列CRLFの例: [ISIB]7 12月の74.14: 23:45[アーク]QLOURNAL 39274a3
[Page 4]
RFC 680
[4ページ] RFC680
The uniqueness of the message identifier is guaranteed by each net- address message processor making the text which follows unique for that net-address. This, specifically says net-address and not site name. This would allow BBN (for instance) to allocate unique identifiers over all four machines, which may be addressed as BBN within the message system, thus producing a more integrated service for their users.
メッセージ識別子のユニークさはそのネットのアドレスにユニークな状態で従うテキストを作るそれぞれのネットのアドレスメッセージプロセッサによって保証されます。 これ、明確に、サイト名ではなく、ネットのアドレスを言います。 これで、(例えば、)BBNはすべての4台のマシンの上にユニークな識別子を割り当てることができるでしょう、その結果、彼らのユーザのために、より統合しているサービスを起こします。マシンはBBNとしてメッセージシステムの中に記述されるかもしれません。
The text following the net-address is not defined here, as the problems associated with this specification are too great at this time. However, the net-address should allow automatic processes to determine if they can deal intelligently with the following text. Several types of automatic processing by the local message reader are thus possible: 1) if the site uses a filing mechanism known to the reader, the reader can retrieve the message 2) if the site supports remote message access (protocol not currently defined), the message id can be passed to the remote site and the message has been filed in the Datacomputer (using the entire message id [including net-address] as the handle), the reader can retrieve it from the Datacomputer.
ネットのアドレスに従うテキストはここで定義されません、この仕様に関連している問題がこのとき重大過ぎるときに。 しかしながら、ネットのアドレスで、自動過程は、それらが知的に以下のテキストに対処できるかどうか決定できるべきです。 その結果、地元のメッセージ読者による自動処理のいくつかのタイプが可能です: 1) サイトが読者にとって知られているファイリングメカニズムを使用して、サイトがリモートメッセージアクセス(現在定義されていないプロトコル)を支持するなら読者がメッセージ2)を検索できて、メッセージイドがリモートサイトに向かうことができて、Datacomputer(ハンドルとして全体のメッセージイド[ネットのアドレスを含んでいる]を使用する)にメッセージをファイルしてあるなら、読者はDatacomputerからそれを検索できます。
IN-REPLY-TO
in reply to
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 (<>).
この分野の内容はこのメッセージが答える前の通信を特定します。 メッセージ識別子がこの分野で使用されるなら、それらは角ブラケット(<>)に同封されるべきです。
REFERENCES
参照
The contents of this field identify other correspondence which this message references. If message identifiers are used, they should be enclosed in angle brackets (<>).
この分野の内容はこのメッセージが参照をつける他の通信を特定します。 メッセージ識別子が使用されているなら、それらは角ブラケット(<>)に同封されるべきです。
KEYWORDS
キーワード
This field contains keywords or phrases from the message, separated by commas.
この分野はコンマによって切り離されたメッセージからのキーワードか句を含んでいます。
[Page 5]
RFC 680
[5ページ] RFC680
C. RECEIVER SPECIFICATION FIELDS
C。 受信機仕様分野
TO
to
This field contains the identity of the primary receivers of the message.
この分野はメッセージのプライマリ・レシーバのアイデンティティを含んでいます。
CC
CC
This field contains the identity of the secondary receivers of the message.
この分野はメッセージのセカンダリ・レシーバのアイデンティティを含んでいます。
BCC
BCC
This field contains the identity of the tertiary receivers of the message. This field should not be made available to the primary and secondary receivers, but it may be recorded to provide information for access control.
この分野はメッセージの第三の受信機のアイデンティティを含んでいます。 第一の、そして、二次の受信機はこの分野を入手するはずがありませんが、アクセス管理のための情報を提供するのは記録されているかもしれません。
D. MESSAGE-TYPE SPECIFICATION FIELDS
D。 メッセージタイプ仕様分野
PRECEDENCE
先行
This field describes the importance and urgency of the message. Machine-readable notations will be enclosed in angle brackets (<>). <PRIORITY> means that the message should be delivered as soons as possible. <ROUTINE> means that Priority processing is not necessary. Plain text may also be included in this field.
この分野はメッセージの重要性と緊急について説明します。 機械可読な記法は角ブラケット(<>)に同封されるでしょう。 <PRIORITY>は、メッセージが可能であるとしてのsoonsとして送られるべきであることを意味します。 <ROUTINE>は、Priority処理が必要でないことを意味します。 また、プレーンテキストはこの分野に含まれるかもしれません。
MESSAGE-CLASS
メッセージクラス
This field describes the "legal" status of the message. Examples: Official, Unofficial, Record, Off the Record, Junk Mail. No automatic processing of this field is immediately expected. Certain message creation processes might, for example, always insert:
この分野はメッセージの「法的な」状態について説明します。 例: 公式であって、非公式であることで、記録にダイレクトメールを記録してください。 この分野のどんな自動処理もすぐに、予想されません。 例えば、あるメッセージ創造の過程はいつも以下を挿入するかもしれません。
MESSAGE CLASS: Unofficial ARPANET Message
メッセージのクラス: 非公式のアルパネットメッセージ
SPECIAL-HANDLING
特別な取り扱い
This field contains any special instructions with regard to the handling of the message at the receiver's end. Machine-readable notations will be enclosed in angle brackets (<>). <PRIVATE> means that the message reception process should not aid the user in circulating copies to others. Plain text may also be included in this field.
この分野は受信機の終わりにメッセージの取り扱いに関してどんな特殊命令も含みます。 機械可読な記法は角ブラケット(<>)に同封されるでしょう。 <兵士の>は、メッセージレセプションの過程が他のものにコピーを循環させる際にユーザを支援するべきでないことを意味します。 また、プレーンテキストはこの分野に含まれるかもしれません。
[Page 6]
[6ページ]
一覧
スポンサーリンク
