RFC886 日本語訳
0886 Proposed standard for message header munging. M.T. Rose. December 1983. (Format: TXT=30566 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Request For Comments: 886
コメントのために以下を要求してください。 886
Proposed Standard for Message Header Munging
メッセージヘッダーの変更を加えることの提案された標準
Thu Dec 15 03:37:52 1983
12月15日木曜日の03:37:52 1983
Marshall T. Rose
マーシャルT.は上昇しました。
Department of Information and Computer Science University of California, Irvine Irvine, CA 92717
情報の部とカリフォルニア大学アーバイン校アーバイン、コンピュータサイエンスカリフォルニア 92717
MRose.UCI@Rand-Relay
MRose.UCI@Rand-Relay
This memo proposes a standard for the ARPA Internet community. If
this proposal is adopted, hosts on the ARPA Internet that do message
translation would be expected to adopt and implement this standard.
このメモはARPAインターネットコミュニティの規格を提案します。 この提案が採用されるなら、ARPAインターネットのメッセージ翻訳をするホストは、この規格を採用して、実行すると予想されるでしょう。
Request For Comments: 886 M. Rose Proposed Standard for Message Header Munging UCI
コメントのために以下を要求してください。 886 UCIに変更を加えるメッセージヘッダーのM.バラ提案された標準
Introduction
序論
This memo describes the rules that are to be used when mail is
transformed from one standard format to another. The scope of this
memo is limited to text messages (computer network mail, or
electronic mail) that traverse the ARPA Internet. This memo is not
presented as a replacement or amendment for the "Standard for the
Format of ARPA Internet Text Messages", RFC822. Rather, this memo
focuses on a particular aspect of mail, and provides a conceptual
and practical basis for implementors of transport agents and user
agents which support message munging.
このメモはメールが1つの標準書式から別のものに変えられるとき使用されていることになっている規則について説明します。 このメモの範囲はARPAインターネットを横断するテキスト・メッセージ(コンピュータネットワークメール、または電子メール)に制限されます。 このメモは「アルパインターネットテキスト・メッセージの形式の規格」のための交換か修正として提示されません、RFC822。 むしろ、このメモは、メールの特定の局面に焦点を合わせて、メッセージの変更を加えることを支持する輸送エージェントとユーザエージェントの作成者の概念的で実用的な基礎を提供します。
Although this memo has been specifically prepared for use with the
822 standard, an understanding of the 822 standard is not required
to make use of this memo. The remainder of this section reminds
the reader of some key concepts presented in the 822 standard, and
how they relate to the perspective of this memo.
このメモは使用のために822規格で明確に準備されましたが、822規格の理解は、このメモを利用するのに必要ではありません。 822規格で提示されたいくつかの重要な考えと、それらがどうこのメモの見解に関連するかについてこのセクションの残りは読者に思い出させます。
Messages are viewed as consisting of an envelope and contents. The
envelope is manipulated solely by transport agents, and contains
the information required by the transport agents to deliver the
message to its recipients. Although this memo does not address
itself directly to the envelope, we shall see that some of the
rules discussed later are applicable to the envelope.
メッセージは封筒とコンテンツから成ると見なされます。 封筒は、受取人に唯一輸送エージェントによって操られて、メッセージを送るために輸送エージェントによって必要とされた情報を含んでいます。 このメモは直接封筒にそれ自体を記述しませんが、私たちは、後で議論した規則のいくつかが封筒に適切であることを見るでしょう。
The contents of the message consists of a rigorously structured
part, known as the headers, followed by a freely formated part,
called the body. The message body is completely uninteresting to
us. Our emphasis is strictly on the headers of the message. Each
header in the message consists of a field, its value, and a
terminating end-of-line sequence. The 822 standard discusses,
among other things, continuation lines, the syntax that is used to
distinguish between fields and values, and the syntax and semantics
of the values of various fields. For our part, we shall concern
ourselves only with the notion that the headers section consists of
one or more headers, which are divided into one or more field/value
pairs.
メッセージのコンテンツはきびしく構造化された部分から成ります、自由にformatedされた部分があとに続いたヘッダーがボディーを呼んだように知られていて。 私たちには、メッセージ本体は完全におもしろくありません。 厳密にメッセージのヘッダーの上に私たちの強調があります。 メッセージの各ヘッダーは分野、値、および終わっている行末系列から成ります。 822規格は特に多岐の値の継続行、分野と値を見分けるのに使用される構文、構文、および意味論を定めます。 部分と、私たちは単にセクションが1個以上の分割されたヘッダーから成るヘッダーが対にするというものか以上が、さばくか、または評価する概念でタッチするつもりです。
The term "message munging" refers to the actions taken by a
transport or user agent to transform the contents of a message from
conformance with one standard format to another. The 822 standard
refers to this as "Network-Specific Transformation". Other phrases
might be "header munging" or "mail filtering". Regardless of the
term used, the key notion is that this action transforms a message
from its current format (the source message) to the structure
required by the target standard. A "munging agent", for the
purposes of this memo, is an entity which performs message munging.
A munging agent may be part of either a transport or user agent.
「メッセージの変更を加える」という用語はメッセージのコンテンツを1つの標準書式による順応から別のものに変えるために輸送かユーザエージェントによって取られた行動について言及します。 822規格は「ネットワーク特有の変化」にこれについて言及します。 他の句は、「ヘッダーの変更を加える」か「メールフィルタリング」であるかもしれません。 使用という用語にかかわらず、主要な概念はこの動作がメッセージを現在の形式(ソースメッセージ)から目標規格によって必要とされた構造に変えるということです。 このメモの目的がメッセージの変更を加えることを実行する実体であるので「変更を加えているエージェント。」 変更を加えているエージェントは輸送かユーザエージェントのどちらかの一部であるかもしれません。
Page 1 Request For Comments: 886 M. Rose Proposed Standard for Message Header Munging UCI
1ページはコメントのために以下を要求します。 886 UCIに変更を加えるメッセージヘッダーのM.バラ提案された標準
Background
バックグラウンド
As more networks connect into the ARPA Internet community, their
users will exchange computer mail messages with other Internet
hosts. Although the 822 standard must be strictly adhered to for
mail that traverses the ARPA Internet, other networks might not
internally adopt this standard. It is nevertheless desirable to
permit mail to flow between hosts which internally conform to the
standard and those which do not. The 822 standard is very clear to
indicate that:
より多くのネットワークがARPAインターネットコミュニティに接続するとき、彼らのユーザは他のインターネット・ホストとコンピュータメール・メッセージを交換するでしょう。 ARPAインターネットを横断する郵便配達人のために厳密に822規格を固く守らなければなりませんが、他のネットワークは内部的にこの規格を採用しないかもしれません。 それにもかかわらず、メールがホストの間を流れるのを許容するのは望ましいです(内部的に規格とそうしないそれらに従います)。 822規格は、示すために以下のことが非常に明確です。
"This standard is NOT intended to dictate the internal formats used by sites, the specific message system features that they are expected to support, or any of the characteristics of user interface programs that create or read messages."
「この規格がサイトによって使用される内部の形式、それらが支持すると予想される特定のメッセージシステム機能、またはメッセージを作成するか、または読むユーザーインタフェースプログラムの特性のどれかを書き取ることを意図しません。」
This plainly states that even hosts within the ARPA Internet, may
opt to use a different standard than 822 for their internal use,
but they are expressly required to use the 822 standard when
transferring mail to other hosts in the ARPA Internet. As such, it
is not difficult to imagine message munging becoming a common
activity among transport and user agents.
これは、ARPAインターネットの中のホストさえ、異なった規格を使用するために彼らの内部の使用のための822より選ぶかもしれませんが、ARPAインターネットの他のホストにメールを移すとき彼らが明白に822規格を使用しなければならないと明らかに述べます。 そういうものとして、メッセージの変更を加えることが輸送とユーザエージェントの中で一般的な活動になると想像するのは難しくはありません。
There are other reasons why message munging may become a widespread
practice. An example from CSnet will serve here. The CSnet relays
provide authorized access for mail services to the ARPA Internet
for the CSnet phonenet sites. CSnet sites are not registered with
the NIC, and hence are often absent from the host tables of ARPA
Internet sites. As a result, addresses for mailboxes on CSnet
phonenet sites are unknown to ARPA Internet sites. From an ARPA
Internet site, it would be impossible to send messages to these
addresses, since the local transport agent has no handle on the
destination hosts of the phonenet mailboxes. Obviously, even
replying to a such a message is simply not possible. To solve this
problem, the transport agents on the CSnet relays perform message
munging on mail destined for the ARPA Internet. Phonenet addresses
of the form "mbox@host" are transformed to "mbox.host@relay", where
"relay" is the ARPA Internet host name of the relay performing the
transformation. Other addresses are left alone. Agents throughout
the ARPA Internet are now able to process these addresses, since
the host-part is a known ARPA Internet host.
メッセージの変更を加えることが広範囲の習慣になるかもしれない他の理由があります。 CSnetからの例はここで役立つでしょう。 CSnetリレーはARPAインターネットに対するメールサービスのための認可されたアクセスをCSnet phonenetサイトに提供します。 CSnetサイトは、NICに登録されないで、したがって、ARPAインターネット・サイトのホストテーブルからしばしば欠けています。 その結果、ARPAインターネット・サイトにおいて、CSnet phonenetサイトのメールボックスのためのアドレスは未知です。 ARPAインターネット・サイトから、これらのアドレスにメッセージを送るのは不可能でしょう、ローカル運送エージェントがphonenetメールボックスのあて先ホストの上にハンドルを全く持っていないので。 明らかに、そのようなaメッセージに答えさえする絶対に可能ではありません。 この問題を解決するために、CSnetリレーでの輸送エージェントはARPAインターネットに運命づけられたメールのメッセージの変更を加えることを実行します。 フォーム" mbox@host "のPhonenetアドレスは" mbox.host@relay "に変えられます。そこでは、「リレー」が変化を実行するリレーのアルパインターネットホスト名です。 他のアドレスは放っておかれます。 ARPAインターネット中のエージェントは現在これらのアドレスを処理できます、ホスト部分が知られているARPAインターネット・ホストであるので。
The source-routing solution to this problem will hopefully be
replaced by domain handling when domains are implemented in the ARPA
Internet. When this is the case, phonenet addresses of the form
"mbox@host" will become "mbox@host.CSNET". Despite this change,
(which cannot help but be for the better, as the use of
source-routing leads to a plethora of problems), message munging
will still occur as it will most likely be necessary to add domain
names during message transmission (see section 6.2.2 of the 822
ARPAインターネットでドメインを実行するとき、希望をいだいてこの問題のソースルーティング解決をドメイン取り扱いに取り替えるでしょう。 これがそうであるときに、フォーム" mbox@host "のphonenetアドレスは" mbox@host.CSNET "になるでしょう。 この変化にもかかわらず(ソースルーティングの使用が多くの問題につながるように、より良いものであらざるを得ません)、それでも、メッセージ送信の間、ドメイン名を加えるのがたぶん必要であるのでメッセージの変更を加えることが起こる、(822のうちのセクション6.2.2を見てください。
Page 2 Request For Comments: 886 M. Rose Proposed Standard for Message Header Munging UCI
2ページはコメントのために以下を要求します。 886 UCIに変更を加えるメッセージヘッダーのM.バラ提案された標準
standard).
規格)
For an alternate reason, consider that it is not unlikely for users
to wish to transform mail from their archives which conforms to an
older standard to the current standard. There could be many
reasons for this, although a common one would be that a user wishes
to re-introduce the message into the transport system. Although
the aged message was perfectly valid when it was composed (e.g., in
the days of the 733 standard), it might no longer conform to the
current standard (i.e., 822). In this case, a user agent would
have to perform message munging, in order to make the message
acceptable to the local transport agent.
交互の理由で、ユーザが彼らのアーカイブからの、より古い規格に従うメールを現在の規格に変えたがっていなさそうにないと考えてください。 この多くの理由があるかもしれません、一般的なものはユーザが輸送システムにメッセージを再取り入れたがっているということでしょうが。 それが構成されたとき(例えば、733規格の数日に)、老いているメッセージは完全に有効でしたが、それはもう現在の規格(すなわち、822)に従わないかもしれません。 この場合、ユーザエージェントはメッセージの変更を加えることを実行しなければならないでしょう、メッセージをローカル運送エージェントにとって許容できるようにするように。
To summarize, even under the most "homogeneous" of environments,
message munging will still be required on the part of transport and
user agents, under certain conditions.
最も「均質」の環境さえメッセージの変更を加えることをまとめるのが輸送とユーザエージェント側のまだ必要でしょう、一定の条件の下で。
Section 3.4.10 of the 822 standard briefly discusses the topic of
"Network-Specific Transformations". In short, the 822 standard
envisions a message traversing net-A to reach net-B as going
through three phases:
.10のセクション3.4 822規格が簡潔に「ネットワーク特有の変化」の話題について議論します。 要するに、822規格は、メッセージがネットのBに達するように三相に直面しながらネットのAを横断するのを思い描きます:
o Transformation The message is made to conform to net-A's standards
o メッセージがネットのAの規格に従うためにされる変化
o Transformation Reversal Net-A's idiosyncrasies are removed and the message now conforms to the 822 standard
o 変化ReversalネットAの特異性は移されます、そして、メッセージは現在、822規格に従います。
o Transformation The message is made to conform to net-B's standards
o メッセージがネットのビーズ規格に従うためにされる変化
This memo concerns itself solely with this section of the 822
standard. The 822 standard presents end-of-line sequences as an
example of an area where transformation might occur. Although this
is a valid concern, our emphasis deals with constructs of higher
semantics: fields and structured field values.
このメモは唯一822規格のこのセクションでタッチしています。 822規格は変化が起こるかもしれない領域に関する例として行末系列を提示します。 これは有効な関心ですが、私たちの強調は、より高い意味論の構造物に対処します: 分野と構造化された分野値。
Page 3 Request For Comments: 886 M. Rose Proposed Standard for Message Header Munging UCI
3ページはコメントのために以下を要求します。 886 UCIに変更を加えるメッセージヘッダーのM.バラ提案された標準
Scope
範囲
This memo does not specify the particular transformation rules that
should be used when munging a message from one standard to another.
このメモは1つの規格から別の規格までメッセージに変更を加えるとき使用されるべきである特定の変換規則を指定しません。
Rather, this memo attempts to make clear the policies that are to
be followed when implementing any munging agent for the ARPA
Internet. The derivation of the formulas specific to message
munging between two given standards is left to the implementors of
such munging systems or to the writers of future RFCs. As such,
this memo can be considered to present the philosophy and
conceptual basis of message munging in the ARPA Internet.
むしろ、このメモは、どんな変更を加えているエージェントもARPAインターネットに実行するとき従われることになっている方針を明らかにするのを試みます。 2つの与えられた規格の間のメッセージの変更を加えるのに特定の定石の派生はシステムに変更を加えるそのようなものの作成者、または、将来のRFCsの作家に任せます。 そういうものとして、このメモがARPAインターネットのメッセージの変更を加えることの哲学と概念的基礎を提示すると考えることができます。
NOTE: It is critical that this position be understood. The actual policies used by domain-specific munging agents is completely beyond the scope of this memo.
以下に注意してください。 この位置が理解されているのは、批判的です。 ドメイン特有の変更を加えているエージェントによって使用された実際の政策は完全このメモの範囲を超えています。
For ease of explanation, some of the examples in this memo use
message munging between the ARPA Internet and the USENET
distribution network as an example. This memo should NOT be
considered to specify how this particular munging activity should
take place. Instead, this context has been chosen for its
familiarity and simplicity.
説明の容易さのために、このメモによる例のいくつかが例としてARPAインターネットとUSENET流通機構の間のメッセージの変更を加えることを使用します。 この特定の変更を加える活動がどう行われるべきであるかを指定するとこのメモを考えるべきではありません。 代わりに、この文脈はその親しみと簡単さに選ばれました。
Message Decomposition
メッセージ分解
A munging agent concerns itself with transforming a message in
conformance with a source standard to a message in conformance with a
target standard. This transformation occurs at various levels. Four
of these are presented here.
変更を加えているエージェントは、ソース規格に応じて目標規格で順応におけるメッセージを順応におけるメッセージに変えるのに携わります。 この変化は様々なレベルで起こります。 これらの4はここに提示されます。
o Field Transformation
o 分野変化
For two standards, some fields may convey identical semantics but have different names. As standards progress, for example, the names of fields may change, but the presence of those fields and their contents continue to have the same meaning. For example, prior to 822 standard, some mailers considered the Remailed- prefix to have semantics equivalent to the 822 standard's Resent- prefix. In this circumstance, one aspect of message munging would be to simply substitute the field names.
2つの規格のために、いくつかの分野には、同じ意味論を伝えますが、異なった名前があるかもしれません。 規格が進歩をするとき、例えば、分野の名前は変化するかもしれませんが、それらの分野の存在とそれらのコンテンツは、同じ意味を持ち続けています。 822規格の前に例えば意味論を822規格Resentの接頭語に同等にするようにRemailed接頭語であると考えられた何人かの郵送者。 この状況では、メッセージの変更を加えることの1つの局面は単にフィールド名を代入するだろうことです。
o Value Transformation
o 値の変化
The value of certain fields may be viewed as containing
ある一定の分野の値は含むと見なされるかもしれません。
Page 4 Request For Comments: 886 M. Rose Proposed Standard for Message Header Munging UCI
4ページはコメントのために以下を要求します。 886 UCIに変更を加えるメッセージヘッダーのM.バラ提案された標準
structured components. The syntax and semantics of these components may differ significantly between two formats. In this circumstance, one aspect of message munging would be to transform components from one representation to another.
コンポーネントを構造化しました。 これらのコンポーネントの構文と意味論は2つの形式の間で有意差があるかもしれません。 この状況では、メッセージの変更を加えることの1つの局面はコンポーネントを1つの表現から別のものに変えるだろうことです。
o Field/Value Combination
o 分野/値の組み合わせ
The semantics of a given header in a particular standard may not be directly expressed using a single header from another standard. In this circumstance, one aspect of message munging would be to map the field/value of a header in the source message to any number of headers in the target message (or vice-versa). As expected, further complication could result by performing value transformation in addition to one-to-many or many-to-one field transformation.
特定の規格における与えられたヘッダーの意味論は、別の規格から独身のヘッダーを使用することで直接言い表されないかもしれません。 この状況では、メッセージの変更を加えることの1つの局面は目標メッセージ(逆もまた同様である)のいろいろなヘッダーにソースメッセージのヘッダーの分野/値を写像するだろうことです。 予想されるように、さらなる複雑さは多くへの1か1つへの多く分野変化に加えた値の変化を実行することによって、結果として生じることができるでしょう。
o Header Ordering
o ヘッダー注文
Some standards may require that fields appear in a particular order in the headers part of the message. Others make no requirements as to the order in which the fields appear. In this circumstance, one aspect of message munging from the latter to the former standard would be to capture the essential information from the source message in order to construct the first field of the target message. As expected, further complication could result by requiring several field/values be consulted in the source message before sufficient context is present to construct the first field of the target message.
いくつかの規格が、野原がメッセージのヘッダー部分の特定のオーダーに現れるのを必要とするかもしれません。 他のものは野原が現れるオーダーに関して要件を全く作りません。 この状況では、後者から前の規格までメッセージの変更を加えることの1つの局面は目標メッセージの最初の分野を構成するためにソースメッセージから不可欠の情報を得るだろうことです。 予想されて、さらなる複雑さがいくつかの分野/値を必要とすることによって結果として生じることができるだろうというように、十分な関係が目標メッセージの最初の分野を構成するために存在している前にソースメッセージで相談されてください。
Page 5 Request For Comments: 886 M. Rose Proposed Standard for Message Header Munging UCI
5ページはコメントのために以下を要求します。 886 UCIに変更を加えるメッセージヘッダーのM.バラ提案された標準
Canonical Forms
標準形
Fundamental to the activity of transformation is the notion of a
canonical form. For a given message standard, each field and
structured field value may be thought of as an object with a
particular semantics that is representable by one or more strings.
That is, each of these strings has an identical semantics, as they
all refer to the same object. For example, in terms of the 822
standard, the two strings
変化の活動への基本的は標準形の概念です。 与えられたメッセージ規格において、各分野と構造化された分野値は1個以上のストリングで「表-可能」な特定の意味論がある物として考えられるかもしれません。 彼らが皆、同じ物を示すとき、すなわち、それぞれのこれらのストリングには、同じ意味論があります。 例えば、822規格に関する2個のストリング
The Protocol Police <NetSer@UCI>
プロトコル Police <NetSer@UCI 、gt。
NetSer@UCI
NetSer@UCI
are semantically equivalent. For the purposes of this memo, a
fully-qualified canonical form of an object is thought of as the
simplest string that represents the full and complete meaning of an
object. The meaning of "simple" is, of course, open to
interpretation. In some cases, "simplest" may mean "shortest". In
other cases, a longer, but unabbreviated string may be "simpler"
than a shorter string. Regardless of this, a canonical form is a
representation of an object. This representation contains the
smallest amount of information required to fully describe the
meaning of the object.
意味的に同等です。 このメモの目的のために、物の完全に適切な標準形は物の完全で完全な意味を表す最も簡単なストリングとして考えられます。 「簡単」の意味はもちろん解釈に開かれています。 いくつかの場合、「最も簡単」は「最も短いこと」を意味するかもしれません。 他の場合では、より長い、しかし、非簡略化されたストリングは「より脆いストリングより簡単であるかもしれません」。 これにかかわらず、標準形は物の表現です。 この表現は物の意味について完全に説明するのに必要である中で最もわずかな情報量を含んでいます。
It is not difficult to determine what a canonical form should
describe for different objects. In terms of the 822 standard, the
following should be considered as minimal definitions of canonical
forms:
標準形が異なった物のために何を説明するはずであるかを決定するのは難しくはありません。 822規格で、以下は標準形の最小量の定義であるとみなされるべきです:
object specifies contains ------ --------- -------- field field-name name address mailbox local-part domain-part date date-time date-part time-part
物が指定する、含有------ --------- -------- 分野のフィールド名名前アドレスのメールボックス地方の部分のドメイン部分の日付の日付-時間日付のパートタイム一部
In terms of USENET, the following might be considered as minimal
definitions of canonical forms:
USENETに関して、以下は標準形の最小量の定義であるとみなされるかもしれません:
object specifies contains ------ --------- -------- field field-name name address mailbox user route date date-time date-part time-part
物が指定する、含有------ --------- -------- 分野のフィールド名名前アドレスのメールボックスユーザルート日付の日付-時間日付のパートタイム一部
NOTE: This memo clearly has no authority to specify the
以下に注意してください。 このメモには、指定する権威が全く明確にありません。
Page 6 Request For Comments: 886 M. Rose Proposed Standard for Message Header Munging UCI
6ページはコメントのために以下を要求します。 886 UCIに変更を加えるメッセージヘッダーのM.バラ提案された標準
minimal canonical forms for USENET. The above table is listed solely for the benefit of the examples which follow.
USENETのための最小量の標準形。 上のテーブルは唯一従う例の利益のために記載されています。
Conceptually, transformation of fields and structured field values
occurs between canonical forms. That is, to transform an address,
one reduces the string representing the object to its canonical
form, to capture the essence of its meaning, and this form is then
transformed, somehow, to the equivalent canonical form for the
target standard. This target canonical form can later be output
using a string representation.
概念的に、分野と構造化された分野値の変化は標準形の間に起こります。すなわち、アドレスを変えるために、1つは意味の本質を得るために物を標準形に表すストリングを減少させます、そして、次に、このフォームはどうにか目標規格のための同等な標準形に変えられます。 後でこの目標標準形はストリング表現を使用する出力であるかもしれません。
NOTE: This memo does not require that canonical forms be represented or otherwise implemented as strings. Nor does this standard require that strings be used during the transformation process. Thinking of a canonical form as a string is a convenient formalism only, not an implementational requirement.
以下に注意してください。 このメモは、標準形が表されるか、または別の方法でストリングとして実行されるのを必要としません。 また、この規格は、ストリングが変化の過程の間使用されるのを必要としません。 ストリングとして標準形を考えるのは、implementational要件ではなく、便利な形式専用です。
Page 7 Request For Comments: 886 M. Rose Proposed Standard for Message Header Munging UCI
7ページはコメントのために以下を要求します。 886 UCIに変更を加えるメッセージヘッダーのM.バラ提案された標準
Transformation Rules
変換規則
All of the forms of message decomposition discussed above may now
be viewed as transformation between canonical forms. Hence, it now
becomes necessary to consider how canonical forms should be
manipulated during transformation. That is, what rules are to be
followed when constructing an equivalent canonical form? There are
several guidelines that must be followed, that we will characterize
in the following fashion:
上で議論したメッセージ分解のフォームのすべてが今、標準形の間の変化として見なされるかもしれません。したがって、現在、標準形が変化の間、どのように操られるべきであるかを考えるのが必要になります。 すなわち、どんな規則が同等な標準形を構成するとき、続かれることですか? 従わなければならないいくつかのガイドラインがあって、私たちが以下で特徴とするつもりであるのが以下を作成します。
o Preservation of information
o 情報の保存
All attempts must be made to preserve all information contained in the original canonical form. This information can be highly useful to the recipients of munged messages. Obviously, for two widely-differing formats, this may not be possible. For example, some standards may not have a group addressing notation such as the one present in the 822 standard, e.g., the notation
元の標準形に含まれたすべての情報を保存するのをすべての試みをしなければなりません。 この情報は非常に変更を加えられたメッセージの受取人の役に立つ場合があります。 明らかに、2つのはなはだしく異なった形式には、これは可能でないかもしれません。 例えば、いくつかの規格で822における現在のものなどのグループ・アドレッシング記法は標準にならないかもしれません、例えば、記法
List: Support@UCI, ZOTnet@UCI;
以下を記載してください。 Support@UCI 、ZOTnet@UCI。
might not be permitted. If one were to consider membership in a group as part of an address' canonical form, then this portion of the canonical form could not be transformed to the other standard.
受入れられないかもしれません。 1つが、グループにおける会員資格がアドレスの標準形の一部であるとみなすなら、標準形のこの一部をもう片方の規格に変えることができないでしょうに。
The 822 standard supports a liberal commenting convention which might prove quite useful in preserving information. Implementors may wish to consider capturing the original information in commentary text. For example, if the USENET address
822規格は情報を保存する際にかなり有用であることが分かるかもしれないコンベンションについて論評する自由主義者を支持します。 作成者は、論評テキストのオリジナルの情報を得ると考えたがっているかもしれません。 例えばUSENETアドレスです。
mark@cbosgd.UUCP (Mark Horton)
mark@cbosgd.UUCP (マークホートン)
had the USENET canonical of
USENETを正準にします。
user: mark route: ucbvax!ihnp4!cbosgd
ユーザ: ルートをマークしてください: ucbvax!ihnp4!cbosgd
and if the corresponding 822 canonical was
対応する822である、正準
local-part: ucbvax!ihnp4!cbosgd!mark domain-part: USENET.UCI
地方の部分: ucbvax!ihnp4!cbosgd!ドメイン部分を示してください: USENET.UCI
then it would not be unreasonable for an implementation to output this canonical form as
その時、実現がこの標準形を出力するのにおいてそれは無理でないでしょう。
"mark@cbosgd.UUCP" <ucbvax!ihnp4!cbosgd!mark@USENET.UCI>
" mark@cbosgd.UUCP "、lt;、 ucbvax!ihnp4!cbosgd!mark@USENET.UCI 、gt。
Page 8 Request For Comments: 886 M. Rose Proposed Standard for Message Header Munging UCI
8ページはコメントのために以下を要求します。 886 UCIに変更を加えるメッセージヘッダーのM.バラ提案された標準
NOTE: Implementors should exercise extreme caution in using a policy such as this. Information placed between commentary delimiters must still conform to the target standard at the syntactic level.
以下に注意してください。 作成者はこれなどの方針を使用するのに極端な警告を訓練するべきです。 論評デリミタの間に置かれた情報はまだ構文のレベルにおける目標規格に従わなければなりません。
Note however that in the above example, the commentary information "(Mark Horton)" was discarded. This practice is strongly discouraged. Although the canonical form for an object does not rely on commentary information as a necessary part, implementors are encouraged to preserve this information whenever possible.
しかしながら、上記の例では、「(マークホートン)」という論評情報が捨てられたことに注意してください。 この習慣は強くがっかりしています。 物のための標準形は必要な部分として論評情報を当てにしませんが、可能であるときはいつも、作成者がこの情報を保存するよう奨励されます。
Finally, preservation of information requires preservation of case at all costs. Only under the most restrictive of circumstances should an implementation change the case of the strings output for a canonical form.
最終的に、情報の保存はどんなことをしてもケースの保存を必要とします。 実現は最も制限している状況だけについて標準形のために出力されたストリングのケースを変えるべきです。
o Re-Formatting
o 再形式
Ideally, the target message should have the exact horizontal and vertical padding as the source message. Because a string representing the source canonical form of an object may not be of the same length as the string representing the target canonical form, the number of characters on each physical and logical line in the headers may be different.
理想的に、目標メッセージには、ソースメッセージとして正確な水平で垂直な詰め物があるべきです。 物のソース標準形を表すストリングにはストリングと同じ長さが標準形、ヘッダーの各物理的、そして、論理行のキャラクタの数が表す目標を表すのがないかもしれないので、異なってください。
The 822 standard supports a header folding convention which permits long field/value pairs to be represented on more than one physical line. When a new canonical form is output to the target message, it is possible that the resulting field/value pair may be longer than the number of characters that antiquated display devices can present on a single line. The 822 standard suggests 65 or 72 characters-per-line as a metric for this limitation. Although not required, message munging agents may re-fold headers if (and only if) this limitation is exceeded. Note however that under no circumstances should a header be re-folded if it was not munged. Refolding without munging may occur on behalf of some transport or user agent, but it may not occur on behalf of a munging agent. Put more simply, this memo does not authorize or forbid such activity, although it does discourage it.
822規格はロング・フィールド/値の組が1つ以上の物理行で代理をされることを許可するヘッダーの折りたたみのコンベンションを支持します。 新しい標準形が目標メッセージへの出力であるときに、古めかしいディスプレイ装置が単線の上に示すことができるキャラクタには結果として起こる分野/値の組が数より長い間あるのは、可能です。 822規格はこの制限における、メートル法のaとして1線あたり65か72のキャラクタを示します。 必要ではありませんが、エージェントに変更を加えるメッセージがヘッダーを再折り重ねるかもしれない、(唯一、)、この制限は超えられています。 しかしながら、それが変更を加えられないならヘッダーが決して、再折り重ねられないことに注意してください。 変更を加えるのなしでRefoldingするのは輸送かユーザエージェントを代表して起こるかもしれませんが、それは変更を加えているエージェントを代表して起こらないかもしれません。 より単に置かれて、このメモは、そのような活動を認可もしませんし、それをがっかりさせますが、禁じもしません。
o Error Recovery
o エラー回復
The preceding discussion has made been under the assumption that the objects composing the field/value pairs of the source message have conformed to the source standard. It is an unfortunate reality that this may not be the case. In fact,
先行議論は従いました。あって、作られていて、物が分野/値を構成して、対にされるソースメッセージの仮定はソース規格に従いました。 これがいずれのそうであるかもしれないのも悲しい現実ではありません。 事実上
Page 9 Request For Comments: 886 M. Rose Proposed Standard for Message Header Munging UCI
9ページはコメントのために以下を要求します。 886 UCIに変更を加えるメッセージヘッダーのM.バラ提案された標準
for those standards which are poorly specified (if at all), determining that an object is improperly constructed might be quite difficult. In addition, it is possible, though hopefully extremely improbable that a target canonical form does not exist for a particular source canonical form. In these cases, munging agents must be able to recover.
不十分に指定される(せいぜい)それらの規格において、物が不適切に組み立てられることを決定するのはかなり難しいかもしれません。 さらに、標準形がする目標が特定のソース標準形のために存在しないのは、可能であって、もっとも、願わくは非常にありそうもないです。 これらの場合では、エージェントに変更を加えるのは回復できなければなりません。
At this point, we introduce two extension fields for the 822 standard. As such, these fields are hereby designated as "reserved" and may not be used for other purposes. These fields are:
ここに、私たちは822規格のために2つの拡大野原を挿入します。 そういうものとして、これらの分野は、「予約される」ようにこれにより指定されて、他の目的に使用されないかもしれません。 これらの分野は以下の通りです。
Illegal-Field Illegal-Object
不法な分野の不法な物
The syntax of these fields is as follows:
これらの分野の構文は以下の通りです:
munge-field = "Illegal-Field" ":" *text / "Illegal-Object" ":" *text
「munge-分野は「不法な分野」と等しい」:、」 *「テキスト/「不法な物」」:、」 *テキスト
munge-object = <a "field-name", the exact field-names which are valid will be presented later>
munge-物=<は「フィールド名」、有効であるのが、提示された後の>であるということである正確なフィールド名です。
The semantics of these fields are as follows:
これらの分野の意味論は以下の通りです:
An Illegal-Field header should be introduced when a header-line which does not conform to the source standard is found in the source message. Illegal-Field should be used only when a header-line is so poorly formed as to prevent recognition of the field in the header-line. For example, if the line lacks a colon, or has a poorly formed field-name, then it should not be output to the target message and a new header-line should be introduced in its place. This header-line has Illegal-Field as its field and contains the offending line as its value. Illegal-Field should not be used if the field can be identified, but the value is poorly formed.
ソース規格に一致していないヘッダー線がソースメッセージで見つけられるとき、Illegal-分野ヘッダーは紹介されるべきです。 ヘッダー線における、分野の認識を防いで、ヘッダー線があまりに不十分に形成されるときだけ、不法な分野は使用されるべきです。 例えば、線に、コロンを欠いているか、または不十分に形成されたフィールド名があるなら、それは目標メッセージへの出力であるべきではありません、そして、新しいヘッダー線は場所で紹介されるべきです。 このヘッダー線は、分野としてIllegal-分野を持っていて、値として怒っている線を含んでいます。 分野を特定できるなら、不法な分野を使用するべきではありませんが、値を不十分に形成します。
An Illegal-Object header should be introduced when an object in the source message can not be parsed into a canonical form, or if the canonical form it represents has no corresponding target canonical form. The offending object should not be output to the target message in the header-line in which it occurs. If the header-line now contains no objects, then the header-line should not be output to the target message as well. Then, an Illegal-Object field should be introduced into the target message. The value of this Illegal-Object field should at the very minimum contain the name of the field that contained the object, the object in question, and an
ソースメッセージの物を標準形に分析できないとき、Illegal-物のヘッダーが紹介されるべきですか、またはどんな対応する目標もそれが表す標準形で正準にならないなら、形成してください。 間違っている物はそれが起こるヘッダー線における目標メッセージへの出力であるべきではありません。 ヘッダー線が現在物を全く含まないなら、ヘッダー線はまた、目標メッセージへの出力であるべきではありません。 そして、Illegal-物の野原は目標メッセージに取り入れられるべきです。 そしてこのIllegal-物の分野の値は非常に最小に物を含んだ分野の名前を含むべきです、問題の物。
Page 10 Request For Comments: 886 M. Rose Proposed Standard for Message Header Munging UCI
10ページはコメントのために以下を要求します。 886 UCIに変更を加えるメッセージヘッダーのM.バラ提案された標準
explanation as to why the object was illegal. Alternately, the value of this Illegal-Object field should consist of the entire header-line (field and value) that contained the object in question along with an explanation as to why the object was illegal.
物が不法であった理由に関する説明。 交互に、このIllegal-物の分野の値は説明と共に物が不法であった理由に関して問題の物を含んだ全体のヘッダー線(さばいて、評価する)から成るべきです。
NOTE: In the circumstance where multiple objects exist in a single header-line in the source message, and one of those objects is determined to be illegal, the actual policy used in determining how much information can be considered to be "uncorrupted" is left to the implementors. Munging agents which use sophisticated parsers may attempt to recover in mid-stream (so to speak) and continue parsing objects on the header-line. Other agents may wish to continue recover with the next header-line in the source message. Regardless of the policy used, the agent must present the contents of the entire header-line in the associated Illegal-Object header.
以下に注意してください。 複数の物がソースメッセージにただ一つのヘッダー線で存在していて、それらの物の1つが不法であると決心している状況では、どのくらいの情報が「腐敗していません」と考えることができるかを決定する際に使用される実際の方針は作成者に任せます。 エージェントに変更を加えて、どれが洗練されたパーサを使用するかが、中流(言わば)の中で回復して、ヘッダー線の上で物を分析し続けているのを試みるかもしれません。 他のエージェントは、続くように、次のヘッダー線がソースメッセージにある状態で回復するように願うかもしれません。 使用される方針にかかわらず、エージェントは関連Illegal-物のヘッダーに全体のヘッダー線のコンテンツを提示しなければなりません。
Implementations should not take extraordinary measures to perform syntax/semantics checking of the source message -- only those fields which must be examined should be rigorously checked. This memo strongly discourages any additional examination. It is not the intention of this memo to suggest that composing agents should produce messages which do not conform to the source standard. A composing agent should not expect a munging agent to enforce adherence to the source standard.
実現はソースメッセージの構文/意味論の照合を実行する並はずれた対策を実施するべきではありません--調べなければならないそれらの分野だけがきびしくチェックされるべきです。 このメモは強くどんな追加試験にも水をさしています。 ソース規格に従わないのは、このメモが、エージェントを構成するとメッセージが出されるべきであると示唆するという意志ではありません。 構成しているエージェントは、変更を加えているエージェントがソース規格に支持を強要すると予想するべきではありません。
o Introduction of Information
o 情報の導入
Munging agents are authorized to introduce a "Received" header into the target message when a message is transformed.
変更を加えて、メッセージが変成しているとき、エージェントが「受け取られていている」ヘッダーを目標メッセージに取り入れるのに権限を与えられます。
NOTE: Adding a "Received" header is entirely optional. This memo strongly recommends that this header be introduced whenever some munging (translation of addresses and/or dates) occurs.
以下に注意してください。 「受け取られていている」ヘッダーを加えるのは完全に任意です。 このメモは、いくつかの変更を加えること(アドレス、そして/または、日付に関する翻訳)が起こるときはいつも、このヘッダーが紹介されることを強く勧めます。
NOTE: Although this memo does not specify the position that the introduced header should have in relation to the other fields in the target message, it is strongly recommended that the introduced header be grouped with the other "Received" headers, at the very beginning of the message.
以下に注意してください。 このメモは導入されたヘッダーが目標メッセージの他の分野と関連して持つべきである位置を指定しませんが、導入されたヘッダーが開口一番他の「受け取られていている」ヘッダーと共にメッセージについて分類されることが強く勧められます。
When introducing a "Received" field, three phrases, which are normally optional in such a field, should be specified by the munging agent. These are:
「受け取られていている」野原を挿入するとき、3つの句(通常、そのような分野で任意である)が変更を加えているエージェントによって指定されるべきです。 これらは以下の通りです。
Page 11 Request For Comments: 886 M. Rose Proposed Standard for Message Header Munging UCI
11ページはコメントのために以下を要求します。 886 UCIに変更を加えるメッセージヘッダーのM.バラ提案された標準
"from" domain # the source domain "by" domain # the target domain "with" protocol # the munging agent's host
"from"ドメイン#、ソースドメイン“by"ドメイン、#目的のドメイン“with"は変更を加えているエージェントのものが接待する#、について議定書の中で述べます。
For example, suppose we have a munging agent on the UCI host, and that this agent services a USENET/ARPA boundary. When the UCI host gets a message from the USENET domain for the ARPA domain, the following happens: First, the UCI mailsystem would prepend the header:
例えば、私たちには変更を加えているエージェントがUCIホストの上にいて、このエージェントがUSENET/ARPA境界を修理すると仮定してください。 UCIホストがUSENETドメインからARPAドメインにメッセージを届けるとき、以下は起こります: まず最初に、UCI mailsystemはヘッダーをprependするでしょう:
Received: from nma by UCI with UUCP; 15 Dec 83 03:53:00 PST
受け取られている: UUCPとUCIによるnmaから。 1983年12月15日の太平洋標準時3時53分0秒
Second, the munging agent, when transforming the message, would prepend the header:
メッセージを変えるとき、2番目に、変更を加えているエージェントはヘッダーをprependするでしょう:
Received: from USENET by ARPA with UCI; 15 Dec 03:54:00 PST
受け取られている: UCIがあるアルパによるUSENETから。 2003年12月15日:54:太平洋標準時00
Finally, the UCI mailsystem would then deliver the message to the appropriate ARPA mailsystem, which in turn would prepend the header:
次に、最終的に、UCI mailsystemは適切なARPA mailsystemにメッセージを渡すでしょう:(順番に、ARPA mailsystemはヘッダーをprependするでしょう)。
Received: from UCI by ISIF with SMTP; 15 Dec 83 03:55:00 PST
受け取られている: SMTPとISIFによるUCIから。 1983年12月15日の太平洋標準時3時55分0秒
This example might be a bit clearer if the domains were qualified a bit more. The first three lines of the message could look like this:
この例はドメインがもう少し資格があったかどうか少し明確であるかもしれません。 メッセージの最初の3つの線がこれに似るかもしれません:
Received: from UCI.ARPA by ISIF.ARPA; 15 Dec 83 03:55:00 PST Received: from USENET by ARPA with UCI; 15 Dec 03:54:00 PST Received: from nma.USENET by UCI.USENET; 15 Dec 83 03:53:00 PST
受け取られている: ISIF.ARPAによるUCI.ARPAから。 1983年12月15日の太平洋標準時3時55分0秒は受けました: UCIがあるアルパによるUSENETから。 2003年12月15日:54:太平洋標準時00は受けました: UCI.USENETによるnma.USENETから。 1983年12月15日の太平洋標準時3時53分0秒
The key point to notice is that the munging agent used the "from" and "by" clauses to denote the domain boundary that was crossed, and used the "with" clause to denote itself. Since the agent is munging the message according to some set of transformation rules, it is actually using a "mail protocol", and as such is justified in identifying itself in the "with" clause.
気付く要所は変更を加えているエージェントが交差されたドメイン境界を指示するのに“from"と“by"節を使用して、それ自体を指示するのに“with"節を使用したということです。 何らかのセットの変換規則に応じてエージェントがメッセージに変更を加えているので、それは、実際に「メールプロトコル」を使用していて、“with"節でそれ自体を特定する際にそういうものとして正当化されます。
Page 12 Request For Comments: 886 M. Rose Proposed Standard for Message Header Munging UCI
12ページはコメントのために以下を要求します。 886 UCIに変更を加えるメッセージヘッダーのM.バラ提案された標準
Objects of Interest
興味がある物
At present, only three types of objects are of interest: fields,
addresses, and dates. In the context of the 822 standard,
header-lines containing the following fields are to be viewed as
appropriate for transformation:
現在のところ、3つのタイプの物だけが興味があります: 分野、アドレス、および日付。 822規格の文脈では、以下の分野を含むヘッダー線は変化に関して適宜見られることです:
Address Fields: From, Sender, Reply-To, To, cc, Bcc,
and any of these fields with the Resent- prefix
分野を記述してください: Sender、Reply、-、Resent接頭語があるこれらの分野のTo、cc、Bcc、およびいずれも
Date Fields: Date, Resent-Date
分野の日付を入れてください: -デートしてください、そして、再送して、デートしてください。
Hence the definition of munge-object, in 822 terms, is:
したがって、822の用語によるmunge-物の定義は以下の通りです。
munge-object = "From" / "Sender" / "Reply-To" / "To" / "cc" / "Bcc" / "Resent-From" / "Resent-Sender" / "Resent-Reply-To" / "Resent-To" / "Resent-cc" / "Resent-Bcc" / "Date" / "Resent-Date"
munge物の=/が「答える」“From"/「送付者」/“To"/「cc」/"Bcc"/、「憤慨、-、」 /、「送付者に憤慨する、」 /、「回答に憤慨する、」 /、「憤慨、-、」 /、「ccに憤慨する、」 /、「」 /が「デートする」というBccに憤慨している/、「-再送して、デートしてください」
NOTE: The list of munge-objects is extensible. For the purposes of this memo, the above fields are defined as the MINIMUM list of munge-objects for the 822 standard. Implementors are encouraged to introduce other fields to the list of munge-objects as their munging agents require. These additions should also be registered with the revisions of this memo as they gain popularity.
以下に注意してください。 munge-物のリストは広げることができます。 このメモの目的において、上の分野は822規格のためにmunge-物のMINIMUMリストと定義されます。 エージェントに変更を加えるのが必要であるように作成者がmunge-物のリストに他の野原を紹介するよう奨励されます。 また、人気を獲得するのに従って、これらの追加はこのメモの改正に登録されるべきです。
For the purposes of the remainder of this memo, an address
header-line is defined as any header-line in the source message
whose field component is one of the fields listed above as an
address field. Further, a date header-line is defined as any
header-line in the source message whose field component is one of
the fields listed above as an date field.
このメモの残りの目的のために、アドレスヘッダー線は分野コンポーネントがアドレス・フィールドとして上に記載された分野の1つであるソースメッセージのどんなヘッダー線とも定義されます。 さらに、日付のヘッダー線は分野コンポーネントが年月日欄として上に記載された分野の1つであるソースメッセージのどんなヘッダー線とも定義されます。
If address munging is performed, then all addresses contained in
all address header-lines must be munged. It is expressly forbidden
to perform address munging on the source message and without
performing address munging on every address header-line. Further,
it is expressly forbidden to munge some, but not all, of the
addresses in any address header-line. All addresses in all of the
アドレスであるなら、変更を加えることは実行されて、次に、すべてのアドレスヘッダー線に含まれたすべてのアドレスに変更を加えなければなりません。 それがソースメッセージとあらゆるアドレスヘッダー線のアドレスの変更を加えることを実行しないでアドレスの変更を加えることを実行するのが明白に禁じられます。 さらに、どんなアドレスヘッダー線でもすべてではなく、アドレスのいくつかをmungeするのが明白に禁じられます。 すべてがすべてに記述します。
Page 13 Request For Comments: 886 M. Rose Proposed Standard for Message Header Munging UCI
13ページはコメントのために以下を要求します。 886 UCIに変更を加えるメッセージヘッダーのM.バラ提案された標準
message's address header-lines must be address munged. If address
munging is not performed, then these header-lines need not be
considered for munging.
メッセージのアドレスヘッダー線は変更を加えられたアドレスであるに違いありません。 変更を加えることがアドレスであるなら実行されないのに変更を加えます次に、これらのヘッダー線が考えられる必要はない。
A similar requirement is made for date munging. If date munging is
performed, then all instances of header-lines whose field is Date
or Resent-Date must be fully date munged.
同様の要件は日付の変更を加えるために作られています。 日付であるなら、変更を加えることは実行されて、次に、分野がDateであるヘッダー線かResent-日付のすべての例は変更を加えられた状態で完全にデートすることであるに違いありません。
NOTE: Certain fields are to be excluding from munging of any sort, all munging agents must preserve their contents exactly. At present, there is one such field: "Received". This contents of this field should ALWAYS be preserved for trace and debugging purposes.
以下に注意してください。 ある一定の分野がどんな種類についても変更を加えるのからの除外であることである、エージェントに皆、変更を加えると、彼らのコンテンツはまさに保存されなければなりません。 現在のところ、そのような分野の1つがあります: 「受け取られています」。 この分野のこのコンテンツは跡として保存されて、目的をデバッグすることであるALWAYSがそうするべきです。
Page 14 Request For Comments: 886 M. Rose Proposed Standard for Message Header Munging UCI
14ページはコメントのために以下を要求します。 886 UCIに変更を加えるメッセージヘッダーのM.バラ提案された標準
Bibliography
図書目録
D.H. Crocker, "Standard for the Format of ARPA Internet Text
Messages", RFC 822, (August, 1982).
D.H.クロッカー、「アルパインターネットテキスト・メッセージの形式の規格」、RFC822(1982年8月)。
M.R. Horton, "Standard for the Interchange of USENET Messages", RFC
850, (June, 1983).
M.R.ホートン、「USENETメッセージの置き換えの規格」、RFC850(1983年6月)。
M.T. Rose, "Achieving Interoperability between two Domains --
Connecting the ZOTnet and UUCP Computer Mail Networks", Technical
Report Number 201, Department of Information and Computer Science,
University of California, Irvine, (January, 1983).
Technical Report Number201、「ZOTnetとUUCPコンピュータメールNetworksを接続して、2Domainsの間でInteroperabilityを達成すること」での情報とコンピュータScience、カリフォルニア大学アーバイン校(1983年1月)のM.T.バラ部。
P.V. Mockapetris, "Domain Names -- Concepts and Facilities", RFC
882, (November, 1983).
P.V.Mockapetris、「ドメイン名--、概念と施設、」、RFC882、(1983年11月。)
Page 15 Request For Comments: 886 M. Rose Proposed Standard for Message Header Munging UCI
15ページはコメントのために以下を要求します。 886 UCIに変更を加えるメッセージヘッダーのM.バラ提案された標準
Appendices
付録
Minimal Canonical Forms
最小量の標準形
This memo defines the minimal canonical forms for the 822 standard.
Implementations may wish to augment these forms with additional
information that may be present in the source message. An earlier
example suggested that group membership might be part of an
address' canonical form. Further, since the 822 standard permits
routes to be specified in addresses, e.g.,
このメモは822規格のための最小量の標準形を定義します。 実現はソースメッセージに存在するかもしれない追加情報でこれらのフォームを増大させたがっているかもしれません。 以前の例は、グループ会員資格がアドレスの標準形の一部であるかもしれないと示唆しました。 さらに、822以来、規格は、ルートが例えばアドレスで指定されることを許可します。
Fred Rated <@ISI-Troll.ARPA,@UCI-750a.UCI: FRated@UCI-750b>
フレッド Rated <@ISI-Troll.ARPA 、@UCI-750a. UCI: FRated@UCI-750b 、gt。
Perhaps they too should be considered part of the 822 address'
canonical form?
恐らく、それらも822アドレスの標準形の一部であると考えられるべきですか?
This memo makes no such requirement, if implementations wish to
make use of this additional information, then they are free to do
so. This practice is neither encouraged nor discouraged. In short
the spirit of this memo is to require those minimal components
required by the 822 standard, nothing more.
このメモがどんなそのような要件も作らないので、実現がこの追加情報を利用したいなら、それらは自由にそうすることができます。 この習慣は、奨励されないで、またがっかりしていません。 要するにこのメモの精神は822規格、より多いものは何によっても必要とされなかったそれらの最小量のコンポーネントを必要とすることになっています。
Page 16
16ページ
一覧
スポンサーリンク
