RFC987 日本語訳
0987 Mapping between X.400 and RFC 822. S.E. Kille. June 1986. (Format: TXT=127540 bytes) (Obsoleted by RFC2156, RFC1327) (Updated by RFC1026, RFC1138, RFC1148) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
UCL Technical Report 120 Mailgroup Note 19
UCL技術報告書120Mailgroup注意19
Network Working Group S.E. Kille
Request for Comments: 987 University College London
June 1986
Killeがコメントのために要求するワーキンググループ東南をネットワークでつないでください: 987 ユニバーシティ・カレッジロンドン1986年6月
Mapping between X.400 and RFC 822
X.400とRFC822の間のマッピング
Status of This Memo
このメモの状態
This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このRFCは改良のためにARPA-インターネットコミュニティ、要求議論、および提案のための提案されたプロトコルを勧めます。 このメモの分配は無制限です。
This document describes a set of mappings which will enable interworking between systems operating the CCITT X.400 (1984) series of protocols [CCITT84a], and systems using the RFC 822 mail protocol [Crocker82a], or protocols derived from RFC 822. The approach aims to maximise the services offered across the boundary, whilst not requiring unduly complex mappings. The mappings should not require any changes to end systems.
このドキュメントはプロトコル[CCITT84a]、およびRFC822メールプロトコルを使用するシステムのCCITT X.400(1984)シリーズ[Crocker82a]、またはRFC822から得られたプロトコルを操作するシステムの間の織り込むことを可能にする1セットのマッピングについて説明します。 アプローチは、過度に複雑なマッピングを必要としていない間に境界の向こう側に提供されたサービスを最大にすることを目指します。 マッピングは、どんな変化もシステムを終わらせるのを必要とするべきではありません。
This specification should be used when this mapping is performed on the ARPA-Internet or in the UK Academic Community. This specification may be modified in the light of implementation experience, but no substantial changes are expected.
このマッピングがARPA-インターネットの上、または、イギリスのAcademic Communityで実行されるとき、この仕様は使用されるべきです。 この仕様は実現経験の見地から変更されるかもしれませんが、大きな変化は全く予想されません。
Kille [Page 1]
Kille[1ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
Chapter 1 -- Overview
第1章--概観
1.1. X.400
1.1. X.400
The X.400 series protocols have been defined by CCITT to provide
an Interpersonal Messaging Service (IPMS), making use of a store
and forward Message Transfer Service. It is expected that this
standard will be implemented very widely. As well as the base
standard (X.400), work is underway on various functional standards
of profiles which specify how X.400 will be used in various
communities. Many of the major functional standards (e.g. from
CEPT, CEN/CENELEC, and NBS) are likely to be similar. Some of the
decisions in this document are in the light of this work. No
reference is given, as these documents are not currently stable.
X.400シリーズプロトコルはInterpersonalメッセージサービス(IPMS)を提供するためにCCITTによって定義されました、店と前進のMessage Transfer Serviceを利用して。 この規格が非常に広く実行されると予想されます。 ベース規格(X.400)と同様に、仕事はX.400が様々な共同体でどう使用されるかを指定するプロフィールの様々な機能標準で進行中です。 主要な機能標準(例えば、CEPT、CEN/CENELEC、およびNBSからの)の多くが同様である傾向があります。 決定のいくつかがこの仕事の見地から本書ではあります。 これらのドキュメントが現在安定していないとき、参照を全く与えません。
1.2. RFC 822
1.2. RFC822
RFC 822 evolved as a messaging standard on the DARPA (the US
Defense Advanced Research Projects Agency) Internet. It is
currently used on the ARPA-Internet in conjunction with two other
standards: RFC 821, also known as Simple Mail Transfer Protocol
(SMTP) [Postel82a], and RFC 920 which is a specification for a
domain name system and a distributed name service [Postel84a].
RFC 822, or protocols derived from RFC 822 are used in a number of
other networks. In particular:
RFC822はメッセージングとしてDARPAの標準(米国国防高等研究計画庁)のインターネットを発展しました。 それは現在、ARPA-インターネットで他の2つの規格に関連して使用されます: また、シンプルメールトランスファプロトコル(SMTP)として知られているRFC821[Postel82a]、およびドメイン名システムと分配された名前サービスのための仕様であるRFC920[Postel84a]。 RFC822、または使用されるRFC822から他の多くのネットワークで得られたプロトコル。 特に:
UUCP Networks
UUCPネットワーク
UUCP is the UNIX to UNIX CoPy protocol <0>, which is usually
used over dialup telephone networks to provide a simple
message transfer mechanism. There are some extensions to
RFC 822, particularly in the addressing. They are likely to
use domains which conform to RFC 920, but not the
corresponding domain nameservers [Horton86a].
UUCPは簡単なメッセージトランスファ・メカニズムを供給する0>(通常、ダイアルアップの上で使用される)がネットワークに電話をするUNIX CoPyプロトコル<へのUNIXです。 RFC822と、特にアドレシングにはいくつかの拡大があります。 それらは対応するドメインネームサーバ[Horton86a]ではなく、RFC920に従うドメインを使用しそうです。
CSNET
CSNET
Some portions of CSNET will follow the ARPA-Internet
protocols. The dialup portion of CSNET uses the Phonenet
protocols as a replacement for RFC 821. This portion is
likely to use domains which conform to RFC 920, but not the
corresponding domain nameservers.
CSNETのいくつかの一部がARPA-インターネットプロトコルに従うでしょう。 CSNETのダイアルアップ一部がRFC821に交換としてPhonenetプロトコルを使用します。 この部分は対応するドメインネームサーバではなく、RFC920に従うドメインを使用しそうです。
BITNET
Bitnet
Some parts of BITNET use RFC 822 related protocols, with
EBCDIC encoding.
Bitnetのいくつかの部分がEBCDICコード化があるRFC822関連するプロトコルを使用します。
Kille [Page 2]
Kille[2ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
JNT Mail Networks
JNTはネットワークに郵送します。
A number of X.25 networks, particularly those associated
with the UK Academic Community, use the JNT (Joint Network
Team) Mail Protocol, also known as Greybook [Kille84a].
This is used with domains and name service specified by the
JNT NRS (Name Registration Scheme) [Larmouth83a].
多くのX.25ネットワーク(特にイギリスのAcademic Communityに関連づけられたもの)がまた、Greybook[Kille84a]として知られているJNT(共同Network Team)メールプロトコルを使用します。 これはJNT NRS(名前Registration Scheme)[Larmouth83a]によって指定されるドメインと名前サービスと共に使用されます。
The mappings specified here are appropriate for all of these
networks.
これらのネットワークのすべてに、ここで指定されたマッピングは適切です。
1.3. The Need for Conversion
1.3. 変換の必要性
There is a large community using RFC 822 based protocols for mail
services, who will wish to communicate with X.400 systems. This
will be a requirement, even in cases where communities intend to
make a transition to use of X.400, where conversion will be needed
to ensure a smooth service transition. It is expected that there
will be more than one gateway <1>, and this specification will
enable them to behave in a consistent manner. These gateways are
sometimes called mail relays. Consistency between gateways is
desirable to provide:
これは要件になるでしょう、共同体が使用する変遷をするつもりであるX.400の場合でさえ。メールサービスにRFC822に基づいているプロトコルを使用する大きい共同体があります。(共同体はX.400システムとコミュニケートしたくなるでしょう)。(そこでは、変換が、滑らかなサービス変遷を確実にするのに必要でしょう)。 一貫した態度で反応させる1>、およびこの仕様が彼らを可能にする1門以上の<があると予想されます。 これらのゲートウェイは時々メール中継と呼ばれます。 ゲートウェイの間の一貫性は提供するのにおいて望ましいです:
1. Consistent service to users.
1. ユーザに対する一貫したサービス。
2. The best service in cases where a message passes through
multiple gateways.
2. メッセージが複数のゲートウェイを通り抜ける場合で最も良いサービス。
1.4. General Approach
1.4. 一般的方法
There are a number of basic principles underlying the details of
the specification.
仕様の細目の基礎となる多くの基本原理があります。
1. The specification should be pragmatic. There should not
be a requirement for complex mappings for 'Academic'
reasons. Complex mappings should not be required to
support trivial additional functionality.
1. 仕様は実践的であるべきです。 'アカデミックな'理由による複雑なマッピングのための要件があるべきではありません。 些細な追加機能性を支持するために複雑なマッピングを必要とするべきではありません。
2. Subject to 1), functionality across a gateway should be as
high as possible.
2. 1)を条件として、ゲートウェイの向こう側の機能性はできるだけ高いはずです。
3. It is always a bad idea to lose information as a result of
any transformation. Hence, it is a bad idea for a gateway
to discard information in the objects it processes. This
includes requested services which cannot be fully mapped.
3. いつもどんな変化の結果、情報を失うのは、悪い考えです。 したがって、ゲートウェイがそれが処理する物で情報を捨てるのは、悪い考えです。 これは完全に写像できるというわけではない要求されたサービスを含んでいます。
4. All mail gateways actually operate at exactly one level
4. すべてのメール・ゲートウェイが実際にまさに1つのレベルで作動します。
Kille [Page 3]
Kille[3ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
above the layer on which they conceptually operate. This
implies that the gateway must not only be cognisant of the
semantics of objects at the gateway level, but also be
cognisant of higher level semantics. If meaningful
transformation of the objects that the gateway operates on
is to occur, then the gateway needs to understand more
than the objects themselves.
彼らが概念的に作動させる層を超えて。 これは、ゲートウェイが単にゲートウェイレベルにおいて物の意味論で認識力があるのではなく、より高い平らな意味論において認識力がありもするに違いないのを含意します。 ゲートウェイが作動させる物の重要な変化が起こるつもりであるなら、ゲートウェイは、物自体より分かる必要があります。
1.5. Gatewaying Model
1.5. モデルをGatewayingします。
1.5.1. X.400
1.5.1. X.400
The CCITT X.400 series recommendations specify a number of
services and protocols. The services are specified in X.400.
Two of these services are fundamental to this document:
CCITT X.400シリーズ推薦は多くのサービスとプロトコルを指定します。 サービスはX.400で指定されます。 これらの2つのサービスがこのドキュメントに基本的です:
1. The Message Transfer Service, which can be provided by
either the P1 or P3 protocols, which are specified in
X.411 [CCITT84b]. This document talks in terms of P1,
but the mappings are equally applicable to P3.
1. Message Transfer Service。(P1かP3プロトコルのどちらかはそのMessage Transfer Serviceを提供できます)。(プロトコルはX.411[CCITT84b]で指定されます)。 このドキュメントはP1に関して話しますが、マッピングは等しくP3に適切です。
2. The Interpersonal Messaging Service (IPMS), which is
provided by the P2 protocol specified in X.420
[CCITT84c].
2. Interpersonalメッセージサービス(IPMS)(P2によって提供される)はX.420[CCITT84c]で指定されていた状態で議定書を作ります。
This document considers only IPMS, and not of any other usage
of the Message Transfer Service. This is reasonable, as
RFC 822, broadly speaking, provides a service corresponding to
IPMS, and no services other than IPMS have been defined over
the Message Transfer Service. As none of the RTS (Reliable
Transfer Service) service elements is available to the IPMS
user, this level and lower levels are of no concern in this
gatewaying specification. Note that in this memo "IP" means
"InterPersonal" (not Internet Protocol).
このドキュメントは、IPMSだけを考えて、Message Transfer Serviceのどんないかなる他の使用法についてもそうしません。 これは妥当です、RFC822が概してIPMSに対応するサービスを提供して、IPMS以外のサービスが全くMessage Transfer Serviceの上で定義されていないとき。 IPMSユーザには、RTS(信頼できるTransfer Service)サービス要素のいずれも有効でないように、これでどんな関心も仕様をgatewayingしないのがこのレベルと下のレベルにあります。 「IP」というこのメモによるそれが「個人間であること」を(インターネットプロトコルでない)意味することに注意してください。
The Message Transfer Service defines an end-to-end service over
a series of Message Transfer Agents (MTA). It also defines a
protocol, P1, which is used between a pair of MTAs. This
protocol is simply a file format (Message Protocol Data Unit,
or MPDU), transferred between two MTAs using the RTS. There
are three types of MPDU:
Message Transfer ServiceはMessage Transferエージェント(MTA)の終わりから終わりへのサービスオーバーaシリーズを定義します。 また、それはプロトコル、1組のMTAsの間で使用されるP1を定義します。 このプロトコルは単にRTSを使用することで2MTAsの間に移されたファイル形式(メッセージプロトコルのData Unit、またはMPDU)です。 MPDUの3つのタイプがあります:
User MPDU
ユーザMPDU
This contains envelope information, and uninterpreted
contents. The envelope includes an ID, an originator, a
これは封筒情報、および非解釈されたコンテンツを含んでいます。 封筒はID、創始者、aを含んでいます。
Kille [Page 4]
Kille[4ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
list of recipients, and trace information. It is used to
carry data for higher level services.
受取人のリスト、およびトレース情報。 それは、より高い平らなサービスのためのデータを運ぶのに使用されます。
Probe
徹底的調査
This contains only envelope information. It is used to
determine whether a User UMPDU could be delivered to a
given O/R (originator/recipient) name.
これは封筒情報だけを含んでいます。 それは、与えられたO/R(創始者/受取人)名にUser UMPDUを届けることができたかどうか決定するのに使用されます。
Delivery Report
配送レポート
This contains envelope information, and specified
contents. It is used to indicate delivery success or
failure of a User or Probe MPDU over the Message Transfer
Service.
これは、封筒情報を含んで、コンテンツを指定しました。 それは、Message Transfer Serviceの上にUserかProbe MPDUの配送成否を示すのに使用されます。
IPMS (P2) specifies two content types for the P1 User MPDU
(User Agent Protocol Data Units or UAPDU):
IPMS(P2)はP1 User MPDU(ユーザエージェントプロトコルData UnitsかUAPDU)のための2つの満足しているタイプを指定します:
Interpersonal Message (IM-UAPDU)
個人間のメッセージ(不-UAPDU)
This has two components: a heading, and a body. The body
is structured as a sequence of body parts, which may be
basic components (e.g.IA5 text, or G3 fax), or IP
Messages. The header contains end to end user
information, such as subject, primary recipients (To:),
and priority. The validity of these fields is not
guaranteed by the Message Transfer Service. This
provides the basic IPMS.
これには、2つのコンポーネントがあります: 見出し、およびボディー。 ボディーは基本的なコンポーネントであるかもしれない身体の部分(例えば、IA5テキスト、またはG3ファックス)、またはIP Messagesの系列として構造化されます。 ヘッダーはエンドユーザ情報の受けることがあって、第一の受取人などの終わり(To:)、および優先権を含んでいます。 これらの分野の正当性はMessage Transfer Serviceによって保証されません。 これは基本的なIPMSを提供します。
Status Report (SR-UAPDU)
現状報告(SR-UAPDU)
This UAPDU has defined contents. It is used to indicate
that a message has been received by a User Agent. It
does not have to be implemented.
このUAPDUはコンテンツを定義しました。 それは、メッセージがUserエージェントによって受け取られたのを示すのに使用されます。 それは実行される必要はありません。
1.5.2. RFC 822
1.5.2. RFC822
RFC 822 is based on the assumption that there is an underlying
service, which is here called the 822-P1 service. The 822-P1
service provides three basic functions:
RFC822は822-P1サービスと呼ばれて、ここにある基本的なサービスがあるという仮定に基づいています。 822-P1サービスは3つの基本機能を提供します:
1. Identification of a list of recipients.
1. 受取人のリストの識別。
2. Identification of an error return address.
2. 誤り返送先の識別。
3. Transfer of an RFC 822 message.
3. RFC822メッセージの転送。
Kille [Page 5]
Kille[5ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
It is possible to achieve 2) within the RFC 822 header. Some
822-P1 protocols, in particular SMTP, can provide additional
functionality, but as these are neither mandatory in SMTP, nor
available in other 822-P1 protocols, they are not considered
here. Details of aspects specific to a number of 822-P1
protocols are given in appendices B to E. An RFC 822 message
consists of a header, and content which is uninterpreted ASCII
text. The header is divided into fields, which are the
protocol elements. Most of these fields are analogous to P2
header elements, although some are analogous to P1 envelope
elements.
RFC822ヘッダーの中に2を)達成するのは可能です。 いくつかの822-P1プロトコル(特にSMTP)がこれらとして追加機能性を提供できますが、SMTPで義務的でなくて、また他の822-P1プロトコルでは利用可能でない、それらはここで考えられません。 多くの822-P1プロトコルに特定の局面の詳細は付録BでE.に明らかにされます。An RFC822メッセージは非解釈されたASCIIテキストであるヘッダー、および内容から成ります。 ヘッダーは分野に分割されます。(分野はプロトコル要素です)。 これらの分野の大部分は、或るものがP1封筒要素に類似していますが、P2ヘッダー要素に類似しています。
1.5.3. The Gateway
1.5.3. ゲートウェイ
Given this functional description of the two protocols, the
functional nature of a gateway can now be considered. It would
be elegant to consider the 822-P1 service mapping onto P1 and
RFC 822 mapping onto P2, but reality just does not fit.
Therefore one must consider that P1 or P1 + P2 on one side are
mapped into RFC 822 + 822-P1 on the other in a slightly tangled
manner. The details of the tangle will be made clear in
chapter 5. The following basic mappings are thus proposed.
When going from RFC 822 to X.400, an RFC 822 message and the
associated 822-P1 information is always mapped into an IM-UAPDU
and the associated P1 envelope. Going from X.400 to RFC 822,
an RFC 822 message and the associated 822-P1 information may be
derived from:
2つのプロトコルのこの機能的な記述を考えて、現在、ゲートウェイの機能的な自然を考えることができます。 822-P1がサービス対応表であるとP2へのP1とRFC822マッピングと考えるのが上品でしょうが、現実はただ合いません。 したがって、半面の上のP1かP1+P2がもう片方でわずかにもつれている方法でRFC822+822-P1に写像されると考えなければなりません。 もつれの詳細は第5章で明らかにされるでしょう。 以下の基本のマッピングはこのようにして提案されます。 RFC822からX.400まで行くとき、RFC822メッセージと関連822-P1情報はいつもIM-UAPDUと関連P1封筒に写像されます。 RFC822、RFC822メッセージ、およびX.400から関連822-P1情報まで行くのは以下から引き出されるかもしれません。
1. A Delivery Report MPDU
1. 配送レポートMPDU
2. An SR-UAPDU and the associated P1 envelope.
2. SR-UAPDUと関連P1封筒。
3. An IM-UAPDU and the associated P1 envelope.
3. IM-UAPDUと関連P1封筒。
Probe MPDUs must be processed by the gateway - this is
discussed in chapter 5. Any other User MPDUs are not mapped by
the gateway, and should be rejected at the gateway.
ゲートウェイで徹底的調査MPDUsを処理しなければなりません--これは第5章で論じられます。 いかなる他のUser MPDUsもゲートウェイによって写像されないで、ゲートウェイで拒絶されるべきです。
Kille [Page 6]
Kille[6ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
1.6. Document Structure
1.6. ドキュメント構造
This document has five chapters:
このドキュメントには、5つの章があります:
1. Overview - this document.
1. 概観--このドキュメント。
2. Service Elements - This describes the (end user) services
mapped by a gateway.
2. Elementsにサービスを提供してください--これはゲートウェイによって写像された(エンドユーザ)サービスについて説明します。
3. Basic mappings - This describes some basic notation used
in chapters 3-5, the mappings between character sets, and
some fundamental protocol elements.
3. 基本のマッピング--これは第3-5章、文字の組の間のマッピングで使用される、何らかの基本的な記法、およびいくつかの基本的なプロトコル要素について説明します。
4. Addressing - This considers the mapping between X.400 O/R
names and RFC 822 addresses, which is a fundamental
gateway component.
4. アドレシング--これはX.400O/R名とRFC822のアドレスの間のマッピングを考えます。(それは、基本的なゲートウェイの部品です)。
5. Protocol Elements - This describes the details of all
other mappings.
5. Elementsについて議定書の中で述べてください--これは他のすべてのマッピングの詳細について説明します。
There are also six appendices:
また、6個の付録があります:
A. Quoted String Encodings.
A.引用文字列Encodings。
B. Mappings Specific to JNT Mail.
JNTに特定のマッピングが郵送するB.。
C. Mappings Specific to Internet Mail.
インターネットに特定のマッピングが郵送するC.。
D. Mappings Specific to Phonenet Mail.
Phonenetに特定のマッピングが郵送するD.。
E. Mappings Specific to UUCP Mail.
UUCPに特定のマッピングが郵送するE.。
F. Format of Address Tables.
アドレス・テーブルのF.形式。
1.7. Acknowledgements
1.7. 承認
This document is eclectic, and credit should be given:
このドキュメントは折衷主義者です、そして、クレジットを与えるべきです:
- Study of the EAN X.400 system code which performs this
function [Neufeld85a]. Some detailed clarification was
made by the DFN report on EAN [Bonacker85a].
- この機能[Neufeld85a]を実行するEAN X.400システム・コードの研究。 DFNレポートはEAN[Bonacker85a]で何らかの詳細に渡る説明をしました。
- An unpublished ICL report, which considered a subset of
the problem [ICL84a].
- 未発表のICL(問題[ICL84a]の部分集合を考えた)は報告します。
- A document by Marshall Rose [Rose85a].
- マーシャル・ローズ[Rose85a]によるドキュメント。
Kille [Page 7]
Kille[7ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
- A document by Mark Horton [Horton85a]. The string
encodings of chapter 3 were derived directly from this
work, as is much of chapter 4.
- マークホートン[Horton85a]のそばのドキュメント。 第3章のストリングencodingsは第4章の多くのように直接この仕事から引き出されました。
- Discussion on a number of electronic mailing lists.
- 多くのメーリング・リストにおける議論。
- Meetings in the UK and the US.
- イギリスと米国でのミーティング。
Kille [Page 8]
Kille[8ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
Chapter 2 -- Service Elements
第2章--Service Elements
RFC 822 and X.400 provide a number of services to the end user. This document describes the extent to which each service can be supported across an X.400 <-> RFC 822 gateway. The cases considered are single transfers across such a gateway, although the problems of multiple crossings are noted where appropriate.
RFC822とX.400はエンドユーザに対する多くのサービスを提供します。 このドキュメントはX.400<->RFC822ゲートウェイの向こう側に各サービスを支持できる範囲について説明します。 多系交雑の問題は適切であるところで有名ですが、考えられたケースはそのようなゲートウェイの向こう側の単一の転送です。
When a service element is described as supported, this means that when this service element is specified by a message originator for a recipient behind a gateway, that it is mapped by the gateway to provide the service implied by the element. For example, if an RFC 822 originator specifies a Subject: field, this is considered to be supported, as an X.400 recipient will get a subject indication. Support implies:
サービス要素が支持されるように説明されるとき、これは、このサービスであるときに、要素がメッセージ創始者によってゲートウェイの後ろの受取人に指定されて、それがゲートウェイによって写像されて、要素によって含意されたサービスを提供することを意味します。 例えば、RFC822であるなら、創始者はSubject:を指定します。 分野、X.400受取人が対象の指示を得るとき、これが支持されると考えられます。 サポートは以下を含意します。
- Semantic correspondence.
- 意味通信。
- No loss of information.
- 情報の損失がありません。
- Any actions required by the service element.
- どんな動作もサービス要素が必要です。
For some services, the corresponding protocol elements map well, and so the service can be fully provided. In other cases, the service cannot be provided, as there is a complete mismatch. In the remaining cases, the service can be partially fulfilled. The level of partial support is summarised.
いくつかのサービスのために、対応するプロトコル要素が井戸を写像するので、サービスを完全に提供できます。 他の場合では、完全なミスマッチがあるとき、サービスを提供できません。 残っている場合では、サービスが部分的に実現できます。 部分的なサポートのレベルについて略言します。
NOTE: It should be clear that support of service elements on
reception is not a gatewaying issue. It is assumed that all
outbound messages are fully conforming to the appropriate
standards.
以下に注意してください。 レセプションにおけるサービス要素のサポートがgatewaying問題でないことは明確であるはずです。 すべての外国行きのメッセージが適切な規格に完全に従っていると思われます。
2.1. RFC 822
2.1. RFC822
RFC 822 does not explicitly define service elements, as distinct
from protocol elements. However, all of the RFC 822 header
fields, with the exception of trace, can be regarded as
corresponding to implicit RFC 822 service elements. A mechanism
of mapping used in several cases, is to place the text of the
header into the body of the IP Message. This can usually be
regarded as partial support, as it allows the information to be
conveyed to the end user even though there is no corresponding
X.400 protocol element. Support for the various service elements
(headers) is now listed.
RFC822は明らかにサービス要素をプロトコル要素と異なると定義しません。 しかしながら、跡以外の822ヘッダーがさばくRFCのすべてを内在しているRFC822サービス要素に対応すると見なすことができます。 マッピングのメカニズムは、中で数個のケースを使用して、IP Messageのボディーにヘッダーのテキストを置くことです。 通常、これを部分的なサポートと見なすことができます、どんな対応するX.400プロトコル要素もありませんが、情報がエンドユーザに伝えられるのを許容するとき。 様々なサービス要素(ヘッダー)のサポートは現在、記載されます。
Kille [Page 9]
Kille[9ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
Date:
日付:
Supported.
支持にされる。
From:
From:
Supported. For messages where there is also a sender field,
the mapping is to "Authorising Addresses", which has subtly
different semantics to the general RFC 822 usage of From:.
支持にされる。 また、送付者分野があって、From:の一般的なRFC822用法にかすかに異なった意味論を持っている「認可アドレス」にはマッピングがあるメッセージのために。
Sender:
送付者:
Supported.
支持にされる。
Reply-To:
Reply-To
Supported.
支持にされる。
To:
To:
Supported.
支持にされる。
Cc:
Cc:
Supported.
支持にされる。
Bcc:
Bcc:
Supported.
支持にされる。
Message-Id:
メッセージイド:
Supported.
支持にされる。
In-Reply-To:
以下に対して
Supported, for a single reference in msg-id form. Other
cases are passed in the message text.
msg-イドフォームにおけるただ一つの参照のために、支持されます。 他のケースはメッセージ・テキストを流れます。
References:
参照:
Supported.
支持にされる。
Keywords:
キーワード:
Passed in the message text.
メッセージ・テキストでは、通過されます。
Kille [Page 10]
Kille[10ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
Subject:
Subject:
Supported.
支持にされる。
Comments:
コメント:
Passed in the message text.
メッセージ・テキストでは、通過されます。
Encrypted:
コード化される:
Passed in the message text. This may not be very useful.
メッセージ・テキストでは、通過されます。 これはそれほど役に立たないかもしれません。
Resent-*
*に憤慨します。
Passed in the message text. In principle, these could be
supported in a fuller manner, but this is not suggested.
メッセージ・テキストでは、通過されます。 原則として、よりふくよかな方法でこれらを支持できるでしょうが、これは示されません。
Other Fields
他の分野
In particular X-* fields, and "illegal" fields in common
usage (e.g. "Fruit-of-the-day:") are passed in the message
text.
特定のX-*がさばいて、「不法入国者」が一般的な用法でさばく(例えば、「1日に実を結ばせてください」)コネはメッセージ・テキストで通過されます。
2.2. X.400
2.2. X.400
When mapping from X.400 to RFC 822, it is not proposed to map any
elements into the body of an RFC 822 message. Rather, new RFC 822
headers are defined. It is intended that these fields will be
registered, and that co-operating RFC 822 systems may use them.
Where these new fields are used, and no system action is implied,
the service can be regarded as being almost supported. Chapter 5
describes how to map these new headers in both directions. Other
elements are provided, in part, by the gateway as they cannot be
provided by RFC 822. Some service elements are are marked N/A
(not applicable). These elements are only applicable to User
Agent / Message Transfer Agent interaction and have no end-to-end
implication. These elements do not need to be mapped by the
gateway.
X.400からRFC822まで写像するとき、それは、RFC822メッセージのボディーにどんな要素も写像するために提案されません。 むしろ、新しいRFC822ヘッダーは定義されます。 これらの分野が示されて、協力RFC822システムがそれらを使用するかもしれないことを意図します。 これらの新しい分野が使用されていて、システム動作が全く含意されないところでは、サービスをほとんど支持されると見なすことができます。 第5章はこれらの新しいヘッダーを両方の方向に写像する方法を説明します。 RFC822がそれらを提供できないようにゲートウェイは他の要素を一部提供します。 いくつかのサービス要素がそうです。N/A(適切でない)であるとマークされます。 これらの要素は、単にUserエージェント/メッセージTransferエージェント相互作用に適切であり、終わりから終わりへの意味を全く持っていません。 ゲートウェイによってこれらの要素は写像される必要はありません。
2.2.1. Message Transfer Service Elements
2.2.1. メッセージ転送サービスElements
Access Management
アクセス管理
N/A.
なし。
Kille [Page 11]
Kille[11ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
Content Type Indication
満足しているタイプ指示
Not mapped. As it can only have one value (P2), there is
little use in creating a new RFC 822 header field, unless it
was to distinguish delivery reports.
写像されません。 1つの値(P2)しか持つことができないように、新しいRFC822ヘッダーフィールドを作成することにおける使用がほとんどありません、配送レポートを区別することになっていなかったなら。
Converted Indication
変換された指示
Supported by a new RFC 822 header.
新しいRFC822ヘッダーによって支持されます。
Delivery Time Stamp Indication
配送タイムスタンプ指示
N/A.
なし。
Message Identification
メッセージ識別
Supported, by use of a new RFC 822 header. This new header
is required, as X.400 has two message-ids whereas RFC 822
has only one.
新しいRFC822ヘッダーの使用で、支持されます。 X.400に2つのメッセージイドがあるとき、この新しいヘッダーが必要ですが、RFC822には、1つしかありません。
Non-delivery Notification
非配送通知
Not supported, although in general an RFC 822 system will
return errors as IP messages. In other elements, this
pragmatic result is treated as effective support of this
service element.
RFC822システムはIPメッセージとして一般に誤りを返すでしょうが、支持されません。 他の要素では、この実践的な結果はこのサービス要素の有効なサポートとして扱われます。
Original Encoded Information Types Indication
オリジナルのコード化された情報は指示をタイプします。
Supported as a new RFC 822 header.
新しいRFC822ヘッダーとして、支持されます。
Registered Encoded Information Types
登録されたコード化された情報タイプ
N/A.
なし。
Submission Time Stamp Indication
服従タイムスタンプ指示
Supported.
支持にされる。
Alternate Recipient Allowed
許容された交互の受取人
Not supported. Any value is ignored by the gateway.
支持されません。 どんな値もゲートウェイによって無視されます。
Deferred Delivery
延期した納入
Support is optional. The framework is provided so that
messages may be held at the gateway. However, a gateway
サポートは任意です。 ゲートウェイにメッセージを保持できるように枠組みを提供します。 しかしながら、ゲートウェイ
Kille [Page 12]
Kille[12ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
following this specification does not have to do this. This
is in line with the emerging functional standards.
この仕様に従うと、これはする必要はありません。 現れている機能標準に沿ってこれがあります。
Deferred Delivery Cancellation
延期した納入キャンセル
Supported.
支持にされる。
Delivery Notification
配送通知
Supported at gateway. Thus, a notification is sent by the
gateway to the originator <2>.
ゲートウェイでは、支持されます。 したがって、ゲートウェイは創始者<2>に通知を送ります。
Disclosure of Other Recipients
他の受取人の公開
Supported by use of a new RFC 822 header.
新しいRFC822ヘッダーの使用で、支持されます。
Grade of Delivery Selection
配送選択のグレード
Supported as a new RFC 822 header. In general, this will
only be for user information in the RFC 822 world.
新しいRFC822ヘッダーとして、支持されます。 一般に、これはユーザー情報のためにRFC822世界にあるだけでしょう。
Multi-Destination Delivery
マルチの目的地配送
Supported.
支持にされる。
Prevention of Non-delivery Notification
非配送通知の防止
Not Supported, as there is no control in the RFC 822 world
(but see Non-delivery Notification).
コントロールが全くRFC822世界にないので(Non-配送Notificationを見てください)Supportedでない。
Return of Contents
コンテンツの復帰
This is normally the case, although the user has no control
(but see Non-delivery Notification).
ユーザには、コントロールが全くありませんが(Non-配送Notificationを見てください)、通常、これはそうです。
Conversion Prohibition
変換禁止
Supported. Note that in practice this support is restricted
by the nature of the gateway.
支持にされる。 実際には、このサポートがゲートウェイの自然によって制限されることに注意してください。
Explicit Conversion
明白な変換
Supported, for appropriate values (See the IPMS Typed Body
service element).
適切な値(IPMS Typed Bodyサービス要素を見る)のために、支持されます。
Kille [Page 13]
Kille[13ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
Implicit Conversion
暗黙変換
Supported, in the sense that there will be implicit
conversion to IA5 in cases where this is practical.
場合にはIA5への暗黙変換がこれが実用的であるところにあるという意味で、支持されます。
Probe
徹底的調査
Supported at the gateway (i.e. the gateway services the
probe).
ゲートウェイで支持される、(すなわち、ゲートウェイサービス、徹底的調査)
Alternate Recipient Assignment
交互の受取人課題
N/A.
なし。
Hold for Delivery
配送には、当てはまってください。
N/A.
なし。
2.2.2. Interpersonal Message Service Elements
2.2.2. 個人間のメッセージService Elements
IP-message Identification
IP-メッセージ識別
Supported.
支持にされる。
Typed Body
タイプされたボディー
Supported. IA5 is fully supported. ForwardedIPMessage is
supported, with some loss of information. A subset of TTX
is supported (see section 5 for the specification of this
subset), with some loss of information. SFD may be
supported, with some loss of information. TTX and SFD are
only supported when conversion is allowed. Other types are
not supported.
支持にされる。 IA5は完全に支持されます。 ForwardedIPMessageは情報のいくらかの損失で支持されます。 TTXの部分集合は情報のいくらかの損失でサポートされます(この部分集合の仕様に関してセクション5を見ます)。 SFDは情報のいくらかの損失で支持されるかもしれません。 変換が許されているときだけ、TTXとSFDは支持されます。 他のタイプは支持されません。
Blind Copy Recipient Indication
盲目の写し受信者指示
Supported.
支持にされる。
Non-receipt Notification
非領収書通知
Not supported.
支持されません。
Receipt Notification
領収書通知
Not supported.
支持されません。
Kille [Page 14]
Kille[14ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
Auto-forwarded Indication
自動進められた指示
Supported as new RFC 822 header.
新しいRFC822ヘッダーとして、支持されます。
Originator Indication
創始者指示
Supported.
支持にされる。
Authorising User's Indication
ユーザの指示を認可します。
Supported, although the mapping (From:) is not quite the
same.
マッピング(From:)はかなりの同じことではありませんが、支持されます。
Primary and Copy Recipients Indication
予備選挙と写し受信者指示
Supported.
支持にされる。
Expiry Date Indication
有効期限日の指示
Supported as new RFC 822 header. In general, only human
action can be expected.
新しいRFC822ヘッダーとして、支持されます。 一般に、人間の行為しか予想できません。
Cross Referencing Indication
指示に参照をつけて、交差してください。
Supported.
支持にされる。
Importance Indication
重要性指示
Supported as new RFC 822 header.
新しいRFC822ヘッダーとして、支持されます。
Obsoleting Indication
指示を時代遅れにします。
Supported as new RFC 822 header.
新しいRFC822ヘッダーとして、支持されます。
Sensitivity Indication
感度指示
Supported as new RFC 822 header.
新しいRFC822ヘッダーとして、支持されます。
Subject Indication
対象の指示
Supported.
支持にされる。
Reply Request Indication
回答要求指示
Supported as comment next to address.
コメントとして、アドレスの横で、支持されます。
Kille [Page 15]
Kille[15ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
Forwarded IP-message Indication
進められたIP-メッセージ指示
Supported, with some loss of information.
情報のいくらかの損失で、支持されます。
Body Part Encryption Indication
ボディー部分暗号化指示
Not supported.
支持されません。
Multi-part Body
複合ボディー
Supported, with some loss of information, in that the
structuring cannot be formalised in RFC 822.
情報のいくらかの損失で、RFC822で構造を正式にすることができないので、支持されます。
Kille [Page 16]
Kille[16ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
Chapter 3 -- Basic Mappings
第3章--基本のマッピング
3.1. Notation
3.1. 記法
The P1 and P2 protocols are encoded in a structured manner
according to the X.409 specifications, whereas RFC 822 is text
encoded. To define a detailed mapping, it is necessary to refer
to detailed protocol elements in each format. This is described.
P1とP2プロトコルはX.409仕様通りに構造化された方法でコード化されますが、RFC822はコード化されたテキストです。 詳細なマッピングを定義するために、各形式で詳細なプロトコル要素を示すのが必要です。 これは説明されます。
3.1.4. RFC 822
3.1.4. RFC822
Structured text is defined according to the Extended Backus
Naur Form (EBNF) defined in section 2 of RFC 822 [Crocker82a].
In the EBNF definitions used in this specification, the syntax
rules given in Appendix D of RFC 822 are assumed. When these
EBNF tokens are referred to outside an EBNF definition, they
are identified by the string "882." appended to the beginning
of the string (e.g. 822.addr-spec). Additional syntax rules,
to be used throughout this specification are defined in this
chapter.
RFC822[Crocker82a]のセクション2で定義されたExtendedバッカスナウアForm(EBNF)に従って、構造化されたテキストは定義されます。 この仕様で使用されるEBNF定義では、RFC822のAppendix Dで与えられたシンタックス・ルールは想定されます。 EBNF定義の外でこれらのEBNF象徴について言及するとき、それらはストリングの始まりまでの追加(例えば、822.addr-仕様)にされるのであるストリング「882」で特定されます。 追加構文は統治されて、この仕様中で使用されるのは本章で定義されます。
The EBNF is used in two ways.
EBNFは2つの方法で使用されます。
1. To describe components of RFC 822 messages (or of
822-P1 components). In this case, the lexical analysis
defined in section 3 of RFC 822 should be used. When
these new EBNF tokens are referred to outside an EBNF
definition, they are identified by the string "EBNF."
appended to the beginning of the string (e.g.
EBNF.bilateral-info).
1. RFC822メッセージ(または822-P1の部品について)の成分について説明するために。 この場合、RFC822のセクション3で定義された字句解析は使用されるべきです。 EBNF定義の外でこれらの新しいEBNF象徴について言及するとき、それらはストリングの始まりまでの追加(例えば、EBNF.bilateral-インフォメーション)にされるのであるストリング"EBNF"によって特定されます。
2. To describe the structure of IA5 or ASCII information
not in an RFC 822 message. In these cases, tokens will
either be self delimiting, or be delimited by self
delimiting tokens. Comments and LWSP are not used as
delimiters.
2. RFC822メッセージでないところのIA5かASCII情報の構造について説明するために。 これらの場合では、象徴は、自己の区切りである、または象徴を区切る自己によって区切られるでしょう。 コメントとLWSPはデリミタとして使用されません。
3.1.5. X.409
3.1.5. X.409
An element is referred to with the following syntax, defined in
EBNF:
要素はEBNFで定義された以下の構文で示されます:
element = protocol "." definition *( "." definition )
protocol = "P1" / "P2"
definition = identifier / context
identifier = ALPHA *< ALPHA or DIGIT or "-" >
context = "[" 1*DIGIT "]"
「要素=プロトコル」 」 定義*(「.」 定義)プロトコル=、「P1"/「P2"定義=識別子/文脈識別子=アルファ*<アルファ、ケタまたは「[「1*ケタ」]」という「-」>文脈=」
Kille [Page 17]
Kille[17ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
For example, P2.Heading.subject defines the subject element of
the P2 heading. The same syntax is also used to refer to
element values. For example,
P1.EncodedInformationTypes.[0].g3Fax refers to a value of
P1.EncodedInformationTypes.[0] .
例えば、P2.Heading.subjectはP2見出しの対象の要素を定義します。 また、同じ構文は、要素値について言及するのに使用されます。 例えば、P1.EncodedInformationTypes.[0].g3FaxはP1.EncodedInformationTypes.[0]の値について言及します。
3.2. ASCII and IA5
3.2. ASCIIとIA5
A gateway will interpret all IA5 as ASCII. Thus, they are treated
identically for the rest of this document.
ゲートウェイはASCIIとしてすべてのIA5を解釈するでしょう。 したがって、それらはこのドキュメントの残りのために同様に扱われます。
3.3. Universal Primitives
3.3. 普遍的な基関数
There is a need to convert between ASCII text, and some of the
Universal Primitive types defined in X.409 [CCITT84d]. For each
case, an EBNF syntax definition is given, for use in all of this
specification. All EBNF syntax definitions of Universal
Primitives are in lower case, whereas X.409 primitives are
referred to with the first letter in upper case. Except as noted,
all mappings are symmetrical.
ASCIIテキストと、いくらかのUniversal Primitiveの間でX.409[CCITT84d]で定義されたタイプを変換する必要があります。 各ケースにおいて、すべてにおける使用のためにEBNF構文定義にこの仕様を与えます。 小文字にはUniversal PrimitivesのすべてのEBNF構文定義がありますが、X.409基関数は大文字における最初の手紙で示されます。 注意されるのを除いて、すべてのマッピングが対称です。
3.3.1. Boolean
3.3.1. 論理演算子
Boolean is encoded as:
論理演算子は以下としてコード化されます。
boolean = "TRUE" / "FALSE"
論理演算子=「本当」/「誤っています」。
3.3.2. NumericString
3.3.2. NumericString
NumericString is encoded as:
NumericStringは以下としてコード化されます。
numericstring = *DIGIT
numericstringは*DIGITと等しいです。
3.3.3. PrintableString
3.3.3. PrintableString
PrintableString is a restricted IA5String defined as:
PrintableStringは以下と定義された制限されたIA5Stringです。
printablestring = *( ps-char / ps-delim )
printablestringは*と等しいです。(ps-炭/ps-delim)
ps-char = 1DIGIT / 1ALPHA / " " / "'" / "+" / ")"
/ "," / "-" / "." / "/" / ":" / "=" / "?"
「ps-炭が1DIGIT / 1ALPHA /と等しい、「「/、「」 '「/「+」/」) 」 /」、/「-」/」、」、' / "/" / ":" / "=" / "?"
ps-delim = "("
ps-delimが等しい、「(」
A structured subset of EBNF.printablestring is now defined.
This can be used to encode ASCII in the PrintableString
character set.
EBNF.printablestringの構造化された部分集合は現在、定義されます。 PrintableString文字の組のASCIIをコード化するのにこれを使用できます。
Kille [Page 18]
Kille[18ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
ps-encoded = *( ps-char / ps-encoded-char )
psによってコード化された=*(psは炭をps-炭/コード化していました)です。
ps-encoded-char = "(a)" ; (@)
/ "(p)" ; (%)
/ "(b)" ; (!)
/ "(q)" ; (")
/ "(u)" ; (_)
/ "(" 3DIGIT ")"
psが炭をコード化している=「(a)」。 (@) /「(p)」。 (%) /"(b)"。 (!) /"(q)"。 (") /"(u)"。 (_) 「("3DIGIT")」という/
The 822.3DIGIT in EBNF.ps-encoded-char must have range 0-127
(Decimal), and is interpreted in decimal as the corresponding
ASCII character. Special encodings are given for: at sign (@),
percent (%), exclamation mark/bang (!), double quote ("), and
underscore (_). These characters are not included in
PrintableString, but are common in RFC 822 addresses. The
abbreviations will ease specification of RFC 822 addresses from
an X.400 system.
EBNF.psが炭をコード化していたところの822.3DIGITは範囲0-127(小数)を持たなければならなくて、対応するASCII文字として小数で解釈されます。 以下のために特別なencodingsを与えます。 サイン(@)では、パーセント(%)(感嘆符/衝撃音(!))が引用文を倍にする、(「)、(_)の下線を引いてください、」 これらのキャラクタは、PrintableStringに含まれていませんが、RFC822アドレスで一般的です。 略語はX.400システムからのRFC822アドレスの仕様を緩和するでしょう。
An asymmetric mapping between PrintableString and ASCII can now
be defined <3>. To encode ASCII as PrintableString, the
EBNF.ps-encoded syntax is used, with all EBNF.ps-char AND
EBNF.ps-delim mapped directly <4>. All other 822.CHAR are
encoded as EBNF.ps-encoded-char. There are two cases of
encoding PrintableString as ASCII. If the PrintableString can
be parsed as EBNF.ps-encoded, then the previous mapping should
be reversed. If not, it should be interpreted as
EBNF.printablestring.
現在、PrintableStringとASCIIの間の非対称のマッピングは定義された<3>であるかもしれません。 PrintableStringとしてASCIIをコード化するのに、EBNF.psによってコード化された構文はすべてのEBNF.ps-炭と共に使用されました、そして、EBNF.ps-delimは直接<4>を写像しました。 EBNF.psが炭をコード化していたとして他のすべての822.CHARがコード化されます。 ASCIIとしてPrintableStringを2つのケースのコード化するのがあります。 EBNF.psによってコード化されるとしてPrintableStringを分析できるなら、前のマッピングは逆にされるべきです。 そうでなければ、それはEBNF.printablestringとして解釈されるべきです。
Some examples are now given. Note the arrows which indicate
asymmetrical mappings:
いくつかの例が現在、出されます。 非対称的なマッピングを示す矢に注意してください:
PrintableString ASCII
PrintableString ASCII
'a demo.' <-> 'a demo.'
foo(a)bar <-> foo@bar
'aデモ'<->'aデモ'foo(a)bar<-> foo@bar
(q)(u)(p)(q) <-> "_%"
(a) <-> @
(a) <- (a)
(040)a(041) -> (a)
(040)(a) -> (@
((a) <- (@
(a) (q)(u)(p)(q)<->"_%"(a)<->@(a)<(a)(040)a(041)->(a)(040)->、(@、((a) <、(@
The algorithm is designed so that it is simple to use in all
common cases, so that it is general, and so that it is
straightforward to code. It is not attempting to minimise the
number of pathological cases.
アルゴリズムはすべてのよくある例に使用するのが簡単であるように、設計されています、それが一般的であり、コード化するために簡単になるように。 それは、病理学的なケースの数を最小とならせるのを試みていません。
Kille [Page 19]
Kille[19ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
3.3.4. T.61String
3.3.4. T.61String
T.61 strings are, in general, only used for conveying human
interpreted information. Thus, the aim of a mapping should be
to render the characters appropriately in the remote character
set, rather than to maximise reversibility. The mappings
defined in the CEN/CENELEC X.400 functional standard should be
used [CEN/CENELEC/85a]. These are based on the mappings of
X.408 (sections 4.2.2 and 5.2.2).
一般に、T.61ストリングは、人間の解釈された情報を伝えるのに使用されるだけです。 したがって、マッピングの目的はリバーシブルを最大にするというよりむしろ適切にキャラクタをリモート文字の組にすることであるべきです。 CEN/CENELEC X.400機能標準で定義されたマッピングは使用されるべきです[CEN/CENELEC/85a]。 これらがX.408に関するマッピングに基づいている、(セクション4.2 .2と5.2、.2)。
3.3.5. UTCTime
3.3.5. UTCTime
Both UTCTime and the RFC 822 822.date-time syntax contain: Year
(lowest two digits), Month, Day of Month, hour, minute, second
(optional), and Timezone. 822.date-time also contains an
optional day of the week, but this is redundant. Therefore a
symmetrical mapping can be made between these constructs <5>.
The UTCTime format which specifies the timezone offset should
be used, in line with CEN/CENELEC recommendations.
UTCTimeとRFC 822 822.date-時間構文の両方が以下を含んでいます。 年(最も低い2ケタ)、Month、Monthのデー、時間、分、2(任意の)番目、およびTimezone。 また、822.日付-時間は任意の曜日を含んでいますが、これは余分です。 したがって、これらの構造物<5>の間で対称のマッピングを作ることができます。 タイムゾーンオフセットを指定するUTCTime形式はCEN/CENELEC推薦に沿って使用されるべきです。
Kille [Page 20]
Kille[20ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
Chapter 4 -- Addressing
第4章--アドレシング
Addressing is probably the trickiest problem of an X.400 <-> RFC 822 gateway. Therefore it is given a separate chapter. This chapter, as a side effect, also defines a standard textual representation of X.400 addresses.
アドレシングはたぶんX.400<->RFC822ゲートウェイの最も扱いにくい問題です。 したがって、別々の章にそれを与えます。 また、本章はX.400アドレスの標準の原文の表現を副作用と定義します。
Initially we consider an address in the (human) mail user sense of "what is typed at the mailsystem to reference a human". A basic RFC 822 address is defined by the EBNF EBNF.822-address:
初めは、私たちは「人間に参照をつけるためにmailsystemでタイプされるもの」に関する(人間)のメールユーザ意味におけるアドレスを考えます。 基本的なRFC822アドレスはEBNF EBNF.822-アドレスによって定義されます:
822-address = [ route ] addr-spec
822アドレスが[ルート]addr-仕様と等しいです。
In an 822-P1 protocol, the originator and each recipient should be considered to be defined by such a construct. In an RFC 822 header, the EBNF.822-address is encapsulated in the 822.address syntax rule, and there may also be associated comments. None of this extra information has any semantics, other than to the end user.
822-P1プロトコルでは、そのような構造物によって創始者と各受取人が定義されると考えられるべきです。 RFC822ヘッダーでは、EBNF.822-アドレスは822.address syntax規則で要約されます、そして、また、関連コメントがあるかもしれません。 このその他の情報のいずれにはも、エンドユーザ以外の少しの意味論もありません。
The basic X.400 address is defined by P1.ORName. In P1 all recipient P1.ORnames are encapsulated within P1.RecipientInfo, and in P2 all P2.ORNames <6> are encapsulated within P2.ORDescriptor.
基本的なX.400アドレスはP1.ORNameによって定義されます。 P1では、すべての受取人P1.ORnamesがP1.RecipientInfoの中で要約されます、そして、P2では、すべてのP2.ORNames<6>がP2.ORDescriptorの中で要約されます。
It can be seen that RFC 822 822.address must be mapped with P2.ORDescriptor, and that RFC 822 EBNF.822-address must be mapped with P1.ORName (originator) and P1.RecipientInfo (recipients).
P2.ORDescriptorと共にRFC 822 822.addressを写像しなければならなくて、P1.ORName(創始者)とP1.RecipientInfo(受取人)と共にRFC822EBNF.822-アドレスを写像しなければならないのを見ることができます。
This chapter is structured as follows:
本章は以下の通り構造化されます:
4.1 Introduction.
4.1序論。
4.2 A textual representation of P1.ORName. This is needed for
the later mappings, and as a side effect provides a standard
representation for O/R names.
4.2 P1.ORNameの原文の表現。 後のマッピング、副作用がO/R名の標準の表現を提供するとき、これが必要です。
4.3 Mapping between EBNF.822-address and P1.ORName
4.3 EBNF.822-アドレスとP1.ORNameの間のマッピング
4.4 The Full P1 / 822-P1 Mapping
4.4 完全なP1 / 822-P1マッピング
4.5 The Full P2 / RFC 822 Mapping
4.5 完全なP2 / RFC822マッピング
4.6 Mapping Message-IDs.
4.6 メッセージIDを写像します。
Kille [Page 21]
Kille[21ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
4.1. A textual representation of P1.ORName.
4.1. P1.ORNameの原文の表現。
P1.ORName is structured as a set of attribute value pairs. It is
clearly necessary to be able to encode this in ASCII for
gatewaying purposes. A general encoding is given here, which may
be used as a basis for a user interface, as well as for the
defined gateway mapping.
1セットの属性値が対にされるとき、P1.ORNameは構造化されます。 gatewaying目的のためのASCIIでこれをコード化できるのが明確に必要です。 一般的なコード化をここに与えます(ユーザーインタフェースの基礎として使用されるかもしれません)、よく定義されたゲートウェイマッピングのように。
4.1.1. Basic Representation
4.1.1. 基本的な表現
A series of BNF definitions of each possible attribute value
pair is given, which is given a 1:1 mapping with the X.400
encoding. The rest of the mapping then talks in terms of these
BNF components, with the mapping to X.400 encoding being
trivial.
それぞれの可能な属性値組の一連のBNF定義(1:1マッピングはX.400コード化と共に与えられている)を与えます。 次に、マッピングの残りはこれらのBNFの部品に関して話します、X.400コード化へのマッピングが些細な状態で。
attributevalue = c / admd / prmd / x121 / t-id / o / ou
/ ua-id / pn.g / pn.i / pn.s / pn.gq / dd.value
attributevalue=c/ admd / prmd / x121 / t-イド/o/ ou / ua-イド/pn.g/pn.i/pn.s/pn.gq/dd.value
c = printablestring ; P1.CountryName
admd = printablestring ; P1.AdministrationDomainName
prmd = printablestring ; P1.PrivateDomainName
x121 = numericstring ; P1.X121Address
t-id = numericstring ; P1.TerminalID
o = printablestring ; P1.OrganisationName
ou = printablestring ; P1.OrganisationalUnit
ua-id = numericstring ; P1.UniqueUAIdentifier
pn.s = printablestring ; P1.PersonalName.surName
pn.g = printablestring ; P1.PersonalName.givenName
pn.i = printablestring ; P1.PersonalName.initials
pn.gq = printablestring ; P1.PersonalName.generation
Qualifier
dd.value = printablestring ; P1.DomainDefined
Attribute.value
cはprintablestringと等しいです。 P1.CountryName admdはprintablestringと等しいです。 P1.AdministrationDomainName prmdはprintablestringと等しいです。 P1.PrivateDomainName x121はnumericstringと等しいです。 P1.X121Address t-イドはnumericstringと等しいです。 P1.TerminalID oはprintablestringと等しいです。 P1.OrganisationName ouはprintablestringと等しいです。 P1.OrganisationalUnit ua-イドはnumericstringと等しいです。 P1.UniqueUAIdentifier pn.sはprintablestringと等しいです。 P1.PersonalName.surName pn.gはprintablestringと等しいです。 P1.PersonalName.givenName pn.iはprintablestringと等しいです。 P1.PersonalName.initials pn.gqはprintablestringと等しいです。 P1.PersonalName.generation Qualifier dd.valueはprintablestringと等しいです。 P1.DomainDefined Attribute.value
In cases where an attribute can be encoded as either a
PrintableString or NumericString (Country, ADMD, PRMD) it is
assumed that the NumericString encoding will be adopted if
possible. This prevents the encoding of PrintableString where
the characters are all numbers. This restriction seems
preferable to the added complexity of a general solution.
Similarly, we can define a set of attribute types.
PrintableStringかNumericStringのどちらかとして属性をコード化できる場合(国、ADMD、PRMD)では、できれば、NumericStringコード化が採用されると思われます。 これはキャラクタがすべて数であるPrintableStringのコード化を防ぎます。 この制限は一般解の加えられた複雑さより望ましく見えます。 同様に、私たちは1セットの属性タイプを定義できます。
Kille [Page 22]
Kille[22ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
dd.type = printablestring ; P1.DomainDefinedAttribute.type
dd.typeはprintablestringと等しいです。 P1.DomainDefinedAttribute.type
standard-type =
"C" ; P1.CountryName
/ "ADMD" ; P1.AdministrationDomainName
/ "PRMD" ; P1.PrivateDomainName
/ "X121" ; P1.X121Address
/ "T-ID" ; P1.TerminalID
/ "O" ; P1.OrganisationName
/ "OU" ; P1.OrganisationalUnit
/ "UA-ID" ; P1.UniqueUAIdentifier
/ "S" ; P1.PersonalName.surName
/ "G" ; P1.PersonalName.givenName
/ "I" ; P1.PersonalName.initials
/ "GQ" ; P1.PersonalName.generationQualifier
標準体型は「C」と等しいです。 P1.CountryName/"ADMD"。 P1.AdministrationDomainName/"PRMD"。 P1.PrivateDomainName/"X121"。 P1.X121Address/「T ID」。 P1.TerminalID/「O」。 P1.OrganisationName/"OU"。 P1.OrganisationalUnit/「UA ID」。 P1.UniqueUAIdentifier/「S」。 P1.PersonalName.surName/「G」。 P1.PersonalName.givenName/「I」。 P1.PersonalName.initials/"GQ"。 P1.PersonalName.generationQualifier
standard-dd-type =
"RFC-822" ; dd.type = "RFC-822"
/ "JNT-Mail" ; dd.type = "JNT-Mail"
/ "UUCP" ; dd.type = "UUCP"
標準のddタイプは"RFC-822"と等しいです。 dd.typeは"RFC-822"/「JNTメール」と等しいです。 dd.typeは「JNT-メール」/"UUCP"と等しいです。 dd.typeは"UUCP"と等しいです。
4.1.2. Encoding of Personal Name
4.1.2. 個人名のコード化
Handling of Personal Name based purely on the
EBNF.standard-type syntax defined above is likely to be clumsy.
It seems desirable to utilise the "human" conventions for
encoding these components. A syntax is proposed here. It is
designed to cope with the common cases of O/R Name
specification where:
純粋に上で定義されたEBNF.standard-type構文に基づくパーソナルNameの取り扱いは不器用である傾向があります。 「人間」のコンベンションをこれらのコンポーネントをコード化するのに利用するのは望ましく思えます。 構文はここで提案されます。 それがO/R Name仕様のよくある例に対処するように設計されている、どこ:
1. There is no generational qualifier
1. どんな世代の資格を与える人もいません。
2. Initials contain only letters <7>.
2. イニシャルは手紙<7>だけを含んでいます。
3. Given Name does not contain full stop ("."), and is at
least two characters long.
3. 与えられたNameが終止符を含んでいない、(「」、)、少なくとも2キャラクタ長さはそうです。
4. If Surname contains full stop, then it may not be in
the first two characters, and either initials or given
name is present.
4. Surnameが終止符を含んでいるなら、最初の2つのキャラクタ、およびどちらのイニシャルにはそれがないかもしれませんか、または名は存在しています。
Kille [Page 23]
Kille[23ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
The following EBNF is defined:
以下のEBNFは定義されます:
encoded-pn = [ given "." ] *( initial "." ) surname
「コード化されたpnが等しい、[付与、」、」、]、*、(初期、」、」、)、姓
given = 2*<ps-char not including ".">
. 「包含ではなく、与えられた=2*<ps-炭」">"
initial = ALPHA
初期の=アルファー
surname = printablestring
姓=printablestring
Subject to the above restriction, this is a reversible mapping.
上の制限を条件として、これはリバーシブルのマッピングです。
For example:
例えば:
GivenName = "Marshall"
Surname = "Rose"
「マーシャル」GivenName=姓=は「上昇しました」。
Maps with "Marshall.Rose"
"Marshall.Rose"がある地図
Initials = "MT"
Surname = "Rose"
「MT」イニシャル=姓=は「上昇しました」。
Maps with "M.T.Rose"
「M.T.は上昇したこと」がある地図
GivenName = "Marshall"
Initials = "MT"
Surname = "Rose"
「MT」「マーシャル」GivenName=イニシャル=姓=は「上昇しました」。
Maps with "Marshall.M.T.Rose"
「Marshall.M.T.は上昇したこと」がある地図
Note that CCITT guidelines suggest that Initials is used to
encode ALL initials. Therefore, the proposed encoding is
"natural" when either GivenName or Initials, but not both, are
present. The case where both are present can be encoded, but
this appears to be contrived!
CCITTガイドラインが、Initialsがすべてのイニシャルをコード化するのに使用されるのを示すことに注意してください。 したがって、両方ではなく、GivenNameかInitialsのどちらかが存在しているとき、提案されたコード化は「自然です」。 両方が出席しているケースをコード化できますが、これは案出されるように見えます!
4.1.3. Two encodings of P1.ORName
4.1.3. P1.ORNameの2encodings
Given this structure, we can specify a BNF representation of an
O/R Name.
この構造を考えて、私たちはO/R NameのBNF表現を指定できます。
Kille [Page 24]
Kille[24ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
std-orname = 1*( "/" attribute "=" value ) "/"
attribute = standard-type
/ "PN"
/ standard-dd-type
/ registered-dd-type
/ "DD." std-printablestring
value = std-printablestring
registered-dd-type
= std-printablestring
std-printablestring =
= *( std-char / std-pair )
std-char = <ps-delim, and any ps-char except "/"
and "=">
std-pair = "$" ( ps-delim / ps-char )
std-orname = 1*( "/" attribute "=" value ) "/" attribute = standard-type / "PN" / standard-dd-type / registered-dd-type / "DD." std-printablestring value = std-printablestring registered-dd-type = std-printablestring std-printablestring = = *( std-char / std-pair ) std-char = <ps-delim, and any ps-char except "/" and "="> std-pair = "$" (ps-delim / ps-炭)
If the type is PN, the value is interpreted according to
EBNF.encoded-pn, and the components of P1.PersonalName derived
accordingly. If the value is registered-dd-type, if the value
is registered at the SRI NIC as an accepted Domain Defined
Attribute type, then the value should be interpreted
accordingly. This restriction maximises the syntax checking
which can be done at a gateway.
タイプがPNであるなら、EBNF.encoded-pn、およびそれに従って、引き出されたP1.PersonalNameの部品に従って、値は解釈されます。 値が受け入れられたDomain Defined AttributeタイプとしてSRI NICに示されるなら値が登録されたddタイプであるなら、値はそれに従って、解釈されるべきです。 この制限はどれがゲートウェイにできるかをチェックする構文を最大にします。
Another syntax is now defined. This is intended to be
compatible with the syntax used for 822.domains. This syntax
is not intended to be handled by users.
別の構文は現在、定義されます。 これは822.domainsに使用される構文と互換性があることを意図します。 この構文はユーザによって扱われることを意図しません。
dmn-orname = dmn-part *( "." dmn-part )
dmn-part = attribute "$" value
attribute = standard-type
/ "~" dmn-printablestring
value = dmn-printablestring
dmn-printablestring =
= *( dmn-char / dmn-pair )
dmn-char = <ps-delim, and any ps-char except ".">
dmn-pair = "\."
「属性「$」値属性=標準体型/「~」dmn-printablestring dmn-orname=dmn-部分*(「.」 dmn-部分)dmn-部分=価値=dmn-printablestring dmn-printablestringは=*<(dmn dmn-炭/対にします)のdmn-炭=ps-delim、および」 . 「>dmn-組=」\以外のどんなps-焦げとも等しいです。」
For example: C$US.ADMD$ATT.~ROLE$Big\.Chief
例えば: C$US.ADMD$ATT~役割の$大きい\.Chief
Kille [Page 25]
Kille[25ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
4.2. Mapping between EBNF.822-address and P1.ORName
4.2. EBNF.822-アドレスとP1.ORNameの間のマッピング
Ideally, the mapping specified would be entirely symmetrical and
global, to enable addresses to be referred to transparently in the
remote system, with the choice of gateway being left to the
Message Transfer Service. There are two fundamental reasons why
this is not possible:
理想的に、指定されたマッピングは、アドレスがリモートシステムで透明に参照されるのを可能にするために完全に対称であってグローバルでしょう、ゲートウェイの選択がMessage Transfer Serviceに残されている状態で。 これが可能でない2つの基本的な理由があります:
1. The syntaxes are sufficiently different to make this
awkward.
1. 構文はこれを無器用にすることができるくらい異なっています。
2. In the general case, there would not be the necessary
administrative co-operation between the X.400 and RFC 822
worlds, which would be needed for this to work.
2. 一般的な場合には、X.400とRFC822の世界の間には、必要な管理協力がないでしょう。世界が、これが働くのに必要でしょう。
Therefore, an asymmetrical mapping is defined.
したがって、非対称的なマッピングは定義されます。
4.2.1. X.400 encoded in RFC 822
4.2.1. RFC822でコード化されたX.400
The std-orname syntax is used to encode O/R Name information
in the 822.local-part of EBNF.822-address. Further O/R Name
information may be associated with the 822.domain component.
This cannot be used in the general case, basically due to
character set problems, and lack of order in X.400 O/R Names.
The only way to encode the full PrintableString character set
in a domain is by use of the 822.domain-ref syntax. This is
likely to cause problems on many systems. The effective
character set of domains is in practice reduced from the
RFC 822 set, by restrictions imposed by domain conventions and
policy.
std-orname構文は、EBNF.822-アドレスの822.local-部分でO/R Name情報をコード化するのに使用されます。 一層のO/R Name情報は822.domainの部品に関連しているかもしれません。 一般的なケース、基本的に文字の組問題への支払われるべきもの、およびX.400O/R Namesのオーダーの不足にこれを使用できません。 ドメインで完全なPrintableString文字の組をコード化する唯一の方法は822.domain-審判構文を使用します。 これは多くのシステムの上で問題を起こしそうです。ドメインの有効な文字の組が実際にはRFC822セットから減少するあります、ドメインコンベンションと方針で課された制限で。
A generic 822.address consists of a 822.local-part and a
sequence of 822.domains (e.g.
<@domain1,@domain2:user@domain3>). All except the 822.domain
associated with the 822.local-part (domain3 in this case)
should be considered to specify routing within the RFC 822
world, and will not be interpreted by the gateway (although
they may have identified the gateway from within the RFC 822
world). The 822.domain associated with the 822.local-part may
also identify the gateway from within the RFC 822 world. This
final 822.domain may be used to determine some number of O/R
Name attributes. The following O/R Name attributes are
considered as a hierarchy, and may be specified by the domain.
They are (in order of hierarchy):
一般的な822.addressが822.local-部分と822.domainsの系列から成る、(@domain2: e.g. <@domain1 、 user@domain3 、gt;、) 822.local-部分(この場合、domain3)に関連している822.domain以外のすべてが、RFC822世界の中でルーティングを指定すると考えられるべきであり、ゲートウェイによって解釈されないでしょう(彼らはRFC822世界からゲートウェイを特定したかもしれませんが)。 また、822.local-部分に関連している822.domainはRFC822世界からゲートウェイを特定するかもしれません。 この最終的な822.domainは、何らかの数のO/R Name属性を決定するのに使用されるかもしれません。 以下のO/R Name属性は、階層構造であるとみなされて、ドメインによって指定されるかもしれません。 それらはこと(階層構造の順に)です:
Country, ADMD, PRMD, Organisation, Organisational Unit
国、ADMD、PRMD、機構、Organisationalユニット
Kille [Page 26]
Kille[26ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
There may be multiple Organisational Units.
複数のOrganisational Unitsがあるかもしれません。
Associations may be defined between domain specifications, and
some set of attributes. This association proceeds
hierarchically: i.e. if a domain implies ADMD, it also implies
country. If one of the hierarchical components is omitted from
an X.400 structure, this information can be associated with the
corresponding domain (e.g. a domain can be mapped onto a
Country/ADMD/Organisation tuple). Subdomains under this are
associated according to the O/R Name hierarchy. For example:
協会はドメイン仕様と、何らかのセットの属性の間で定義されるかもしれません。 この協会は階層的で続きます: また、すなわち、ドメインがADMDを含意するなら、それは国を含意します。 階層的なコンポーネントの1つがX.400構造から省略されるなら、この情報を対応するドメインに関連づけることができます(Country/ADMD/機構tupleに例えばドメインを写像できます)。 O/R Name階層構造に従って、これの下のサブドメインは関連しています。 例えば:
=> "AC.UK" might be associated with
C="234", ADMD="BT", PRMD="DES"
=>"AC.UK"はC=「234」、ADMD=「BT」PRMD=「デス」に関連しているかもしれません。
then domain "R-D.Salford.AC.UK" maps with
C="234", ADMD="BT", PRMD="DES", O="Salford", OU="R-D"
そして、「R-D.Salford.AC.UK」というPRMD=「DES」、C=「234」、ADMD=「BT」O=「ソルフォード」OUがあるドメイン地図は"R-D"と等しいです。
There are two basic reasons why a domain/attribute mapping
might be maintained, as opposed to using simply subdomains:
単にサブドメインを使用することと対照的にドメイン/属性マッピングが維持されるかもしれない2つの根本的な理由があります:
1. As a shorthand to avoid redundant X.400 information.
In particular, there will often be only one ADMD per
country, and so it does not need to be given
explicitly.
1. 余分なX.400情報を避ける速記として。 特に、1国あたり1ADMDしかしばしばないので、それによって明らかに与えられる必要はありません。
2. To deal with cases where attribute values do not fit
the syntax:
2. 属性値が構文に合わないケースに対処するために:
domain-syntax = ALPHA [ *alphanumhyphen alphanum ]
alphanum = <ALPHA or DIGIT>
alphanumhyphen = <ALPHA or DIGIT or HYPHEN>
ドメイン構文=アルファー[*alphanumhyphen alphanum]alphanumが<アルファーと等しいです、またはDIGIT>alphanumhyphenは<アルファー、DIGITまたはHYPHEN>と等しいです。
Although RFC 822 allows for a more general syntax, this
restriced syntax is chosen as it is the one chosen by the
various domain service administrations.
RFC822は、より一般的な構文を考慮しますが、このrestriced構文は、それが様々なドメインサービス運営によって選ばれたものであるので、選ばれています。
This provides a general aliasing mechanism.
これは一般的なエイリアシングメカニズムを提供します。
This set of mappings need only be known by the gateways
relaying between the RFC 822 world, and the O/R Name namespace
associated with the mapping in question. However, it is
desirable (for the optimal mapping of third party addresses)
for all gateways to know these mappings. A format for the
exchange of this information is defined in Appendix F.
このセットのマッピングは関連しているマッピングがはっきりしていなかった状態でRFC822世界と、O/R Name名前空間の間でリレーされるゲートウェイによって知られているだけでよいです。 しかしながら、すべてのゲートウェイに、これらのマッピングを知るのは望ましいです(第三者アドレスの最適のマッピングのための)。 この情報の交換のための書式はAppendix Fで定義されます。
From the standpoint of the RFC 822 Message Transfer System, the
domain specification is simply used to route the message in the
RFC822Message Transfer Systemの見地から、ドメイン仕様は、メッセージを中に発送するのに単に使用されます。
Kille [Page 27]
Kille[27ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
standard manner. The standard domain mechanisms are used to
identify gateways, and are used to select appropriate gateways
for the corresponding O/R Name namespace. In most cases, this
will be done by registering the higher levels, and assuming
that the gateway can handle the lower levels.
標準の方法。 標準のドメインメカニズムは、ゲートウェイを特定するのに使用されて、対応するO/R Name名前空間のために適切なゲートウェイを選択するのに使用されます。 多くの場合、より高いレベルを示して、ゲートウェイが下のレベルを扱うことができるのに就くことによって、これをするでしょう。
As a further mechanism to simplify the encoding of common
cases, where the only attributes to be encoded on the LHS are
Personal Name attributes which comply with the restrictions of
4.2.2, the 822.local-part may be encoded as EBNF.encoded-pn.
よくある例のコード化を簡素化するさらなるメカニズムとして、.2、822.local-部分はEBNF.encoded-pnとしてコード化されるかもしれません。そこでは、唯一のLHSでコード化されるべき属性が4.2の制限に従うパーソナルName属性です。
An example encoding is:
例のコード化は以下の通りです。
/PN=J.Linnimouth/GQ=5/@Marketing.Xerox.COM
J./PN=Linnimouth/GQは 5/@Marketing.Xerox.COM と等しいです。
encodes the P1.ORName consisting of
P1.ORNameの成ることをコード化します。
P1.CountryName = "US"
P1.AdministrationDomainName = "ATT"
P1.OrganisationName = "Xerox"
P1.OrganisationalUnit = "Marketing"
P1.PersonalName.surName = "Linnimouth"
P1.PersonalName.initials = "J"
P1.PersonalName.GenerationQualifier = "5"
"Linnimouth"「マーケティング」「ゼロックス」「ATT」「米国」P1.CountryName=P1.AdministrationDomainName=P1.OrganisationName=P1.OrganisationalUnit=P1.PersonalName.surName=P1.PersonalName.initialsは「J」P1.PersonalName.GenerationQualifierと= 「5インチ」等しいです。
If the GenerationQualifier was not present, the encoding
J.Linnimouth@Marketing.Xerox.COM could be used.
GenerationQualifierが存在していないなら、コード化している J.Linnimouth@Marketing.Xerox.COM を使用できるでしょうに。
Note that in this example, the first three attributes are
determined by the domain Xerox.COM. The OrganisationalUnit is
determined systematically.
最初の3つの属性がドメインXerox.COMのそばでこの例では、決定していることに注意してください。 OrganisationalUnitは系統的に断固としています。
There has been an implicit assumption that an RFC 822 domain is
either X.400 or RFC 822. This is pragmatic, but undesirable,
as the namespace should be structured on a logical basis which
does not necessarily correspond to the choice of Message
Transfer protocols. The restriction can be lifted, provided
that the nameservice deals with multiple message transfer
protocols. This can happen in a straightforward manner for the
UK NRS, as explained in [Kille86a]. It could also be achieved
with the DARPA Domain Nameserver scheme by use of the WKS
mechanism.
RFC822ドメインがX.400かRFC822のどちらかであるという暗黙の仮定がありました。 これは、実践的ですが、望ましくありません、名前空間が必ずMessage Transferプロトコルの選択と食い違っている論理的ベースで構造化されるべきであるとき。 nameserviceが複数のメッセージ転送プロトコルに対処すれば、制限について提案できます。 これは[Kille86a]で説明されるようにUK NRSに、正直な態度で起こることができます。 また、DARPA Domain Nameserver計画でWKSメカニズムの使用でそれを達成できるでしょう。
Kille [Page 28]
Kille[28ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
4.2.2. RFC 822 Encoded in X.400
4.2.2. X.400でコード化されたRFC822
In some cases, the encoding defined above may be reversed, to
give a "natural" encoding of genuine RFC 822 addresses. This
depends largely on the allocation of appropriate management
domains.
いくつかの場合、上で定義されたコード化は、本物のRFC822アドレスの「自然な」コード化を与えるために逆にされるかもしれません。 これは主に適切な管理ドメインの配分によります。
The general case is mapped by use of domain defined attributes.
Three are defined, according to the full environment used to
interpret the RFC 822 information.
一般的なケースはドメインの定義された属性の使用で写像されます。 RFC822情報を解釈するのに使用される完全な環境に従って、3は定義されます。
1. Domain defined type "RFC-822". This string is to be
interpreted in the context of RFC 822, and RFC 920
[Crocker82a,Postel84a].
1. ドメインはタイプ"RFC-822"を定義しました。 このストリングはRFC822、およびRFC920[Crocker82a、Postel84a]の文脈で解釈されることです。
2. Domain defined type "JNT-Mail". This string is to be
interpreted in the context of the JNT Mail protocol,
and the NRS [Kille84a,Larmouth83a].
2. ドメインはタイプ「JNT-メール」を定義しました。 このストリングはJNTメールプロトコルの文脈、およびNRS[Kille84a、Larmouth83a]で解釈されることです。
3. Domain defined type "UUCP". This is interpreted
according to the constraints of the UUCP world
[Horton86a].
3. ドメインはタイプ"UUCP"を定義しました。 UUCP世界[Horton86a]の規制に従って、これは解釈されます。
These three are values currently known to be of use. Further
recognised values may be defined. These will be maintained in
a list at the SRI Network Information Center.
これらの3は現在役に立つのが知られている値です。 さらなる認識された値は定義されるかもしれません。 これらはSRI Networkインフォメーション・センターでリストで維持されるでしょう。
Other O/R Name attributes will be used to identify a context in
which the O/R Name will be interpreted. This might be a
Management Domain, or some part of a Management Domain which
identifies a gateway MTA. For example:
他のO/R Name属性は、O/R Nameが解釈される文脈を特定するのに使用されるでしょう。 これは、Management Domain、またはゲートウェイMTAを特定するManagement Domainの何らかの部分であるかもしれません。 例えば:
1)
1)
C = "GB"
ADMD = "BT"
PRMD = "AC"
"JNT-Mail" = "Jimmy(a)UK.CO.BT-RESEARCH-LABS"
「BT」「GB」C=ADMD=PRMDは「西暦」「JNT-メール」=「Jimmy(a)UK.CO.BT研究研究室」と等しいです。
2)
2)
C = "US"
ADMD = "Telemail"
PRMD = "San Fransisco"
O = "U Cal"
OU = "Berkeley"
"RFC-822" = "postel(a)usc-isib.arpa"
「バークレー」「Uカル」「サンフランシスコ」"Telemail"「米国」C=ADMD=PRMD=O=OU="RFC-822"は"postel(a)usc-isib.arpa"と等しいです。
Kille [Page 29]
Kille[29ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
Note in each case the PrintableString encoding of "@" as "(a)".
In the first example, the "JNT-Mail" domain defined attribute
is interpreted everywhere within the (Administrative or
Private) Management Domain. In the second example, further
attributes are needed within the Management Domain to identify
a gateway. Thus, this scheme can be used with varying levels
of Management Domain co-operation.
「(a)」としてその都度"@"のPrintableStringコード化に注意してください。 「JNT-メール」ドメインの定義された属性が中でいたる所で最初の例では、解釈される、(管理、兵士) または、管理Domain。 2番目の例では、さらなる属性が、ゲートウェイを特定するのにManagement Domainの中で必要です。 したがって、異なったレベルのManagement Domain協力と共にこの計画を使用できます。
4.2.3. RFC 822 -> X.400
4.2.3. RFC822->X.400
There are two basic cases:
2つの基本的なケースがあります:
1. X.400 addresses encoded in RFC 822. This will also
include RFC 822 addresses which are given reversible
encodings.
1. RFC822でコード化されたX.400アドレス。 また、これはリバーシブルのencodingsが与えられているRFC822アドレスを含むでしょう。
2. "Genuine" RFC 822 addresses.
2. 「本物」のRFC822アドレス。
The mapping should proceed as follows, by first assuming case
1).
マッピングは、以下の通り最初にケース1)を仮定することによって、続くべきです。
STAGE 1.
1を上演してください。
1. If the 822-address is not of the form:
1. 822アドレスがフォームのものでないなら:
local-part "@" domain
地方の部分"@"ドメイン
go to stage 2.
ステージ2まで行ってください。
2. Attempt to parse domain as:
2. 以下としてドメインを分析するのを試みてください。
*( domain-syntax "." ) known-domain
*「(ドメイン構文、」、」、) 知られているドメイン
Where known-domain is the longest possible match in a
list of gatewayed domains. If this fails, and the domain
does not explicitly identify the local gateway, go to
stage 2. If it succeeds, allocate the attributes
associated with EBNF.known-domain, and systematically
allocate the attributes implied by each
EBNF.domain-syntax component.
知られているドメインがgatewayedドメインのリストで可能な限り長いマッチであるところ。 これが失敗して、ドメインが明らかに地方のゲートウェイを特定しないなら、ステージ2まで行ってください。 成功するなら、EBNF.known-ドメインに関連している属性を割り当ててください、そして、系統的にそれぞれのEBNF.domain-構文コンポーネントによって含意された属性を割り当ててください。
3. Map 822.local-part to ASCII, according to the
definition of Appendix A. This step should be applied:
3. 822.local-部分をASCIIに写像してください、そして、Appendix A.Thisステップの定義に従って、適用されるべきであってください:
A. If the source network cannot support
822.quoted-string (as discussed in Appendix A).
A. ソースネットワークが822.quoted-stringを支持できないなら(Appendix Aで議論するように)。
Kille [Page 30]
Kille[30ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
B. If the address is an 822-P1 recipient.
B. アドレスが822-P1受取人であるなら。
This mapping is always applied in case B, as it
increases the functionality of the gateway, and does
not imply any loss of generality. Mapping case B
allows sites which cannot generate 822.quoted-string
to address recipients the gateway, without the gateway
having to know this explicitly. There is no loss of
functionality, as the quoting character of Appendix A
(#) is not in PrintableString. This seems desirable.
It should not be applied in to other addresses, as a
third party RFC#822 address containing the sequence
EBNF.atom-encoded (as defined in Appendix A) would be
transformed asymmetrically.
このマッピングは場合Bでいつも適用されます、ゲートウェイの機能性を増加させて、少しの一般性の喪失も含意しないとき。 ケースBを写像すると、ゲートウェイなしで持っているゲートウェイは、明らかにこれを知るために受取人に演説するために822.quoted-stringを発生させることができないサイトに許容されます。 Appendix A(#)の引用しているキャラクタがPrintableStringにないとき、機能性の損失が全くありません。 これは望ましく思えます。 それでは、他のアドレスに適用するべきでなくて、第三者RFCとして、系列がEBNF.atomコード化した(Appendix Aで定義されるように)#822アドレス含有を非対称的に変えるでしょう。
4. Map the result of 3) to EBNF.ps-encoded according to
section 3.
4. EBNF.psによってコード化されるのにセクション3によると、3の)結果を写像してください。
5. Parse the result of 4) according to the EBNF
EBNF.std-orname. If this parse fails, parse the result
of 4) according to the EBNF EBNF.encoded-pn. If this
also fails, go to stage 2. Otherwise, the result is a
set of type/value pairs.
5. EBNF EBNF.std-ornameに従って、4の)結果を分析してください。 これであるなら、やり損ないを分析してください、そして、EBNF EBNF.encoded-pnに従って、4の)結果を分析してください。 また、これが失敗するなら、ステージ2まで行ってください。 さもなければ、結果は1セットのタイプ/値の組です。
6. Associate the EBNF.attribute-value syntax (determined
from the identified type) with each value, and check
that it conforms. If not, go to stage 2.
6. EBNF.attribute-value構文(特定されたタイプから断固とした)を各値に関連づけてください、そして、それが従うのをチェックしてください。そうでなければ、ステージ2まで行ってください。
7. Ensure that the set of attributes conforms both to the
X.411 P1.ORName specification and to the restrictions
on this set given in X.400. If not go to stage 2.
7. 属性のセットがX.400で与えられているこのセットでX.411 P1.ORName仕様と、そして、制限に一致しているのを確実にしてください。 そうでなければ、ステージ2まで行ってください。
8. Build the O/R Name from this information.
8. この情報からO/R Nameを造ってください。
STAGE 2.
2を上演してください。
This will only be reached if the RFC 822 EBNF.822-address is
not a valid X.400 encoding. If the address is an 822-P1
recipient address, it must be rejected, as there is a need to
interpret such an address in X.400. For the 822-P1 return
address, and any addresses in the RFC 822 header, they should
now be encoded as RFC 822 addresses in an X.400 O/R Name:
これにRFC822EBNF.822-アドレスが有効なX.400コード化でない場合にだけ達するでしょう。 アドレスが822-P1受取人アドレスであるなら、それを拒絶しなければなりません、そのようなアドレスを解釈する必要がX.400にあるとき。 822-P1返送先、およびRFC822ヘッダーのどんなアドレスにおいても、RFC822がX.400O/RにNameを記述するとき、それらは現在、コード化されるべきです:
1. Convert the EBNF.822-address to PrintableString, as
specified in chapter 3.
1. 第3章で指定されるようにEBNF.822-アドレスをPrintableStringに変換してください。
2. The domain defined attribute ("RFC-822", "JNT-Mail" or
2. またはドメインが属性を定義した、("RFC-822"、「JNT-メール」。
Kille [Page 31]
Kille[31ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
"UUCP") appropriate to the gateway should be selected,
and its value set.
ゲートウェイに適切な"UUCP"は選択されるべきでした、そして、値はセットしました。
3. Build the rest of the O/R Name in the local Management
Domain agreed manner, so that the O/R Name will receive
a correct global interpretation.
3. 地方のManagement DomainのO/R Nameの残りに同意された方法を築き上げてください、O/R Nameが正しいグローバルな解釈を受けるように。
4.2.4. X.400 -> RFC 822
4.2.4. X.400->RFC822
There are two basic cases:
2つの基本的なケースがあります:
1. RFC 822 addresses encoded in X.400.
1. X.400でコード化されたRFC822アドレス。
2. "Genuine" X.400 addresses. This may include
symmetrically encoded RFC 822 addresses.
2. 「本物」のX.400アドレス。 これは対称的にコード化されたRFC822アドレスを含むかもしれません。
When a P1 Recipient O/R Name is interpreted, gatewaying will be
selected if there a single special domain defined attribute
present ("RFC-822", "JNT-Mail" or "UUCP"). In this case, use
mapping A. For other O/R Names which
P1 Recipient O/R Nameが解釈されるとき、ただ一つの特別なドメインがそこで属性プレゼント("RFC-822"、「JNT-メール」または"UUCP")を定義したなら、gatewayingは選択されるでしょう。 この場合マッピングA.For他のO/R Namesを使用してください、どれ
1. Contain the special attribute.
1. 特別な属性を含んでください。
AND
AND
2. Identify the local gateway with the other attributes.
2. 地方のゲートウェイを他の属性と同一視してください。
Use mapping A. In other cases, use mapping B.
マッピングA.In他のケース、Bを写像する使用を使用してください。
Mapping A
Aを写像します。
1. Map the domain defined attribute value to ASCII, as
defined in chapter 3.
1. 第3章で定義されるようにドメインの定義された属性値をASCIIに写像してください。
2. Where appropriate (P1 recipients), interpret the string
according to the semantics implied by the domain
defined attribute.
2. 適切である(P1受取人)ところでは、ドメインの定義された属性によって含意された意味論に従って、ストリングを解釈してください。
Mapping B.
Bを写像します。
This will be used for X.400 addresses which do not use the
explicit RFC 822 encoding.
これは明白なRFC822コード化を使用しないX.400アドレスに使用されるでしょう。
1. Noting the hierarchy specified in 4.3.1, determine the
maximum set of attributes which have an associated
domain specification. If no match is found, allocate
1. 階層構造が指定したことに注意する、4.3、.1、関連ドメイン仕様を持っている最大のセットの属性を決定してください。 マッチが全く見つけられないなら割り当て
Kille [Page 32]
Kille[32ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
the domain as the domain specification of the local
gateway, and go to step 4.
地方のゲートウェイ、および4を踏む碁のドメイン仕様としてのドメイン。
2. Following the 4.3.1 hierarchy, if each successive
component exists, and conforms to the syntax
EBNF.domain-syntax (as defined in 4.3.1), allocate the
next subdomain.
2. それぞれの連続したコンポーネントが構文EBNF.domain-構文に存在していて、一致しているなら4.3.1階層構造に従う、(中で定義される、4.3、.1、)、次のサブドメインを割り当ててください。
3. If the remaining components are personal-name
components, conforming to the restrictions of 4.2.2,
then EBNF.encoded-pn should be derived to form
822.local-part. In other cases the remaining
components should simply be encoded as a 822.local-part
using the EBNF.std-orname syntax. Where registered
domain defined types exist, the DD. syntax should not
be used.
3. 残っているコンポーネントが.2、当時のEBNF.encoded-pnを4.2の制限に従わせるコンポーネントがそうするべきである個人名であるなら引き出されて、822.local-部分を形成してください。 他の場合では、残っているコンポーネントは、822.local-部分として単にEBNF.std-orname構文を使用することでコード化されるべきです。 . 登録されたドメイン定義されたタイプが存在していて、DDが構文であるところでは、使用するべきではありません。
4. If this step is reached for an 822-P1 recipient, then
the address is invalid. For other addresses, if the
derived 822.local-part can only be encoded by use of
822.quoted-string, the gateway may optionally use the
ASCII to 822.local-part mapping defined in Appendix A,
dependent on the mail protocols of the networks being
relayed to. Use of this encoding is discouraged.
4. このステップに822-P1受取人のために達しているなら、アドレスは無効です。 派生している822.local-部分が他のアドレスそうすることができるだけであるなら、822.quoted-stringの使用でコード化されてください、ゲートウェイ。任意に、リレーされるネットワークのメールプロトコルに依存するAppendix Aで定義された822.local-部分マッピングへのASCIIを使用するかもしれません。 このコード化の使用はお勧めできないです。
4.3. Repeated Mappings
4.3. 繰り返されたマッピング
The mappings defined are symmetrical across a single gateway,
except in certain pathological cases (see chapter 3). However, it
is always possible to specify any valid address across a gateway.
This symmetry is particularly useful in cases of (mail exploder
type) distribution list expansion. For example, an X.400 user
sends to a list on an RFC 822 system which he belongs to. The
received message will have the originator and any 3rd party X.400
O/R names in correct format (rather than doubly encoded). In
cases (X.400 or RFC 822) where there is common agreement on
gateway identification, then this will apply to multiple gateways.
ある病理学的なケースを除いて、定義されたマッピングは1門の向こう側に対称です(第3章を見てください)。 しかしながら、ゲートウェイの向こう側にどんな有効なアドレスも指定するのはいつも可能です。 この対称は(メール発破器タイプ)発送先リスト拡大の場合で特に役に立ちます。 例えば、X.400ユーザは彼が属すRFC822システムの上のリストに発信します。 受信されたメッセージは正しい形式(二倍コード化されているよりむしろ)で創始者とどんな第3パーティーX.400O/R名も持つでしょう。 そして、ゲートウェイ識別の一般的な協定がある場合(X.400かRFC822)では、これは複数のゲートウェイに適用されるでしょう。
However, the syntax may be used to source route.
しかしながら、構文は送信元経路に使用されるかもしれません。
For example: X.400 -> RFC 822 -> X.400
例えば: X.400->RFC822->X.400
C = "UK"
ADMD = "BT"
PRMD = "AC"
"JNT-Mail" = "/PN=Duval/DD.Title=Manager/(a)FR.PTT.Inria"
「C=「イギリス」 ADMD=「BT」PRMD=「西暦」「JNT-メール」=」/PN=デュバル/DD.Titleはマネージャ/(a)FR.PTT.Inriaと等しいです」
Kille [Page 33]
Kille[33ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
This will be sent to an arbitrary UK Academic Community gateway
by X.400. Then by JNT Mail to another gateway determined by
the domain FR.PTT.Inria. This will then derive the X.400 O/R
Name:
これはX.400によって任意のイギリスのAcademic Communityゲートウェイに送られるでしょう。 そして、ドメインFR.PTT.Inriaのそばで断固としたもう1つの門へのJNTメールで。 次に、これはX.400O/R Nameを引き出すでしょう:
C = "FR"
ADMD = "PTT"
PRMD = "Inria"
PN.S = "Duval"
"Title" = "Manager"
「デュバル」という"Inria"「PTT」「フラン」C=ADMD=PRMD=PN.S=「タイトル」は「マネージャ」と等しいです。
Similarly: RFC 822 -> X.400 -> RFC 822
同様に: RFC822->X.400->RFC822
"/C=UK/ADMD=BT/PRMD=AC/RFC-822=jj(a)seismo.css.gov/"
@monet.berkeley.edu
@monet「/C=イギリス/ADMDはBT/PRMD=AC/RFC-822=jj(a)seismo.css.gov/と等しく」.berkeley.edu
/C=UK/ADMD=BT/PRMD=AC/RFC-822=jj#l#a#r#seismo.css.gov/
@monet.berkeley.edu
イギリス/ADMD=BT/PRMD=西暦/RFC-822=jj#/C=l#は#r#seismo.css.gov/@monet.berkeley.eduです。
The second case uses the Appendix A encoding to avoid
822.quoted-text. This will be sent to monet.berkeley.edu by
RFC 822, then to the AC PRMD by X.400, and then to
jj@seismo.css.gov by RFC 822.
2番目のこの件は、822.quoted-テキストを避けるのにAppendix Aコード化を使用します。 これはRFC822によってmonet.berkeley.eduに送られるでしょう、そして、X.400と、そして、RFC822による jj@seismo.css.gov へのAC PRMDに。
4.4. The full P1 / 822-P1 mapping
4.4. 完全なP1 / 822-P1マッピング
There are two basic mappings at the P1 level:
2つの基本のマッピングがP1レベルにあります:
1. 822-P1 return address <-> P1.UMPDUEnvelope.originator
1. 822-P1返送先<->P1.UMPDUEnvelope.originator
2. 822-P1 recipient <-> P1.RecipientInfo
2. 822-P1受取人<->P1.RecipientInfo
822-P1 recipients and return addresses are encoded as
EBNF.822-address. As P1.UMPDUEnvelope.originator is encoded as
P1.ORName, mapping 1) has already been specified.
P1.RecipientInfo contains a P1.ORName and additional information.
The handling of this additional information is now specified.
822-P1受取人と返送先はEBNF.822-アドレスとしてコード化されます。 P1.UMPDUEnvelope.originatorがP1.ORNameとしてコード化されるとき、1を)写像するのは既に指定されました。 P1.RecipientInfoはP1.ORNameと追加情報を含んでいます。 この追加情報の取り扱いは現在、指定されます。
4.4.1. RFC 822 -> X.400
4.4.1. RFC822->X.400
The following default settings should be made for each
component of P1.RecipientInfo.
以下の既定の設定はP1.RecipientInfoの各部品のために作られているべきです。
P1.ExtensionIdentifier
P1.ExtensionIdentifier
This can be set systematically by the X.400 system.
X.400システムは系統的にこれを設定できます。
Kille [Page 34]
Kille[34ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
P1.RecipientInfo.perRecipientFlag
P1.RecipientInfo.perRecipientFlag
Responsibility Flag should be set. Report Request should
be set according to content return policy, as discussed
in section 5.3. User Report Request should be set to
Basic.
責任Flagは用意ができるべきです。 満足している返品条件によると、レポートRequestはセクション5.3で議論するように用意ができるべきです。 ユーザReport RequestはBasicに用意ができるべきです。
P1.ExplicitConversion
P1.ExplicitConversion
This optional component should be omitted.
この任意のコンポーネントは省略されるべきです。
4.4.2. X.400 -> RFC 822
4.4.2. X.400->RFC822
The mapping only takes place in cases where
P1.RecipientInfo.perRecipientFlag Responsibility Flag is set.
The following treatment should be given to the other
P1.RecipientInfo components.
マッピングはP1.RecipientInfo.perRecipientFlag Responsibility Flagが用意ができている場合で行われるだけです。 他のP1.RecipientInfoの部品に以下の処理を与えるべきです。
P1.ExtensionIdentifier
P1.ExtensionIdentifier
Not used.
使用されません。
P1.RecipientInfo.perRecipientFlag
P1.RecipientInfo.perRecipientFlag
If ReportRequest is Confirmed or Audit-and-Confirmed then
a delivery report indicating success should be sent by
the gateway. This report should use each
P1.ReportedRecipientInfo.SupplementaryInformation to
indicate the identity of the gateway, and the nature of
the report (i.e. only as far as the gateway). Failures
will be handled by returning RFC 822 messages, and so
User Report Request set to No report is ignored.
ReportRequestがConfirmedかAuditの、そして、確認された当時のa配送であるなら、成功がゲートウェイによって送られるべきであるのを示すと報告してください。 このレポートは、ゲートウェイのアイデンティティ、およびレポートの本質(すなわち、ゲートウェイと同じくらい遠くにだけ)を示すのに各P1.ReportedRecipientInfo.SupplementaryInformationを使用するべきです。 失敗が戻っているRFC822メッセージによって扱われるので、レポートでないのに用意ができているUser Report Requestは無視されます。
P1.ExplicitConversion
P1.ExplicitConversion
If present, the O/R name should be rejected, unless the
requested conversion can be achieved. None of the
currently recognised values of this parameter are
appropriate to a gateway using this specification.
存在していて、要求された変換を達成できないなら、O/R名は拒絶されるべきです。 このパラメタの現在認識された値のいずれもこの仕様を使用するのにおいてゲートウェイに適切ではありません。
Kille [Page 35]
Kille[35ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
4.5. The full P2 / RFC 822 mapping
4.5. 完全なP2 / RFC822マッピング
All RFC 822 addresses are assumed to use the 822.mailbox syntax.
This should include all 822.comments associated with the lexical
tokens of the 822.mailbox. All P2.ORNames are encoded within the
syntax P2.ORDescriptor, or P2.Recipient (or within Message IDs).
An asymmetrical mapping is defined between these components.
すべてのRFC822アドレスが822.mailbox構文を使用すると思われます。 これは822.mailboxの字句に関連しているすべての822.commentsを含むべきです。 すべてのP2.ORNamesが構文のP2.ORDescriptor、またはP2.Recipient(またはMessage IDの中で)の中でコード化されます。 非対称的なマッピングはこれらのコンポーネントの間で定義されます。
4.5.1. RFC 822 -> X.400
4.5.1. RFC822->X.400
The following sequence is followed.
以下の順序は従われています。
1. Take the address, and extract an EBNF.822-address.
This can be derived trivially from either the
822.addr-spec or 822.route-addr syntax. This is mapped
to P2.ORName as described above.
1. アドレスを取ってください、そして、EBNF.822-アドレスを抜粋してください。 822.addr-仕様か822.route-addr構文からこれを些細なことに得ることができます。 これは上で説明されるようにP2.ORNameに写像されます。
2. A string should be built consisting of (if present):
2. 成ることが五弦に建てられるべきである、(存在しているなら):
- The 822.phrase component if it is a 822.phrase
822.route-addr construct.
- それであるなら、822.phraseの部品は822.phrase 822.route-addr構造物です。
- Any 822.comments, in order, retaining the
parentheses.
- 括弧を保有するオーダーにおけるどんな822.comments。
This string should then be encoded into T.61 (as
described in chapter 3). If the string is not null,
it should be assigned to P2.ORDescriptor.freeformName.
そして、このストリングはT.61にコード化されるべきです(第3章で説明されるように)。 ストリングがヌルでないなら、それはP2.ORDescriptor.freeformNameに割り当てられるべきです。
3. P2.ORDescriptor.telephoneNumber should be omitted.
3. P2.ORDescriptor.telephoneNumberは省略されるべきです。
4. In cases of converting to P2.Recipient,
P2.Recipient.replyRequest and
P2.Recipient.reportRequest should be omitted.
4. P2.Recipientに変える場合では、P2.Recipient.replyRequestとP2.Recipient.reportRequestは省略されるべきです。
If the 822.group construct is present, each included
822.mailbox should be encoded as above. The 822.group should
be mapped to T.61, and a P2.ORDesciptor with only a
freeformName component built from it.
822.group構造物が存在しているなら、それぞれの含まれている822.mailboxは同じくらい上でコード化されるべきです。 freeformNameの部品だけがそれから造られている状態で、822.groupはT.61、およびP2.ORDesciptorに写像されるべきです。
4.5.2. X.400 -> RFC 822
4.5.2. X.400->RFC822
In the basic case, where P2.ORName is present, proceed as
follows.
基本的な場合では、以下の通り続いてください。そこでは、P2.ORNameが出席しています。
1. Encode P2.ORName as EBNF.822-address.
1. EBNF.822-アドレスとしてP2.ORNameをコード化してください。
Kille [Page 36]
Kille[36ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
2a. If P2.ORDescriptor.freeformName is present, convert it
to ASCII (chapter 3), and use use this as the
822.phrase component of 822.mailbox using the
822.phrase 822.route-addr construct.
2a。 P2.ORDescriptor.freeformNameが存在しているなら、ASCII(第3章)にそれを変換してください。そうすれば、使用は、822.mailboxの822.phraseの部品として822.phrase 822.route-addr構造物を使用することでこれを使用します。
2b. If P2.ORDescriptor.freeformName is absent, if
EBNF.822-address is parsed as 822.addr-spec use this as
the encoding of 822.mailbox. If EBNF.822-address is
parsed as 822.route 822.addr-spec, then a 822.phrase
taken from 822.local-part should be added.
2b。 P2.ORDescriptor.freeformNameが欠けるなら、EBNF.822-アドレスが822.addr-仕様として分析されるなら、822.mailboxのコード化としてこれを使用してください。 EBNF.822-アドレスが822.route 822.addr-仕様として分析されるなら、822.local-部分から取られた822.phraseは加えられるべきです。
3. If P2.ORDescriptor.telephoneNumber is present, this
should be placed in a trailing 822.comment.
3. P2.ORDescriptor.telephoneNumberが存在しているなら、これは引きずっている822.commentに置かれるべきです。
4. If P2.Recipient.reportRequest has the
receiptNotification bit set, then an 822.comment
"(Receipt Notification Requested)" should be appended
to the address. The effort of correlating P1 and P2
information is too great to justify the gateway sending
Receipt Notifications.
4. P2.Recipient.reportRequestがreceiptNotificationビットを設定させるなら、「(通知が要求した領収書)」という822.commentをアドレスに追加するべきです。 P1とP2情報を関連させる努力はゲートウェイがReceipt Notificationsを送るのを正当化できないくらい大きいです。
5. If P2.Recipient.replyRequest is present, an 822.comment
"(Reply requested)" or "(Reply not requested)" should
be appended to the address, dependent on its value.
5. P2.Recipient.replyRequestが存在しているなら、822.comment「(要求された回答)」か「(要求されなかった回答)」をアドレスに追加するべきです、値に依存しています。
If P2.ORName is absent, P2.ORDescriptor.freeformName should be
converted to ASCII, and used with the RFC 822 822.group syntax:
P2.ORNameが欠けるなら、P2.ORDescriptor.freeformNameはASCIIに変換されて、RFC 822 822.group構文で使用されるべきです:
freeformname ":" ";"
"freeformname":、」 ";"
Steps 3-5 should then be followed.
そして、方法3-5は従われるべきです。
4.6. Message IDs
4.6. メッセージID
There is a need to map both ways between 822.msg-id and
P2.IPMessageID. A mapping is defined which is symmetrical for
non-pathological cases. The mapping allows for the fact that
P2.IPMessageID.PrintableString is mandatory for the Cen/Cenelec
profile. This allows for good things to happen when messages pass
multiple times across the X.400/RFC 822 boundary. A mapping
between 822.msg-id and P1.MPDUIdentifier is defined. This allows
for X.400 error messages to reference an RFC 822 ID, which is
preferable to a gateway generated ID.
822.msg-イドとP2.IPMessageIDの間には、両方の道を写像する必要があります。 マッピングは定義されます(非病理学的なケースにおいて、対称です)。 マッピングはP2.IPMessageID.PrintableStringがCen/Cenelecプロフィールに義務的であるという事実を考慮します。 メッセージがX.400/RFC822境界の向こう側に複数の回を通過するとき、これは起こる良いものを考慮します。 822.msg-イドとP1.MPDUIdentifierの間のマッピングは定義されます。 これはX.400エラーメッセージのために、RFC822IDを参照に許容します。(それは、ゲートウェイ発生しているIDより望ましいです)。
Kille [Page 37]
Kille[37ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
4.6.1. P2.IPMessageID -> 822.msg-id
4.6.1. P2.IPMessageID->822.msg-イド
P2.IPMessageID.ORName is used to generate an 822.addr-spec, as
defined above. P2.IPMessageID.PrintableString is mapped to
ASCII, as defined in chapter 3. This string (if it is present
and if the value is not "RFC-822") is appended to the front of
the 822.local-part of the 822.msg-id, with "*" as a separator.
If no ORName is present, an 822.msg-id of the form
"PrintableString*@gateway-domain" is generated.
P2.IPMessageID.ORNameは、822.addr-仕様を発生させるのに上で定義されるように使用されます。 P2.IPMessageID.PrintableStringは第3章で定義されるようにASCIIに写像されます。 このストリング(それが存在していて、値が"RFC-822"でないなら)を822.msg-イドの822.local-部分の前部に追加します、分離符としての「*」で。 どんなORNameも存在していないなら、フォーム" PrintableString*@gateway-domain "の822.msg-イドは発生します。
4.6.2. 822.msg-id -> P2.IPMessageID
4.6.2. 822. msg-イド->P2.IPMessageID
822.local-part is parsed as:
822.の地方の部分は以下として分析されます。
[ printablestring "*" ] real-local-part
[「*」をprintablestringします] 全く地方の部分
If EBNF.printablestring is found, it is mapped to
PrintableString, and used as P2.IPMessageID.PrintableString.
Otherwise
P2.IPMessageID.PrintableString is set to "RFC-822". This
arbitrary value allows for conformance to Cen/Cenelec. If
EBNF.real-local-part is not present, no P2.IPMessageID.ORName
is generated. Otherwise, 822.local-part is replaced with
EBNF.real-local-part, and 822.addr-spec is mapped to
P2.IPMessageID.ORName as defined above.
EBNF.printablestringが見つけられるなら、それは、PrintableStringに写像されて、P2.IPMessageID.PrintableStringとして使用されます。 さもなければ、P2.IPMessageID.PrintableStringは"RFC-822"に用意ができています。 この任意の値はCen/Cenelecにおいて順応を考慮します。 EBNF.realの地方の部分が存在していないなら、P2.IPMessageID.ORNameは全く発生しません。 さもなければ、822.local-部分をEBNF.realの地方の部分に取り替えます、そして、上で定義されるように822.addr-仕様をP2.IPMessageID.ORNameに写像します。
4.6.3. 822.msg-id -> P1.MPDUIdentifier
4.6.3. 822. msg-イド->P1.MPDUIdentifier
P1.CountryName is assigned to "", P1.AdministrationDomainName
to 822.domain (from 822.msg-id) and P1.MPDUIdentifier.IA5String
to 822.local-part (from 822.msg-id).
P1.CountryNameが割り当てられる、「「822.domain(822.msg-イドからの)へのP1.AdministrationDomainNameと822.local-部分(822.msg-イドからの)へのP1.MPDUIdentifier.IA5String、」
4.6.4. P1.MPDUIdentifier -> 822.msg-id
4.6.4. P1.MPDUIdentifier->822.msg-イド
822.local-part is set to P1.MPDUIdentifier.IA5String, with any
CRLF mapped to SPACE. If P1.CountryName is "", 822.domain is
set to P1.AdministrationDomainName; Otherwise to
P1.AdministrationDomainName ".." P1.CountryName. If there are
any specials, the domain literal encoding should be used.
822.の地方の部分はどんなCRLFもSPACEに写像されているP1.MPDUIdentifier.IA5Stringに設定されます。 P1.CountryNameがそうである、「「822.domainはP1.AdministrationDomainNameに用意ができています;、」 「そうでなければ、P1.AdministrationDomainName」、」 P1.CountryName。 何か特別番組があれば、ドメインの文字通りのコード化は使用されるべきです。
Kille [Page 38]
Kille[38ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
Chapter 5 -- Protocol Elements
第5章--プロトコル要素
This chapter gives detailed mappings for the functions outlined in chapters 1 and 2. It makes extensive use of the notations and mappings defined in chapters 3 and 4. This chapter is structured as follows:
本章は第1章と第2章に概説された機能のための詳細なマッピングを与えます。 それで、第3章と第4章で記法とマッピングの大規模な使用を定義します。 本章は以下の通り構造化されます:
5.1. Basic RFC 822 -> X.400 mappings
5.1. 基本的なRFC822->X.400マッピング
5.2. A definition of some new RFC 822 elements, and their mapping
to X.400.
5.2. いくつかの新しいRFC822要素の定義、およびX.400へのそれらのマッピング。
5.3 Some special handling associated with Return of Contents.
5.3 何らかの特別な取り扱いがContentsのReturnと交際しました。
5.4. X.400 -> RFC 822
5.4. X.400->RFC822
5.1. RFC 822 -> X.400
5.1. RFC822->X.400
First, the basic functions of an 822-P1 protocol should be mapped
as follows:
まず最初に、822-P1プロトコルの基本機能は以下の通り写像されるべきです:
822-P1 Originator
822-P1創始者
Mapped to P1.UMPDUEnvelope.originator (see chapter 4).
P1.UMPDUEnvelope.originator(第4章を見る)に写像されます。
822-P1 Recipient
822-P1受取人
Mapped to P1.RecipientInfo (see chapter 4).
P1.RecipientInfo(第4章を見る)に写像されます。
The RFC 822 headers are used to generate both a P1.UMPDUEnvelope
and a P2.Heading. The IP Message will have either one or two
P2.BodyParts which will be type P2.IA5Text with no
P2.IA5Text.repertoire component. The last P2.BodyPart will contain
the RFC 822 message body. If there are any RFC 822 headers which
indicate mapping into the P2.BodyPart, then two P2.BodyParts are
generated. If a revised version of P2 allowed for extensible
header specification, this would be seen as a preferable mapping.
The first body part will start with the line:
RFC822ヘッダーは、P1.UMPDUEnvelopeとP2.Headingの両方を発生させるのに使用されます。 IP MessageはP2.IA5Text.repertoireの部品なしでタイプP2.IA5Textになるどちらかか2P2.BodyPartsを持つでしょう。 最後のP2.BodyPartはRFC822メッセージボディーを含むでしょう。 何かマッピングをP2.BodyPartに示すRFC822ヘッダーがあれば、2P2.BodyPartsが発生します。 P2の改訂版が広げることができるヘッダー仕様を考慮するなら、これは望ましいマッピングと考えられるでしょうに。 最初の身体の部分は線から始まるでしょう:
RFC-822-Headers:
RFC822ヘッダー:
The rest of this body part will contain all of the headers not
otherwise mapped (both 822.field-name and 822.field-body). The
order of any such headers should be preserved. Similarly,
ordering within P2.Heading and P1.UMPDUEnvelope should reflect
ordering within the RFC 822 header. No P1 or P2 optional fields
are generated unless specified.
この身体の部分の残りは別の方法で写像されなかったヘッダー(822.field-nameと822.field-ボディーの両方)のすべてを含むでしょう。 どんなそのようなヘッダーの注文も保存するべきです。 同様に、P2.HeadingとP1.UMPDUEnvelopeの中で注文するのは、RFC822ヘッダーの中に注文しながら、反射するべきです。 指定されない場合、どんなP1もP2の任意の分野も発生しません。
Kille [Page 39]
Kille[39ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
A pro-forma X.400 message is now specified. Some of these
defaults may be changed by the values in the RFC 822 message being
mapped. The mandatory P1 and P2 components have the following
defaults.
形式上のX.400メッセージは現在、指定されます。 写像されるRFC822メッセージの値でこれらのいくつかのデフォルトを変えるかもしれません。 義務的なP1とP2の部品には、以下のデフォルトがあります。
P1.MPDUIdentifier
P1.MPDUIdentifier
The default should be unique value generated by the gateway.
デフォルトはゲートウェイで発生するユニークな値であるべきです。
P1.OriginatorORName
P1.OriginatorORName
Always generated from 822-P1.
822-P1からいつも発生しています。
P1.ContentType
P1.ContentType
P1.ContentType.p2
P1.ContentType.p2
P1.RecipientInfo
P1.RecipientInfo
These will always be supplied from 822-P1.
822-P1からこれらをいつも供給するでしょう。
P1.Trace
P1.Trace
The last P1.TraceInformation component is generated such
that: P1.TraceInformation.GlobalDomainIdentifier is set to
the local vaglue. P1.DomainSuppliedInfo.action is set to
relayed. P1.DomainSuppliedInfo.arrival is set to the current
time. P1.DomainSuppliedInfo.previous may be set if there is
anything sensible to set it to.
最後のP1.TraceInformationの部品が発生しているそのようなものであるので: P1.TraceInformation.GlobalDomainIdentifierは地方のvaglueに用意ができています。 P1.DomainSuppliedInfo.actionはリレーされるのに用意ができています。 P1.DomainSuppliedInfo.arrivalは現在の時間に用意ができています。 それにそうするように設定するために分別があるものは何かがあれば、P1.DomainSuppliedInfo.previousは用意ができるかもしれません。
P2.IPMessageID
P2.IPMessageID
The default should be a unique value generated by the
gateway.
デフォルトはゲートウェイで発生するユニークな値であるべきです。
The following optional parameters should be set:
以下の任意のパラメタは設定されるべきです:
P1.PerMessageFlag
P1.PerMessageFlag
The P1.PerMessageFlag.contentReturnRequest bit should be set
according to the discussion in section 5.3. The
P1.PerMessageFlag.alternateRecipientAllowed bit should be
set, as it seems desirable to maximise opportunity for
(reliable) delivery.
議論に従って、P1.PerMessageFlag.contentReturnRequestビットはセクション5.3に設定されるべきです。 (信頼できる)の配送の機会を最大にするのが望ましく思えるようにP1.PerMessageFlag.alternateRecipientAllowedビットは設定されるべきです。
Kille [Page 40]
Kille[40ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
The RFC 822 headings should be mapped as follows:
RFC822見出しは以下の通り写像されるべきです:
Received:
受け取られている:
Fudged onto P1.TraceInformation (try not to grimace too
much). P1.DomainSuppliedInfo.action is set to relayed.
P1.DomainSuppliedInfo.arrival is set to the date-time
component P1.TraceInformation.GlobalDomainIdentifier has
P1.CountryName as a null string, and
P1..AdministrationDomainName as the domain of the receiving
host (if present - null string if not).
P1.DomainSuppliedInfo.previous has P1.CountryName as a null
string, and P1.AdministrationDomainName has the domain of
the sending host with all other information enclosed in
round parentheses. The encoding of ASCII to PrintableString
(chapter 3) should be used if needed. For example:
P1.TraceInformation(しかめつらをし過ぎないようにする)にごまかされます。 P1.DomainSuppliedInfo.actionはリレーされるのに用意ができています。 コンポーネントP1.TraceInformation.GlobalDomainIdentifierにはP1.CountryNameがある日付-時までP1.DomainSuppliedInfo.arrivalはヌルストリング、およびP1としてセットです。受信のドメインとしてのAdministrationDomainNameが接待する、(プレゼント--ヌルストリングである、そうでなければ) P1.DomainSuppliedInfo.previousにはヌルストリングとしてP1.CountryNameがあります、そして、P1.AdministrationDomainNameは他のすべての情報をもっている送付ホストのドメインが丸い括弧で囲まれるのを持っています。 必要であるなら、PrintableString(第3章)へのASCIIのコード化は使用されるべきです。 例えば:
Received: from 44e.cs.ucl.ac.uk by vax2.Cs.Ucl.AC.UK
with SMTP id a002110; 18 Dec 85 10:40 GMT
受け取られている: SMTPイドa002110とvax2.Cs.Ucl.AC.UKによる44e. cs.ucl.ac.ukから。 1985年12月18日のグリニッジ標準時10時40分
maps to -
地図、-
P1.GlobalDomainIdentifier
CountryName = ""
AdministrationDomainName = "vax2.Cs.Ucl.AC.UK"
P1.DomainSuppliedInfo
arrival = 18 Dec 85 10:40 GMT
action = relayed
previous
CountryName = ""
AdministrationDomainName =
"44e.cs.ucl.ac.uk (with SMTP id a002110)"
P1.GlobalDomainIdentifier CountryNameが等しい、「「"vax2.Cs.Ucl.AC.UK"P1.DomainSuppliedInfo AdministrationDomainName=到着が=がリレーした1985年12月18日のグリニッジ標準時10時40分の動作と前であることの状態で等しい、CountryNameが等しい、「「AdministrationDomainNameは「44e. cs.ucl.ac.uk(SMTPイドa002110と)」と等しいです」。
Date:
日付:
This is used to set the first component of
P1.TraceInformation. The mandatory components are set as
follows:
これは、P1.TraceInformationの最初の部品を設定するのに使用されます。 義務的なコンポーネントは以下の通り設定されます:
P1.GlobalDomainIdentifier
CountryName = ""
AdministrationDomainName = ""
P1.DomainSuppliedInfo
arrival = time derived from Date:
action = relayed
P1.GlobalDomainIdentifier CountryNameが等しい、「「AdministrationDomainNameが等しい、「「P1.DomainSuppliedInfo到着=時間を日付:から派生しました」。 =がリレーした動作
No optional fields are used in the trace.
どんな任意の分野も跡で使用されません。
Kille [Page 41]
Kille[41ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
Message-Id:
メッセージイド:
Mapped to P2.IPMessageID. If the RFC 822 message does not
contain a P1-Message-ID: field, the Message-Id: field is
also mapped to P1.MPDUIdentifier. For these, and all other
fields containing msg-id the mappings of chapter 4 are used
for each msg-id.
P2.IPMessageIDに写像されます。 RFC822メッセージがP1Message IDを含んでいないなら: 分野、Message-イド: また、分野はP1.MPDUIdentifierに写像されます。 これら、およびmsg-イドを含む他のすべての分野において、第4章に関するマッピングは各msg-イドに使用されます。
From:
From:
If Sender: is present, this is mapped to
P2.AuthorisingUsers. If not, it is mapped to P2.Originator.
For this, and other components containing addresses, the
mappings of chapter 4 are used for each address.
送付者であるなら: 存在している、これはP2.AuthorisingUsersに写像されます。 そうでなければ、それはP2.Originatorに写像されます。 これ、およびアドレスを含む他のコンポーネントにおいて、第4章に関するマッピングは各アドレスに使用されます。
Sender:
送付者:
Mapped to P2.Originator.
P2.Originatorに写像されます。
Reply-To:
Reply-To
Mapped to P2.Heading.replyToUsers.
P2.Heading.replyToUsersに写像されます。
To:
To:
Mapped to P2.Heading.primaryRecipients
P2.Heading.primaryRecipientsに写像されます。
Cc:
Cc:
Mapped to P2.Heading.copyRecipients.
P2.Heading.copyRecipientsに写像されます。
Bcc:
Bcc:
Mapped to P2.Heading.blindCopyRecipients.
P2.Heading.blindCopyRecipientsに写像されます。
In-Reply-To:
以下に対して
Mapped to P2.Heading.inReplyTo for the first (if any)
822.msg-id component. If the field contains an 822.phrase
component, or there are multiple 822.msg-id components, the
ENTIRE field is passed in the P2.BodyPart.
最初(もしあれば)の822.msg-イドコンポーネントのためにP2.Heading.inReplyToに写像されます。 分野が822.phraseの部品を含んでいるか、または複数の822.msg-イドコンポーネントがあれば、ENTIRE野原はP2.BodyPartを通り過ぎられます。
References:
参照:
Mapped to P2.Heading.crossReferences.
P2.Heading.crossReferencesに写像されます。
Kille [Page 42]
Kille[42ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
Keywords:
キーワード:
Passed in the P2.BodyPart.
P2.BodyPartでは、通過されます。
Subject:
Subject:
Mapped to P2.Heading.subject. The field-body uses the
mapping referenced in chapter 3 from ASCII to T.61.
P2.Heading.subjectに写像されます。 分野本体は第3章でASCIIからT.61まで参照をつけられるマッピングを使用します。
Comments:
コメント:
Passed in the P2.BodyPart.
P2.BodyPartでは、通過されます。
Encrypted:
コード化される:
Passed in the P2.BodyPart.
P2.BodyPartでは、通過されます。
Resent-*
*に憤慨します。
Passed in the P2..BodyPart <8>.
P2では、通過されます。BodyPart<8>。
Other Fields
他の分野
In particular X-* fields, and "illegal" fields in common
usage (e.g. "Fruit-of-the-day:") are passed in the
P2.BodyPart. The same treatment should be applied to
RFC 822 fields where the content of the field does not
conform to RFC 822 (e.g. a Date: field with unparsable
syntax).
特定のX-*がさばいて、「不法入国者」が一般的な用法でさばく(例えば、「1日に実を結ばせてください」)コネはP2.BodyPartで通過されます。 同じ処理は分野の内容がRFC822(例えば、「非-パー-可能」構文がある日付:分野)に従わないRFC822分野に適用されるべきです。
5.2. Extended RFC 822 Elements -> X.400
5.2. 拡張RFC822要素->X.400
First an EBNF definition of a number of extended fields is given,
and then a mapping to X.400 is defined. In most cases, the
RFC 822 syntax is defined to make this mapping very
straightforward, and so no detailed explanation of the mapping is
needed.
まず最初に、多くの拡張分野のEBNF定義を与えます、そして、次に、X.400へのマッピングを定義します。 多くの場合、RFC822構文がこのマッピングを非常に簡単にするように定義されるので、マッピングの詳説は全く必要ではありません。
extended-field = "P1-Message-ID" ":" p1-msg-id
/ "X400-Trace" ":" x400-trace
/ "Original-Encoded-Information-Types"
":"encoded-info
/ "P1-Content-Type" ":" p1-content-type
/ "UA-Content-ID" ":" printablestring
/ "Priority" ":" priority
/ "P1-Recipient" : 1 mailbox
/ "Deferred-Delivery" ":" date-time
「拡張分野=「P1メッセージID」」:、」 「p1-msg-イド/「X400跡」」:、」 「/「元のコード化された情報タイプ」のために」 : 「コード化されたインフォメーション/「P1コンテントタイプ」」をx400たどってください」 「p1の満足しているタイプ/「UAコンテントID」」:、」 「printablestring/「優先権」」:、」 優先権/「P1受取人」: 「1メールボックス/「延期した納入」」:、」 日付-時間
Kille [Page 43]
Kille[43ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
/ "Bilateral-Info" ":" bilateral-info
/ "Obsoletes" ":" 1 msg-id
/ "Expiry-Date" ":" date-time
/ "Reply-By" ":" date-time
/ "Importance" ":" importance
/ "Sensitivity" ":" sensitivity
/ "Autoforwarded" ":" boolean
「/「双方のインフォメーション」」:、」 「双方のインフォメーション/は「時代遅れに」」:、」 「1msg-イド/「有効期限日」」:、」 「日付-時間/「近く、返答」」:、」 「日付-時間/「重要性」」:、」 「重要性/「感度」」:、」 「感度/"Autoforwarded"」:、」 論理演算子
p1-msg-id = global-id ";" *text
「p1-msg-イドはグローバルなイドと等しい」;、」 *テキスト
p1-content-type = "P2" / atom
p1の満足しているタイプは「P2"/原子」と等しいです。
x400-trace = global-id ";"
"arrival" date-time
[ "deferred" date-time ]
[ "action" action ]
[ "converted" "(" encoded-info ")" ]
[ "previous" global-id ]
「x400-跡はグローバルなイドと等しい」;、」 「到着」日付-時間[日付-時間を「延期する」][「動作」動作][「変換される」「(「コード化されたインフォメーション」)」という][「前」のグローバルなイド]
action = "Relayed" / "Rerouted" / escape
動作は「リレーされた」か「別ルートで送られた」/エスケープと等しいです。
global-id = c "*" admd [ "*" prmd ]
グローバルなイド=c「*」admd[「*」prmd]
encoded-info = 1 encoded-type
コード化されたインフォメーションは1つのコード化されたタイプと等しいです。
encoded-type = "Undefined" ; undefined (0)
/ "Telex" ; tLX (1)
/ "IA5-Text" ; iA5Text (2)
/ "G3-Fax" ; g3Fax (3)
/ "TIF0" ; tIF0 (4)
/ "Teletex" ; tTX (5)
/ "Videotex" ; videotex (6)
/ "Voice" ; voice (7)
/ "SFD" ; sFD (8)
/ "TIF1" ; tIF1 (9)
/ escape
コード化されたタイプ=「未定義」。 未定義の(0)/「テレックス」。 tLX(1)/「IA5テキスト」。 iA5Text(2)/「G3ファックス」。 g3Fax(3)/"TIF0""。 tIF0(4)/「テレテックス」。 tTX(5)/「ビデオテックス」。 ビデオテックス(6)/「声」。 声の(7)/"SFD"。 sFD(8)/"TIF1""。 tIF1(9)/エスケープ
priority = "normal" / "non-urgent" / "urgent" / escape
優先権は「正常である」か「不急」の、または、「緊急」の/エスケープと等しいです。
bilateral-info = c "*" admd "*" *text
双方のインフォメーション=c「*」admd「*」*テキスト
importance = "low" / "normal" / "high" / escape
重要性=「安値」/「標準」/「高値」/エスケープ
sensitivity = "Personal" / "Private"
/ "Company-Confidential" / escape
感度=「個人的である」か「個人的な」/「社内秘密」/エスケープ
escape = 1*DIGIT
=1*DIGITから逃げてください。
Kille [Page 44]
Kille[44ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
With the exception of "Bilateral-Info:" and "X400-Trace:", there
must be no more than one of each of these fields in an RFC 822
header. Any field beginning with the String "Autoforwarded-" is
valid if the field would be syntactically valid with this string
removed.
「双方のインフォメーション:」 そして、RFC822ヘッダーに「以下をX400たどっ」て、それぞれのこれらの分野の1つ未満があるに違いありません。 分野がシンタクス上このストリングを取り除いていて有効であるなら、String"Autoforwarded"と共に始まるどんな分野も有効です。
The mappings to X.400 are as follows:
X.400へのマッピングは以下の通りです:
P1-Message-ID:
P1Message ID:
Mapped to P1.UMPDUEnvelope.MPDUIdentifier. This take
precedence over any value derived from Message-ID:.
P1.UMPDUEnvelope.MPDUIdentifierに写像されます。 どんな値の上の先行がMessage-IDから引き出したこの撮影:
X400-Trace:
X400-跡:
Mapped to the next component of
P1.UMPDUEnvelope.Traceinformation. Care should be taken to
preserve order. If one or more of these mappings is made,
then a trace component should NOT be generated from the
Date: field which should be redundant. This is because the
message has previously come from X.400, and the Date:
information will be redundant. Note that all trace
information (Received: and "X400-Trace:") in the RFC 822
message will be in strict order, with the most recent at the
top. This order should be preserved in the mapping.
P1.UMPDUEnvelope.Traceinformationの次の部品に写像されます。 オーダーを保存するために注意するべきです。 これらのマッピングの1つ以上が作られるなら、跡のコンポーネントは日付:から発生するべきではありません。 余分であるべき分野。 これはメッセージが以前にX.400、および日付:から来たからです 情報は余分になるでしょう。 RFC822メッセージのすべてのトレース情報(受け取りました: そして、「以下をX400たどる」)が厳しいオーダーで最新であるのをもってトップであることに注意してください。 このオーダーはマッピングに保存されるべきです。
Original-Encoded-Information-Types:
オリジナルは情報タイプをコード化しました:
This is used to set P1.UMPDUEnvelope.original.
P1.EncodedInformationTypes.[0] has bits set according to
each of the encoded-info components in this field. Any
escape values should not be encoded.
これは、P1.UMPDUEnvelope.originalを設定するのに使用されます。 それぞれのコード化されたインフォメーションコンポーネントに従って、P1.EncodedInformationTypes.[0]はこの分野にビットを設定させます。 少しのエスケープ値もコード化するべきではありません。
P1-Content-Type:
P1-コンテントタイプ:
If the value is anything other than "P2", the mapping should
not be performed (unless the new value has some semantics to
the gateway).
「P2"、マッピングを実行(新しい値が何らかの意味論をゲートウェイに持っていない場合)であるべきでない」を除いて、値が何かであるなら。
UA-Content-ID:
UA-コンテントID:
Mapped to P1.UMPDUEnvelope.UAContentID.
P1.UMPDUEnvelope.UAContentIDに写像されます。
Priority:
優先権:
Mapped to P1.UMPDUEnvelope.Priority. An escape value should
be encoded as P1.Priority.normal.
P1.UMPDUEnvelope.Priorityに写像されます。 エスケープ値はP1.Priority.normalとしてコード化されるべきです。
Kille [Page 45]
Kille[45ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
P1-Recipient:
P1-受取人:
If this field is set, the
P1.PerMessageFlag.discloseRecipients bit should be set. Any
of the addresses here which do not correspond to 822-P1
recipients should be added to the P1 recipient list, with
the responsibility bit turned off.
この分野が設定されるなら、P1.PerMessageFlag.discloseRecipientsビットは設定されるべきです。 ここの822-P1受取人に文通されないアドレスのどれかはP1受取人リストに追加されるべきです、責任ビットがオフにされている状態で。
Deferred-Delivery:
延期した納入:
Mapped to P1.UMPDUEnvelope.deferredDelivery. Note that the
value of this field should always be in the past, as this
field should only be present in messages which have come
originally from X.400. Thus there should be no implied
action. See also the comments on the reverse mapping.
P1.UMPDUEnvelope.deferredDeliveryに写像されます。 この分野の値が過去にいつもそうあるべきであることに注意してください、この分野が単に元々X.400から来たメッセージに存在しているべきであるとき。 したがって、どんな暗示している動きもあるべきではありません。 また、逆のマッピングのコメントを見てください。
Bilateral-Info:
双方のインフォメーション:
No attempt is made to reconvert this information back to
X.400.
この情報をX.400に再転して戻させるのを試みを全くしません。
Obsoletes:
時代遅れにします:
Mapped to P2.Heading.obsoletes.
P2.Heading.obsoletesに写像されます。
Expiry-Date:
有効期限日:
Mapped to P2.Heading.expiryDate.
P2.Heading.expiryDateに写像されます。
Reply-By:
返答してください:
Mapped to P2.Heading.replyBy.
P2.Heading.replyByに写像されます。
Importance:
重要性:
Mapped to P2.Heading.importance. An escape value should be
encoded as P2.Heading.importance.normal.
P2.Heading.importanceに写像されます。 エスケープ値はP2.Heading.importance.normalとしてコード化されるべきです。
Sensitivity:
感度:
Mapped to P2.Heading.sensitivity. An escape value should be
encoded as P2.Heading.sensitivity.normal.
P2.Heading.sensitivityに写像されます。 エスケープ値はP2.Heading.sensitivity.normalとしてコード化されるべきです。
Autoforwarded:
Autoforwardedしました:
If this field is present and the value is "TRUE", there will
be zero or more field names beginning "Autoforwarded-".
この分野が存在していて、値がゼロが「本当に」あるということであるか、より多くのフィールド名が"Autoforwarded"を始めることであるなら。
Kille [Page 46]
Kille[46ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
These should be taken, and the string "Autoforwarded-"
stripped. These fields, in conjunction with the 822-P1
information should be used to build an IP Message. Any
implied actions should be taken. P2.Heading.autoforwarded is
set in this message. The other RFC 822 fields are used to
build another IP Message, which is used as the single body
part of the first message. This mechanism does not nest.
これらは、取って"Autoforwarded"が剥取ったストリングであるべきです。 これらの分野であり、822-P1に関連して情報は、IP Messageを造るのに使用されるべきです。 どんな暗示している行動も取るべきです。 P2.Heading.autoforwardedはこのメッセージで用意ができています。 他のRFC822分野は、別のIP Messageを造るのに使用されます。(Messageは最初のメッセージのただ一つの身体の部分として使用されます)。 このメカニズムはどんな巣もしません。
5.3. Return of Contents
5.3. コンテンツの復帰
It is not clear how widely supported X.400 return of contents
service will be. However, profiling work suggests that most
systems will not support this service. As this service is
expected in the RFC 822 world, two approaches are specified (it is
not so necessary in the X.400 world, as delivery reports are
distinguished from messages). The choice will depend on the
service level of the X.400 community being serviced by the
gateway.
広く支持されたX.400がコンテンツサービスについてどう戻るかが、そうであることは明確ではありません。 しかしながら、仕事の輪郭を描くのは、ほとんどのシステムがこのサービスを支持しないのを示します。 このサービスがRFC822世界で予想されるように、2つのアプローチが指定されます(それはX.400世界でそれほど必要ではありません、配送レポートがメッセージと区別されるとき)。 この選択はゲートウェイによってサービスを提供されるX.400共同体のサービスレベル次第でしょう。
In environments where return of contents is widely supported, the
P1.PerMessageFlag content return request bit will be set, and the
Report Request bit in P1.PerRecipientFlag will be set to
Confirmed, for every message passing from RFC 822 -> X.400. The
content return service can then be passed back to the end
(RFC 822) user in a straightforward manner.
コンテンツの復帰が広く支持される環境で、P1.PerMessageFlag満足している返送依頼ビットは設定されるでしょう、そして、P1.PerRecipientFlagのReport RequestビットはConfirmedに設定されるでしょう、RFC822->X.400からのあらゆるメッセージ・パッシングのために。 そして、正直な態度で終わり(RFC822)のユーザに満足しているリターンサービスを戻すことができます。
In environments where return of contents is not widely supported,
a gateway must make special provisions to handle return of
contents. For every message passing from RFC 822 -> X.400, the
P1.PerMessageFlag content return request bit will be set, and the
Report Request bit in P1.PerRecipientFlag will be set to
Confirmed. When the delivery report comes back, the gateway can
note that the message has been delivered to the recipient(s) in
question. If a non-delivery report is received, a meaningful
report (containing some or all of the original message) can be
sent to the 822-P1 originator. If no report is received for a
recipient, a (timeout) failure notice should be sent to the 822-P1
originator. The gateway may retransmit the X.400 message if it
wishes. Delivery confirmations should only be sent back to the
822-P1 originator if the P1.PerRecipientFlag User Report Request
bit is set to Confirmed.
コンテンツの復帰が広く支持されない環境で、ゲートウェイは、コンテンツの復帰を扱うために特別条項を作らなければなりません。 RFC822->X.400からのあらゆるメッセージ・パッシングにおいて、P1.PerMessageFlag満足している返送依頼ビットは設定されるでしょう、そして、P1.PerRecipientFlagのReport RequestビットはConfirmedに設定されるでしょう。 配送レポートが戻るとき、ゲートウェイは、問題の受取人にメッセージを送ることに注意できます。 非配送レポートが受け取られているなら、重要なレポート(オリジナルのメッセージのいくつかかすべてを含んでいる)を822-P1創始者に送ることができます。 受取人のためにレポートを全く受け取らないなら、(タイムアウト)失敗通知を822-P1創始者に送るべきです。 願うなら、ゲートウェイはX.400メッセージを再送するかもしれません。 P1.PerRecipientFlag User Report RequestビットがConfirmedに設定される場合にだけ、配送確認は822-P1創始者に送り返されるべきです。
Kille [Page 47]
Kille[47ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
5.4. X.400 -> RFC 822
5.4. X.400->RFC822
5.4.1. General
5.4.1. 一般
This section describes how to build a pro-forma message, and
then explains how these defaults may be overridden. It should
be noted that RFC 822 folding of headers should be used in an
appropriate manner.
このセクションは、形式上のメッセージを築き上げる方法を説明して、次に、これらのデフォルトがどうくつがえされるかもしれないかを説明します。 ヘッダーにおける折りたたみのRFC822が適切な方法で使用されるべきであることに注意されるべきです。
5.4.2. Service MPDU
5.4.2. サービスMPDU
5.4.2.1. Probe
5.4.2.1. 徹底的調査
Any P1.ProbeMPDU should be serviced by the gateway, as there
is no equivalent RFC 822 functionality. The value of the
reply is dependent on whether the gateway could service a
User MPDU with the values specified in the probe. The reply
should make use of P1.SupplementaryInformation to indicate
that the probe was serviced by the gateway.
どんな同等なRFC822の機能性もなくて、どんなP1.ProbeMPDUもゲートウェイによって調整されるべきです。 回答の値は値が徹底的調査で指定されている状態でゲートウェイがUser MPDUを調整できたかどうかに依存しています。 回答は、徹底的調査がゲートウェイによって修理されたのを示すのにP1.SupplementaryInformationを利用するべきです。
5.4.2.2. Delivery Report
5.4.2.2. 配送レポート
The 822-P1 components are constructed as follows:
822-P1の部品は以下の通り構成されます:
822-P1 Originator
822-P1創始者
This is set to an 822.addr-spec pointing to an
administrator at the gateway.
これはゲートウェイに管理者を示す822.addr-仕様へのセットです。
822-P1 Recipient
822-P1受取人
The single recipient is constructed from
P1.DeliveryReportEnvelope.originator, using the
mappings of chapter 4.
第4章に関するマッピングを使用して、独身の受取人はP1.DeliveryReportEnvelope.originatorから組み立てられます。
The mandatory RFC 822 headers for an RFC 822 pro-forma are
constructed as follows:
形式上、RFC822のための義務的なRFC822ヘッダーは以下の通り組み立てられます:
Date:
日付:
From the P1.DomainSuppliedInfo.arrival component of
the first P1.TraceInformation component.
最初のP1.TraceInformationの部品のP1.DomainSuppliedInfo.arrivalの部品から。
From:
From:
This is set to the same as the 822-P1 originator. An
これは822-P1創始者と同じくらいに設定されます。 1
Kille [Page 48]
Kille[48ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
appropriate phrase component may be added (e.g. giving
the name of the gateway).
適切な句のコンポーネントは加えられるかもしれません(例えば、ゲートウェイの名前を与えます)。
To:
To:
The same as the 822-P1 recipient.
822-P1受取人と同じです。
A Subject: field should be added, which contains some
appropriate words (e.g. "Delivery Report").
Subject: 分野(いくつかの適切な言葉(例えば、「配送レポート」)を含む)は加えられるべきです。
The other two P1.DeliveryReportEnvelope parameters should be
mapped as follows:
他の2つのP1.DeliveryReportEnvelopeパラメタが以下の通り写像されるべきです:
P1.DeliveryReportEnvelope.report
P1.DeliveryReportEnvelope.report
This should be mapped to a P1-Message-Id: field.
これはP1メッセージイドに写像されるべきです: さばきます。
P1.DeliveryReportEnvelope.TraceInformation
P1.DeliveryReportEnvelope.TraceInformation
Each component should be mapped to an "X400-Trace:"
field. RFC 822 and X.400 ordering should be
maintained (see 5.3).
各コンポーネントが写像されるべきである、「X400-跡:」 さばきます。 RFC822とX.400注文を維持するべきです(5.3を見てください)。
The P1.DeliveryReportContent parameters should be mapped to
a series of new RFC 822 headers. These new headers are
intended for processing in the RFC 822 world. No attempt
will be made to reverse the mappings.
P1.DeliveryReportContentパラメタは一連の新しいRFC822ヘッダーに写像されるべきです。 これらの新しいヘッダーはRFC822世界での処理のために意図します。 マッピングを逆にするのを試みを全くしないでしょう。
drc-field = "Delivery-Report-Content-Original"
":" msg-id
/ "Delivery-Report-Content-Intermediate-Trace"
":" x400-trace
/ "Delivery-Report-Content-UA-Content-ID"
":" printablestring
/ "Delivery-Report-Content-Billing-Information"
":" *text
/ "Delivery-Report-Content-Reported-Recipient-Info"
":" drc-info
「drc-分野は「配送のレポートの満足しているオリジナル」と等しい」:、」 「msg-イド/「配送のレポートの満足している中間的跡」」:、」 「x400-跡/「配送のレポートの満足しているUAコンテントID」」:、」 「printablestring/「配送のレポートの満足している支払い情報」」:、」 *「テキスト/「配送のレポートの満足している報告された受取人インフォメーション」」:、」 drc-インフォメーション
drc-info = mailbox ";"
last-trace ";"
"ext" 1*DIGIT
"flags" 2DIGIT
[ "intended" mailbox ] ";"
[ "info" printablestring ]
「drc-インフォメーションはメールボックスと等しい」;、」 「最後の跡」;、」 「"ext"1*DIGITは「」 2DIGIT[「意図している」メールボックス]に旗を揚げます」」 [「インフォメーション」printablestring]
Kille [Page 49]
Kille[49ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
last-trace = drc-report ";"
date-time ";"
[ "converted" "(" encoded-info ")"
「最後に=drc-レポートをたどってください」;、」 「日付-時間」;、」 [「変換される」「(「コード化されたインフォメーション」)」という。
drc-report = "SUCCESS" drc-success
/ "FAILURE" drc-failure
drc-レポート=「成功」drc-成功/「失敗」drc-失敗
drc-success = date-time ";" 1*DIGIT
「drc-成功=日付-時間」;、」 1*ケタ
drc-failure = *text [ ";" *text ] ";"
「drc-失敗は*テキストと等し[「;」*テキスト]」;、」
There may be multiple
"Delivery-Report-Content-Intermediate-Trace:" and
"Delivery-Report-Content-Reported-Recipient-Info:" fields.
The msg-id for "Delivery-Report-Content-Original" is derived
according to the mapping of chapter 4. EBNF.drc-failure may
use numeric values or textual explanation. The latter is
preferred. All P1.DeliveryReportContent parameters are
mapped to the corresponding component. The order of
"Delivery-Report-Content-Intermediate-Trace:" should have
the most recently stamped one first.
そこでは、複数であるかもしれません。「配送は内容中間的な跡を報告します」。 そして、「配送レポート内容は受取人インフォメーションを報告しました」。 分野。 第4章に関するマッピングに従って、「配送のレポートの満足しているオリジナル」のためのmsg-イドは引き出されます。 EBNF.drc-失敗は数値か原文の説明を使用するかもしれません。 後者は好まれます。 すべてのP1.DeliveryReportContentパラメタが対応するコンポーネントに写像されます。 注文する、「配送のレポートの満足している中間的跡:」 最も最近、1/1に押し込むべきでした。
The body of the RFC 822 message should be a human readable
description of the critical parts of the
P1.DeliveryReportContent. In particular, the failed
recipients, and failure reason should be given. Some or all
of the original message should be included in the delivery
report. The original message will be available at the
gateway, as discussed in section 5.3.
RFC822メッセージのボディーはP1.DeliveryReportContentの批判的な部分の人間の読み込み可能な記述であるべきです。 特に理由があげられるべきである失敗した受取人、および失敗。 オリジナルのメッセージのいくつかかすべてが配送レポートに含まれるべきです。 オリジナルのメッセージはセクション5.3で議論するようにゲートウェイで利用可能になるでしょう。
5.4.3. User MPDU
5.4.3. ユーザMPDU
These elements are the basis for both Status Report and IP
Message.
これらの要素はStatus ReportとIP Messageの両方の基礎です。
The 822-P1 components are constructed as follows:
822-P1の部品は以下の通り構成されます:
822-P1 Originator
822-P1創始者
This is derived from P1.UMPDUEnvelope.originator.
P1.UMPDUEnvelope.originatorからこれを得ます。
822-P1 Recipient
822-P1受取人
Each recipient is constructed from the P1.RecipientInfo,
as described in chapter 4. This describes actions as
well as format mappings.
各受取人は第4章で説明されるようにP1.RecipientInfoから組み立てられます。 また、これは形式マッピングとして動作を記述します。
Kille [Page 50]
Kille[50ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
The mandatory RFC 822 field pro-forma is derived as follows.
In most cases where the P1.UMPDUContent is an IP Message, these
defaults will be overridden:
形式上、義務的なRFC822分野は以下の通り引き出されます。 多くの場合、これらのデフォルトはP1.UMPDUContentがIP Messageであるところでくつがえされるでしょう:
Date:
日付:
From the P1.DomainSuppliedInfo.arrival component of the
first P1.TraceInformation component.
最初のP1.TraceInformationの部品のP1.DomainSuppliedInfo.arrivalの部品から。
From:
From:
From the P1.UMPDUEnvelope.originator, as defined in
chapter 4.
P1.UMPDUEnvelope.originator第4章で定義されるように。
To:
To:
This default is only required if the generated RFC 822
message has no destination specification. If
P1.PerMessageFlag.discloseRecipients is set then it
should contain the ORName in each P1.RecipientInfo
component. If it is not set, the it should be set to
"To: No Recipients Specified : ;".
発生しているRFC822メッセージに目的地仕様が全くない場合にだけ、このデフォルトが必要です。 P1.PerMessageFlag.discloseRecipientsが用意ができているなら、それはそれぞれのP1.RecipientInfoの部品にORNameを含むべきです。 それが設定されないなら設定する、それは「To:」に設定されるべきです。 どんな受取人も指定しませんでした: ;".
The mappings, and any actions for each P1.UserMPDU element is
now considered.
現在、マッピング、およびそれぞれのP1.UserMPDU要素のためのどんな動作もそうです。考えられる。
P1.MPDUIdentifier
P1.MPDUIdentifier
Mapped to the extended RFC 822 field "P1-Message-ID:".
Note that the sequence CRLF is mapped to SPACE, which
makes the mapping irreversible for such cases.
拡張RFC822分野に写像されて、「P1はIDを通信します」。 系列CRLFがSPACEに写像されることに注意してください。(SPACEはマッピングをそのような場合に逆にできなくします)。
P1.UMPDUEnvelope.original
P1.UMPDUEnvelope.original
Mapped to the extended RFC 822 field
"Original-Encoded-Information-Types:". If it contains
only P2.IA5Text, the RFC 822 field may be omitted.
拡張RFC822分野「オリジナルは情報タイプをコード化したこと」に写像されます。 P2.IA5Textだけを含んでいるなら、RFC822分野は省略されるかもしれません。
P1.ContentType
P1.ContentType
As this can currently only have one value, it is not
mapped, on the basis that it is redundant. If the field
contains any value other than P2, then the UMPDU should
be rejected.
これが現在1つの値しか持つことができないようにそれはベースで写像されません。余分。 分野が何かP2以外の値を含んでいるなら、UMPDUは拒絶されるべきです。
Kille [Page 51]
Kille[51ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
P1.UAContentID
P1.UAContentID
Mapped to the extended RFC 822 field "UA-Content-Id:".
拡張RFC822分野に写像されて、「UAはイドを満足します」。
P1.Priority
P1.Priority
Mapped to the extended RFC 822 field "Priority:".
拡張RFC822分野に写像される、「優先権:」
P1.PerMesageFlag
P1.PerMesageFlag
This has a number of components:
これには、多くのコンポーネントがあります:
- discloseRecipients
- discloseRecipients
If this bit is set, a "P1-Recipient:" field should
be generated, and contain each of the P1
recipients.
このビットがセット、aである、「P1-受取人:」 分野は、発生して、P1受取人各人を含むべきです。
- conversionProhibited
- conversionProhibitedしました。
If this bit is set, the message should be rejected
if it contains P2.BodyPart which is not P2.IA5Text
or P2.ForwardedIPMessage.
このビットが設定されるなら、P2.IA5Textでなくて、またP2.ForwardedIPMessageでもないP2.BodyPartを含んでいるなら、メッセージは拒絶されるべきです。
- alternateRecipientAllowed
- alternateRecipientAllowed
The value of this bit is ignored.
このビットの価値は無視されます。
- contentReturnRequest
- contentReturnRequest
The value of this bit is ignored.
このビットの価値は無視されます。
P1.UMPDUEnvelope.deferredDelivery
P1.UMPDUEnvelope.deferredDelivery
This should be mapped to the extended RFC 822 field
"Deferred-Delivery:". X.400 profiles, and in particular
the CEN/CENELEC profile [CEN/CENELEC/85a], specify that
this element must be supported at the first MTA. Thus,
it is expected that the value of this element will always
be in the past. If it is not, the function may
optionally be implemented by the gateway: that is, the
gateway should hold the message until the time specified
in the protocol element. Thus the extended RFC 822 field
is just for information.
これが拡張RFC822分野に写像されるべきである、「延期した納入:」 X.400プロフィール、および特にCEN/CENELECプロフィール[CEN/CENELEC/85a]は、最初のMTAでこの要素を支えなければならないと指定します。 したがって、この要素の価値が過去にいつもあると予想されます。 それがそうでないなら、機能はゲートウェイによって任意に実行されるかもしれません: 時間がプロトコル要素で指定するまで、すなわち、ゲートウェイはメッセージを保持するはずです。 したがって、拡張RFC822分野はまさしく情報のためのものです。
Kille [Page 52]
Kille[52ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
P1.PerDomainBilateralInformation
P1.PerDomainBilateralInformation
Each component should be encoded in the extended RFC 822
field "Bilateral-Info:". P1.BilateralInfo should be
mapped into ASCII in a manner appropriate to its
contents. This submapping is not reversible.
各コンポーネントが拡張RFC822分野でコード化されるべきである、「双方のインフォメーション:」 P1.BilateralInfoはコンテンツに適切な方法でASCIIに写像されるべきです。 この副写像はリバーシブルではありません。
P1.TraceInformation
P1.TraceInformation
This should be mapped to "X400-Trace:", as for the
delivery report.
これは、「以下をX400たどる」ために配送レポートのように写像されるべきです。
5.4.4. Status Report
5.4.4. 現状報告
The entire status report is mapped into the body of the RFC 822
message, in the same manner as for a Delivery Report. An
appropriate "Subject:" field should be generated. As status
reports cannot be requested from the RFC 822 world, the mapping
is not likely to be used a great deal.
全体の現状報告はRFC822メッセージのボディーに写像されます、Delivery Reportのような同じ方法で。 適切な「Subject:」 分野は発生するべきです。 RFC822世界から現状報告を要求できないので、マッピングは大いに使用されそうにはありません。
5.4.5. IP Message
5.4.5. IPメッセージ
The P1.UMPDUEnvelope pro-forma specification ensures all the
822-P1 information, and a minimal (legal) RFC 822 message. The
mappings and actions for the P2.Heading components are now
described. Basically, these are interpreted as actions and/or
mappings into RFC 822 fields. The following mappings are
specified:
P1.UMPDUEnvelopeの形式上の仕様はすべての822-P1情報、および最小量(法的な)のRFC822メッセージを確実にします。 P2.Headingの部品のためのマッピングと動作は現在、説明されます。 基本的に、これらは動作、そして/または、マッピングとしてRFC822分野に解釈されます。 以下のマッピングは指定されます:
P2.IPMessageID
P2.IPMessageID
This is mapped to the field "Message-ID:", according to
section 4.
これがその分野に写像される、「Message ID:」、セクション4
P2.Heading.originator
P2.Heading.originator
If P2.Heading.authorisingUsers is present this is mapped
to Sender:, if not to From:.
P2.Heading.authorisingUsersが存在しているなら、これはSenderに写像されます。: From:に。
P2.Heading.authorisingUsers
P2.Heading.authorisingUsers
Mapped to From:.
From:に写像されます。
P2.Heading.primaryRecipients
P2.Heading.primaryRecipients
Mapped to To:.
To:に写像されます。
Kille [Page 53]
Kille[53ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
P2.Heading.copyRecipients
P2.Heading.copyRecipients
Mapped to Cc:.
Cc:に写像されます。
P2.Heading.blindCopyRecipients
P2.Heading.blindCopyRecipients
Mapped to Bcc:.
Bcc:に写像されます。
P2.Heading.inReplyTo
P2.Heading.inReplyTo
Mapped to In-Reply-To:.
以下に対して写像されます。
P2.Heading.obsoletes
P2.Heading.obsoletes
Mapped to the extended RFC 822 field "Obsoletes:"
拡張RFC822に写像されて、分野は「以下を時代遅れにします」。
P2.Heading.crossReferences
P2.Heading.crossReferences
Mapped to References:.
参照に写像される:
P2.Heading.subject
P2.Heading.subject
Mapped to subject. The contents are converted to ASCII
(as defined in chapter 3). Any CRLF are not mapped, but
are used as points at which the subject field must be
folded. line.
対象に写像されます。 内容はASCIIに変換されます(第3章で定義されるように)。 どんなCRLFも写像されませんが、対象の分野を折り重ねなければならないポイントとして使用されます。立ち並んでください。
P2.Heading.expiryDate
P2.Heading.expiryDate
Mapped to the extended RFC 822 field "Expiry-Date:".
「以下と満期でデートしてください。」拡張RFC822分野に写像されて、
P2.Heading.replyBy
P2.Heading.replyBy
Mapped to the extended RFC 822 field "Reply-By:".
「返答してください。」拡張RFC822分野に写像されて、
P2.Heading.replyToUsers
P2.Heading.replyToUsers
Mapped to Reply-To:.
Reply-Toに写像されます。
P2.Heading.importance
P2.Heading.importance
Mapped to the extended RFC 822 field "Importance:".
拡張RFC822分野に写像される、「重要性:」
P2.Heading.sensitivity
P2.Heading.sensitivity
Mapped to the extended RFC 822 field "Sensitivity:".
拡張RFC822分野に写像される、「感度:」
Kille [Page 54]
Kille[54ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
P2.Heading.autoforwarded
P2.Heading.autoforwarded
If it is set to FALSE, it is simply mapped to the
extended RFC 822 field "Autoforwarded:". If this is set
to TRUE, the P2.Body does not consist of a single
P2.ForwardedIPMessage, then there is an X.400 error, and
the message should be bounced. Otherwise the following
steps are taken.
FALSEに設定されるなら、それが単に拡張RFC822分野に写像される、「Autoforwarded:」 これがTRUEに設定されるなら、P2.Bodyは独身のP2.ForwardedIPMessageから成りません、そして、次に、X.400誤りがあります、そして、メッセージは弾むべきです。 さもなければ、以下の方法を取ります。
1. The mappings for all of the message, except the
body part are completed.
1. メッセージのすべてのためのマッピングであり、ボディーを除いて、部分は完成します。
2. Prepend each RFC 822 fieldname with the string
"Autoforwarded-". Mapped to the extended RFC 822
field "Autoforwarded:".
2. 各RFC822がストリング"Autoforwarded"と共にfieldnameするPrepend。 拡張RFC822分野に写像される、「Autoforwarded:」
3. Add the field "Autoforwarded:" with value TRUE.
3. 分野を加えてください、「Autoforwarded:」 値のTRUEと共に。
4. Convert the syntax of the P2.ForwardedIPMessage to
generate the remaining RFC 822 fields.
4. P2.ForwardedIPMessageの構文を変換して、残っているRFC822分野を発生させてください。
The P2.Body is mapped into the RFC 822 message body. Each
P2.BodyPart is converted to ASCII. If the P2.Body contains a
P2.BodyPart not listed here, the entire message should be
rejected. If there are exactly two P2.IA5Text body parts, and
the first line of the first is "RFC-822-Headers:", then the
rest of this first body part should be treated as additional
header information for the RFC 822 message. If there is an
"In-Reply-To:" field, this should be used to replace any
generated In-Reply-To: field.
P2.BodyはRFC822メッセージボディーに写像されます。 各P2.BodyPartはASCIIに変換されます。 P2.Bodyがここに記載されなかったP2.BodyPartを含んでいるなら、全体のメッセージは拒絶されるべきです。 2P2.IA5Textがまさにあれば身体の部分、および1つの番目ものの最初の線がそうである、「RFC822ヘッダー:」、そして、この最初の身体の部分の残りはRFCのための追加ヘッダー情報として扱われた822メッセージがそうするべきです。 「以下に対して」があれば 分野、これは、どんな発生しているIn-Reply-Toも取り替えるのに使用されるべきです。 さばきます。
In other cases of multiple P2.BodyPart, the mapping defined by
Rose and Stefferud in [Rose85b], should be used to separate the
P2.BodyParts in the single RFC 822 message body.
倍数の他の場合では、P2.BodyPart([Rose85b]でローズとStefferudによって定義されたマッピング)は、単一のRFC822メッセージボディーでP2.BodyPartsを切り離すのに使用されるべきです。
Individual body parts are mapped as follows:
個々の身体の部分は以下の通り写像されます:
P2.IA5Text
P2.IA5Text
The mapping is trivial.
マッピングは些細です。
P2.TTX
P2.TTX
If any P1.Teletex.NonBasicParams are set, the message
should be rejected. Otherwise, it should be converted to
ASCII according to chapter 3.
何かP1.Teletex.NonBasicParamsが用意ができているなら、メッセージは拒絶されるべきです。 さもなければ、第3章に従って、それはASCIIに変換されるべきです。
Kille [Page 55]
Kille[55ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
P2.SFD
P2.SFD
An SFD should be converted to ASCII as if it was being
rendered on an 79 column ASCII only VDU. It seems likely
that many gateways will not support this conversion. In
these cases, the message should be rejected.
まるでそれが79で唯一のコラムASCII VDUにレンダリングされているかのようにSFDはASCIIに変換されるべきです。 この変換は多くのゲートウェイは支持されそうにないでしょう。 これらの場合では、メッセージは拒絶されるべきです。
P2.ForwardedIPMessage
P2.ForwardedIPMessage
The P2.ForwardedIPMessage.delivery and
P2.ForwardedIPMessage.DeliveryInformation are
discarded <9>. The IM-UAPDU should have its syntax
mapped (recursively) according to this gatewaying
specification. Clearly, it makes no sense to apply any
of the actions defined here.
P2.ForwardedIPMessage.deliveryとP2.ForwardedIPMessage.DeliveryInformationは捨てられた<9>です。 これに従って、IM-UAPDUは、仕様をgatewayingしながら、構文を写像させるはずです(再帰的に)。 明確に、それはここで定義された動作のどれかを適用する意味に全くなりません。
Kille [Page 56]
Kille[56ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
Appendix A -- Quoted String Encodings
付録A--引用文字列Encodings
This Appendix describes a quoting mechanism which may be used to allow general interworking between RFC 822, and variants of RFC 822 which do not support 822.quoted-string. This is important, as the basic X.400 <-> RFC 822 mapping makes use of 822.quoted-string.
このAppendixは822.quoted-stringを支持しないRFC822と、RFC822の異形の間の一般的な織り込むことを許すのに使用されるかもしれない引用メカニズムについて説明します。 基本的なX.400<->RFC822マッピングが822.quoted-stringを利用するとき、これは重要です。
1. ASCII <-> 822.atom
1. ASCII<->822.atom
The following EBNF is specified.
以下のEBNFは指定されます。
atom-encoded = *( a-char / a-encoded-char )
a-char = <any CHAR except specials, SPACE,
CTL, "_", and "#">
a-encoded-char = "_" ; (space)
/ "#u#" ; (_)
/ "#l#" ; <(>
/ "#r#" ; <)>
/ "#m#" ; (,)
/ "#c#" ; (:)
/ "#b#" ; (\)
/ "#h#" ; (#)
/ "#e#" ; ($=)
/ "#s#" ; ($/)
/ "#" 3DIGIT "#"
原子でコード化された=*(aが炭をa-炭/コード化している)a-炭は<と等しいです。そして、特別番組、SPACE、CTL、"_"をどんなCHARも除く、「#「>コード化された炭="_"」 (スペース) 「/」#u#、」、。 (_) 「/」#l#、」、。 「<、(>/、」 #r#、」、;、<)「>/」#m#、」、。 (,) 「/」#c#、」、。 (:) 「/」#b#、」、。 (\) 「/」#h#、」、。 (#) 「/」#e#、」、。 ($=) 「/」#s#、」、。 ($/) /「#」3DIGIT「#」
NOTE: There are two encodings of double characters. This is so
that systems using this encoding, do not also need to know about
the "$" quoting mechanism defined in chapter 4.
以下に注意してください。 二重人格の2encodingsがあります。 これがそうであるので、そのシステムがこのコード化を使用して、またでない、第4章で定義されたメカニズムを引用しながら「$」に関して知る必要性をしてください。
The 822.3DIGIT in EBNF.a-encoded-char must have range 0-127
(Decimal), and is interpreted in decimal as the corresponding
ASCII character. The choice of special abbreviations (as opposed
to octal encoding) provided is based on the manner in which this
mapping is most frequently used: encoding PrintableString
components of O/R names as atom. Therefore, there are special
encodings for each of the PrintableString characters not in
EBNF.a-char, except ".". Space is given a single character
encoding, due to its (expected) frequency of use, and backslash as
the RFC 822 single quote character.
EBNF.aが炭をコード化していたところの822.3DIGITは範囲0-127(小数)を持たなければならなくて、対応するASCII文字として小数で解釈されます。 提供された特別な略語(8進コード化と対照的に)の選択はこのマッピングが最も頻繁に使用される方法に基づいています: 原子としてO/R名のPrintableStringの部品をコード化します。 「したがって、PrintableStringキャラクタ各人のための特別なencodingsがどんなEBNF.a-炭でもなくて、除いてください」、」 単一のキャラクタコード化をスペースに与えます、使用の(予想されます)頻度、およびRFC822の単独の引用文字としてのバックスラッシュのため。
To encode (ASCII -> atom): all EBNF.a-char are used directly and
all other CHAR are encoded as EBNF.a-encoded-char. To decode
(822.atom -> ASCII): if 822.atom can be parsed as
EBNF.encoded-atom reverse the previous mapping. If it cannot be
so parsed, map the characters directly.
(ASCII->原子)をコード化するために: EBNF.aすべて焦げるのは、EBNF.aが炭をコード化していたとして他の中古のCHARがコード化されるということです。 (822.atom->ASCII)を解読するために: EBNF.encoded-原子として822.atomを分析できるなら、前のマッピングを逆にしてください。 それをそう分析できないなら、直接キャラクタを写像してください。
Kille [Page 57]
Kille[57ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
2. 822.local-part <-> ASCII
2. 822.の地方の部分<->ASCII
A related transformation is for 822.local-part (or other element
defined as '822.word ("." 822.word)') where not 822.quoted-text is
used. To encode (ASCII -> 822.local-part), all EBNF.a-char and
"." are used directly and all other 822.CHAR are encoded as
EBNF.a-encoded-char. To decode (822.local-part -> ASCII), first
attempt to parse 822.local-part as '822.atom *("." 822.atom)'. If
this fails, or if each 822.atom cannot be parsed as
EBNF.atom-encoded then map each character directly. Otherwise map
each "." directly, and each atom as in the previous section.
822.local-部分には関連する変化がある、('822.wordと定義された他の要素、(「. 」 822.word、)、'、)、822.quoted-テキストでないのが使用されているところ。 そして、「エンコード(ASCII->822.local-部分)、すべてのEBNF.a-焦げ、」 . 」 822.CHARがコード化される中古の他はコード化されたEBNF.aが焦げていますか? (822.local-部分->ASCII)を解読するために、最初に'822.atom*として822.local-部分を分析するのを試みてください、(「. 」 822.atom、)、' EBNF.atomによってコード化されるとして各822.atomを分析できないならこれが失敗するなら、直接各キャラクタを写像してください。 「さもなければ、それぞれを写像してください」、」 直接、そして、同じくらい中の前が区分する各原子。
There are places where it is needed to convert between
PrintableString or IA5Text (X.400), and 822.word (RFC 822). word
may be encoded as 822.atom (which has a restricted character set)
or as 822.quoted-string, which can handle all ASCII characters.
If 822.quoted-string is used, clearly the mappings for
PrintableString defined in Chapter 3 provide a straightforward
mapping. However, some RFC 822 based networks cannot handle the
822.quoted-string format in all cases. This Appendix is for use
in these cases. The major requirement for this mapping is the
UNIX world, but it may well be needed in other places.
場所がそれがPrintableStringかIA5Text(X.400)と、822.word(RFC822)の間で変換するのに必要であるところにあります。単語は822.atom(制限された文字の組を持っている)として、または、822.quoted-stringとしてコード化されるかもしれません。822.quoted-stringはすべてのASCII文字を扱うことができます。 822.quoted-stringが使用されているなら、明確に、第3章で定義されたPrintableStringのためのマッピングは簡単なマッピングを提供します。 しかしながら、ベースのRFC822がネットワークでつなぐ或るものはすべての場合における822.quoted-string形式を扱うことができません。 このAppendixはこれらの場合における使用のためのものです。 このマッピングのための主要な要件はUNIX世界ですが、それがたぶん他の場所で必要でしょう。
These mappings are somewhat artificial, and their usage is
discouraged, except in cases where there is no alternative.
これらのマッピングはいくらか人工です、そして、代替手段が全くないケースの中を除いて、それらの用法はがっかりしています。
Kille [Page 58]
Kille[58ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
Appendix B -- Mappings Specific to JNT Mail
付録B--JNTメールに特定のマッピング
This Appendix is specific to the JNT Mail Protocol. It describes specific changes in the context of this protocol. Addressing is not discussed here, as it is covered in Appendix A.
このAppendixはJNTメールプロトコルに特定です。 それはこのプロトコルの文脈における特定の変化について説明します。 それがAppendix Aで覆われているとき、ここでアドレシングについて議論しません。
1. Introduction
1. 序論
There are four aspects of a gateway which are JNT Mail Specific,
in addition to those relating to addressing. These are each given
a section of this appendix.
JNTメールSpecificであるゲートウェイの4つの局面がアドレシングに関連するものに加えています。 この付録のセクションを考えて、これらはそれぞれです。
2. Acknowledge-To:
2. To:を承認します。
This field has no direct functional equivalent in X.400. However,
it can be supported to an extent, and can be used to improve X.400
support.
この分野はX.400にどんなダイレクト機能的な同等物も持っていません。 しかしながら、それを程度まで支持できて、X.400サポートを改良するのに使用できます。
When going from JNT Mail to X.400, the User Report Request bits of
each P1.RecipientInfo.perRecipientFlag should be set to confirmed.
If there is more that one address in the Acknowledge-To: field, or
if the one address is not equivalent to the 822-P1 return address,
then:
JNTメールからX.400まで行くとき、それぞれのP1.RecipientInfo.perRecipientFlagのUser Report Requestビットは確認されるのに設定されるべきです。 1つがAcknowledge-To:に記述する以上があれば 分野か次に、1つのアドレスが822-P1返送先に同等でないかどうか、:
a. Acknowledgement(s) should be generated by the gateway.
The text of these acknowledgements should indicate that
they are generated by the gateway.
a。 承認はゲートウェイで発生するべきです。 これらの承認のテキストは、それらがゲートウェイで発生するのを示すべきです。
b. The Acknowledge-To: field should also be passed in the
first P2.BodyPart.
b。 To:を承認します。 また、野原は最初のP2.BodyPartを通り過ぎられるべきです。
When going from X.400 to JNT Mail, in cases where
P1.RecipientInfo.perRecipientFlag has the user bits set to
confirmed the copy of the message to that recipient should have an
Acknowledge-To: field containing the P.UMPDUEnvelope.originator.
No attempt should be made to map Receipt notification requests
onto Acknowledge-To:. This is because no association can be
guaranteed between P2 and P1 level addressing information.
X.400からJNTメールまで行くとき、P1.RecipientInfo.perRecipientFlagがユーザビットを確認されるのに設定させる場合では、その受取人へのメッセージのコピーはAcknowledge-To:を持っているはずです。 P.UMPDUEnvelope.originatorを含む分野。 Receipt通知要求をAcknowledge-To:に写像するのを試みを全くするべきではありません。情報を記述するP2とP1レベルの間で協会を全く保証できないので、これはそうです。
3. Trace
3. 跡
JNT Mail trace uses the Via: syntax. When going from JNT Mail to
X.400, the following mapping onto P1.TraceInformation is used.
JNTメール跡はViaを使用します: 構文。 JNTメールからX.400まで行くとき、P1.TraceInformationへの以下のマッピングは使用されています。
P1.DomainSuppliedInfo.action is set to relayed.
P1.DomainSuppliedInfo.actionはリレーされるのに用意ができています。
P1.DomainSuppliedInfo.arrival is set to the date-time component
P1.DomainSuppliedInfo.arrivalは日付-時間コンポーネントに用意ができています。
Kille [Page 59]
Kille[59ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
of the Via: field. P1.DomainSuppliedInfo.previous has
P1.CountryName as a null string, and
P1.AdministrationDomainName as the domain specified in the Via:
field.
P1.TraceInformation.GlobalDomainIdentifier has P1.CountryName
as a null string, and P1.AdministrationDomainName as any
commented information in the Via: field. For example:
以下を通って さばきます。 P1.DomainSuppliedInfo.previousはヌルストリングとしてP1.CountryNameを持っていて、Viaで指定されたドメインとしてP1.AdministrationDomainNameを持っています: さばきます。 P1.TraceInformation.GlobalDomainIdentifierはヌルストリングとしてP1.CountryNameを持っていて、Viaのどんな論評された情報としてもP1.AdministrationDomainNameを持っています: さばきます。 例えば:
Via: UK.AC.Edinburgh ; 17 Jun 85 9:15:29 BST (EMAS V7)
以下を通って UK.AC.Edinburgh。 1985年6月17日のベーリング標準時9時15分29秒(エマスV7)
maps to -
地図、-
P1.GlobalDomainIdentifier
CountryName = ""
AdministrationDomainName = "(EMAS V7)"
P1.DomainSuppliedInfo
arrival = 17 Jun 85 9:15:29 BST
action = relayed
previous
CountryName = ""
AdministrationDomainName = "UK.AC.Edinburgh"
P1.GlobalDomainIdentifier CountryNameが等しい、「「「(エマスV7)」P1.DomainSuppliedInfo到着=1985年6月17日ベーリング標準時9時15分29秒動作AdministrationDomainName==が前のCountryName=をリレーした、「「AdministrationDomainNameは"UK.AC.Edinburgh"と等しいです」。
4. Timezone specification
4. タイムゾーン仕様
The extended syntax of zone defined in the JNT Mail Protocol
should be used in the mapping of UTCTime defined in chapter 3.
JNTメールプロトコルで定義されたゾーンの拡張構文は第3章で定義されたUTCTimeに関するマッピングで使用されるべきです。
5. Lack of separate 822-P1 originator specification
5. 別々の822-P1創始者仕様の不足
In JNT Mail the default mapping of the P1.MPDUEnvelope.originator
is to the Sender: field. This can cause a problem if the mapping
of P2.Heading has already generated a Sender: field. To overcome
this, new extended JNT Mail field is defined. This is chosen to
align with the JNT recommendation for interworking with full
RFC 822 systems [Kille84b].
JNTメールには、SenderにはP1.MPDUEnvelope.originatorに関するデフォルトマッピングがあります: さばきます。 P2.Headingに関するマッピングがSenderを既に発生させたなら、これは問題を引き起こす場合があります: さばきます。 これに打ち勝つために、新しい拡張JNTメール分野は定義されます。 これは、完全なRFC822と共にシステムが[Kille84b]であると織り込むためのJNT推薦に並ぶために選ばれています。
original-sender = "Original-Sender" ":" mailbox
「元の送り主は「元の送り主」と等しい」:、」 メールボックス
If an IPM has no P2.heading.authorisingUsers component and
P2.Heading.originator.ORName is different from
P1.UMPDUEnvelope.originator, map P1.MPDUEnvelope.originator onto
the Sender: field.
IPMにはP2.heading.authorisingUsersの部品が全くなくて、P2.Heading.originator.ORNameがP1.UMPDUEnvelope.originatorと異なるなら、P1.MPDUEnvelope.originatorをSenderに写像してください: さばきます。
If an IPM has a P2.heading.authorisingUsers component, and
P2.Heading.originator.ORName is different from
P1.UMPDUEnvelope.originator, P1.MPDUEnvelpoe.originator should be
IPMにはP2.heading.authorisingUsersの部品があって、P2.Heading.originator.ORNameがP1.UMPDUEnvelope.originatorと異なるなら、P1.MPDUEnvelpoe.originatorは異なるべきです。
Kille [Page 60]
Kille[60ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
mapped onto the Sender: field, and P2.Heading.originator mapped
onto the Original-Sender: field.
Senderに写像される: 分野、およびOriginal-送付者に写像されたP2.Heading.originator: さばきます。
In other cases the P1.MPDUEnvelope.Originator is already correctly
represented.
他の場合では、P1.MPDUEnvelope.Originatorは正しく既に表されます。
Note that in some pathological cases, this mapping is
asymmetrical.
いくつかの病理学的な場合では、このマッピングが非対称的であることに注意してください。
Kille [Page 61]
Kille[61ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
Appendix C -- Mappings Specific to Internet Mail
付録C--インターネットメールに特定のマッピング
The Simple Mail Transfer Protocol [Postel82a] is used in the ARPA-Internet, and in any network following the US DoD standards for internetwork protocols. This appendix is specific to those hosts which use SMTP to exchange mail.
シンプルメールトランスファプロトコル[Postel82a]はARPA-インターネット、およびインターネットワークプロトコルの米国DoD規格に続くどんなネットワークにも使用されます。 それらのホストにとって、この付録は特定です(メールを交換するのにSMTPを使用します)。
1. Mapping between O/R names and SMTP addresses
1. O/Rの名前とSMTPの間でアドレスを写像します。
The mappings of Chapter 4 are to be used.
第4章のマッピングは使用されていることです。
2. Use of the ARPA Domain System
2. アルパドメインシステムの使用
Whenever possible, domain-qualified addresses should be be used to
specify encoded O/R names. These domain encodings naturally
should be independent of any routing information.
可能で、ドメインで適切なアドレスがそうであるべきであるときはいつも、使用されて、コード化されたO/R名を指定してください。 これらのドメインencodingsはどんなルーティング情報からも自然に独立しているべきです。
3. Identification of gateways
3. ゲートウェイの識別
The ARPA-Internet Network Information Center (NIC) will maintain a
list of registered X.400 gateways in the ARPA Internet.
ARPA-インターネットNetworkインフォメーション・センター(NIC)はARPAインターネットの登録されたX.400ゲートウェイのリストを維持するでしょう。
Kille [Page 62]
Kille[62ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
Appendix D -- Mappings Specific to Phonenet Mail
付録D--Phonenetメールに特定のマッピング
There are currently no mappings specific to Phonenet Mail.
現在、Phonenetメールに特定のどんなマッピングもありません。
Kille [Page 63]
Kille[63ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
Appendix E -- Mappings Specific to UUCP Mail
付録E--UUCPメールに特定のマッピング
Gatewaying of UUCP and X.400 is handled by first gatewaying the UUCP address into RFC 822 syntax (using RFC 976) [Horton86a] and then gatewaying the resulting RFC 822 address into X.400. For example, an X.400 address
UUCPとX.400のGatewayingは、RFC822構文(RFC976を使用します)[Horton86a]にUUCPアドレスをgatewayingして、次に、結果として起こるRFC822アドレスをX.400にgatewayingしながら、最初にによって扱われます。 例えば、X.400アドレス
Country US
Organization Xerox
Personal Name John Smith
国の米国組織のゼロックスの個人名ジョン・スミス
might be expressed from UUCP as
UUCPから言い表されるかもしれません。
inthop!gate!gatehost.COM!/C=US/O=Xerox/PN=John.Smith/
inthop!ゲート!gatehost.COM!/Cは米国/O=Xerox/PN=John.Smith/と等しいです。
(assuming gate is a UUCP-ARPA gateway and gatehost.COM is an ARPA-X.400 gateway) or
または(ゲートがUUCP-ARPAゲートウェイであり、gatehost.COMがARPA-X.400ゲートウェイであると仮定します)。
inthop!gate!Xerox.COM!John.Smith
inthop!ゲート!Xerox.COM!John.Smith
(assuming that Xerox.COM and /C=US/O=Xerox/ are equivalent.)
(Xerox.COMと/C=米国/O=ゼロックス/が同等であると仮定します。)
In the other direction, a UUCP address Smith@ATT.COM, integrated into 822, would be handled as any other 822 address. A non-integrated address such as inthop!dest!user might be handled thought a pair of gateways:
もう片方の方向に、822と統合されたUUCPアドレス Smith@ATT.COM はいかなる他の822アドレスとしても扱われるでしょう。 1組のゲートウェイであると思われて、inthop!dest!ユーザなどの非統合しているアドレスは扱われるかもしれません:
Country US
ADMD ATT
PRMD ARPA
Organization GateOrg
RFC-822 inthop!dest!user@gatehost.COM
国の米国ADMD ATT PRMDアルパ組織GateOrg RFC-822 inthop!dest!user@gatehost.COM
or through a single X.400 to UUCP gateway:
または、aを通して、UUCPゲートウェイにX.400を選抜してください:
Country US
ADMD ATT
PRMD UUCP
Organization GateOrg
UUCP inthop!dest!user
国のUS ADMD ATT PRMD UUCP Organization GateOrg UUCP inthop!dest!ユーザ
Kille [Page 64]
Kille[64ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
Appendix F -- Format of Address Mapping Tables
付録F--アドレス変換テーブルの形式
There is a need to specify the association between the domain and X.400 namespaces described in 4.2.1. This is defined as a table syntax, but the syntax is defined in a manner which makes it suitable for use with domain nameservers (such as the DARPA Domain nameservers or the UK NRS). The symmetry of the mapping is not clear, so a separate table is specified for each direction. For domain -> X.400:
4.2で.1に説明されたドメインとX.400名前空間との協会を指定する必要があります。 これはテーブルシンタックスと定義されますが、構文はそれをドメインネームサーバ(DARPA DomainネームサーバかUK NRSなどの)によって使用に適するようにする方法で定義されます。 マッピングの対称が明確でないので、別々のテーブルは各方向に指定されます。 ドメイン->X.400に:
domain-syntax "#" dmn-orname "#"
ドメイン構文「#」dmn-orname「#」
For example:
例えば:
AC.UK#PRMD$DES.ADMD$BT.C$UK#
XEROX.COM#O$Xerox.ADMD$ATT.C$US#
AC.UK#PRMD$DES.ADMD$BT.C$イギリス#XEROX.COM#O$Xerox.ADMD$ATT.C$U.S.#
For X.400 -> domain:
X.400->ドメインに:
dmn-orname "#" domain-syntax "#"
dmn-orname「#」ドメイン構文「#」
EBNF.domain-syntax will be interpreted according to RFC 920. EBNF.dmn-orname will have components ordered as defined in section 4.2.1, and with the most significant component on the RHS.
RFC920によると、EBNF.domain-構文は解釈されるでしょう。 EBNF.dmn-ornameはセクション4.2.1、およびRHSで最も重要なコンポーネントで定義されるようにコンポーネントを注文させるでしょう。
Kille [Page 65]
Kille[65ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
References
参照
Bonacker85a.
Bonacker85a。
K.H. Bonacker, U. Pankoke-Babatz, and H. Santo, "EAN - Conformity
to X.400 and DFN-Pflichtenheft," GMD (Gesellschaft fur Mathematik
und Datenverarbeitung) report, June 1985.
K.H.Bonacker、U.Pankoke-Babatz、およびH.サント、「EAN--、X.400とDFN-Pflichtenheftとの適合性、」、GMD(利益社会毛皮Mathematik und Datenverarbeitung)は報告します、6月1985
CCITT84a.
CCITT84a。
CCITT SG 5/VII, "Recommendations X.400," Message Handling Systems:
System Model - Service Elements, October 1984.
CCITT SG5/VII、「推薦X.400」メッセージハンドリングシステム: システムモデル--Elements、1984年10月を修理してください。
CCITT84b.
CCITT84b。
CCITT SG 5/VII, "Recommendations X.411," Message Handling Systems:
Message Transfer Layer, October 1984.
CCITT SG5/VII、「推薦X.411」メッセージハンドリングシステム: 1984年10月のメッセージ転送層。
CCITT84c.
CCITT84c。
CCITT SG 5/VII, "Recommendations X.420," Message Handling Systems:
Interpersonal Messaging User Agent Layer, October 1984.
CCITT SG5/VII、「推薦X.420」メッセージハンドリングシステム: 1984年10月の個人間のメッセージングユーザエージェント層。
CCITT84d.
CCITT84d。
CCITT SG 5/VII, "Recommendations X.409," Message Handling Systems:
Presentation Transfer Syntax and Notation, October 1984.
CCITT SG5/VII、「推薦X.409」メッセージハンドリングシステム: プレゼンテーション転送構文と記法、1984年10月。
CEN/CENELEC/85a.
CEN/CENELEC/85a。
CEN/CENELEC/Information Technology/Working Group on Private
Message Handling Systems, "FUNCTIONAL STANDARD A/3222,"
CEN/CLC/IT/WG/PMHS N 17, October 1985.
1985年10月のプライベート・メッセージ取り扱いシステム、「機能標準A/3222」、CEN/CLC/IT/WG/PMHS N17のCEN/CENELEC/情報技術/作業部会。
Crocker82a.
Crocker82a。
D.H. Crocker, "Standard of the Format of ARPA Internet Text
Messages," RFC 822, August 1982.
D.H.クロッカー、「アルパインターネットテキスト・メッセージの形式の規格」、RFC822、1982年8月。
Horton85a.
Horton85a。
M.R. Horton, "Draft Standard for ARPA/MHS Addressing Gateways,"
AT&T Bell Laboratories, October 1985.
M.R.ホートン、「ゲートウェイを記述するアルパ/MHSの草稿規格」、AT&Tベル研究所、1985年10月。
Kille [Page 66]
Kille[66ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
Horton86a.
Horton86a。
M.R. Horton, "UUCP Mail Interchange Format Standard", RFC 976,
February 1986.
M.R.ホートン、「UUCPは置き換え形式規格を郵送する」RFC976、1986年2月。
ICL84a.
ICL84a。
ICL, "Comparison of service elements of Grey Book Mail and X.400,"
Mailgroup Note 18: Extract from unpublished report for ITSU
(Information Technology Standards Unit), July 1984.
ICL、「Grey BookメールとX.400のサービス要素の比較」、Mailgroup Note18: 非公開報告から、ITSUのために(情報Technology Standards Unit)、1984年7月を抽出してください。
Kille84a.
Kille84a。
S.E. Kille, (editor), JNT Mail Protocol (revision 1.0), Joint
Network Team, Rutherford Appleton Laboratory, March 1984.
東南Kille、(エディタ)、JNTメールプロトコル(改正1.0)、共同ネットワークチーム、ラザフォードアップルトーン研究所、1984年3月。
Kille84b.
Kille84b。
S.E. Kille, "Gatewaying between RFC 822 and JNT Mail," JNT
Mailgroup Note 15, May 1984.
東南Kille(「RFC822とJNTメールの間のGatewaying」、JNT Mailgroup注意15)は1984がそうするかもしれません。
Kille86a.
Kille86a。
S.E. Kille, "O/R Names in the UK Academic Community," UK Working
Document, March 1986.
東南Kille(「イギリスのアカデミー会員社会のO/R名」、イギリスの働くドキュメント)は1986を行進させます。
Larmouth83a.
Larmouth83a。
J. Larmouth, "JNT Name Registration Technical Guide," Salford
University Computer Centre, April 1983.
J.Larmouth、「JNT名前の登録の技術ガイド」、ソルフォード大学コンピュータセンター、1983年4月。
Neufeld85a.
Neufeld85a。
G. Neufeld, J. Demco, B. Hilpert, and R. Sample, "EAN: an X.400
message system," in Second International Symposium on Computer
Message Systems, Washington, pp. 1-13, North Holland,
September 1985.
G.ニューフェルド、Demco、B.Hilpert、およびR.が抽出するJ.、「EAN:」 コンピュータMessage Systems、ワシントン、ページのSecondの国際Symposiumの「X.400メッセージシステム」 1-13 1985年9月の北のオランダ。
Postel82a.
Postel82a。
J. Postel, "Simple Mail Transfer Protocol," RFC 821, August 1982.
J.ポステル、「簡単なメール転送プロトコル」、RFC821、1982年8月。
Postel84a.
Postel84a。
J. Postel and J. Reynolds, "Domain Requirements," RFC 920,
October 1984.
J.ポステルとJ.レイノルズ、「ドメイン要求性」、RFC920、1984年10月。
Kille [Page 67]
Kille[67ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
Rose85a.
Rose85a。
M.T. Rose, "Mapping Service Elements between ARPA and MHS," Draft
proposal, October 1985.
「アルパとMHSの間でService Elementsを写像し」て、M.T.が上昇して、Draftが提案であり、10月は1985です。
Rose85b.
Rose85b。
M.T. Rose and E.A. Stefferud, "Proposed Standard for Message
Encapsulation," RFC 934, January 1985.
M.T.ローズとE.A.Stefferud、「メッセージカプセル化の提案された標準」、RFC934、1985年1月。
Kille [Page 68]
Kille[68ページ]
RFC 987 June 1986 Mapping between X.400 and RFC 822
X.400とRFC822の間のRFC987 1986年6月のマッピング
Notes:
注意:
<0> UNIX is a trademark of Bell Laboratories.
<0>UNIXはベル研究所の商標です。
<1> The term gateway is used to describe a component performing the
protocol mappings between RFC 822 and X.400. This is standard
usage amongst mail implementors, but should be noted carefully
by transport and network service implementors. (Sometime called
a "mail relay".)
用語ゲートウェイが使用されている<1>はRFC822とX.400の間のプロトコルマッピングを実行するコンポーネントについて説明します。 これは、メール作成者の中の標準的用法ですが、輸送とネットワーク・サービス作成者によって慎重に注意されるべきです。 (「メール中継」はいつか、呼びました。)
<2> If the remote protocol is JNT Mail, a notification may also be
sent by the recipient UA.
リモートが議定書を作るなら<2>がJNTメールである、また、通知は受取人UAによって送られるかもしれません。
<3> The asymmetry occurs where an ASCII string contains the sequence
EBNF.ps-encoded-char. This would be mapped directly to
PrintableString, but the reverse mapping would be to the value
implied by the sequence.
<3>、非対称はEBNF.psが炭をコード化していた状態でASCIIストリングが系列を含むところに起こります。 これは直接PrintableStringに写像されるでしょうが、系列によって含意された値には逆のマッピングがあるでしょう。
<4> It might be suggested that for reasons of elegance,
EBNF.ps-delim (left parenthesis) is encoded as
EBNF.ps-encoded-char. This is not done, as it it would never be
possible to represent a PrintableString containing the character
"(" in ASCII. This is because an "(" in ASCII would be mapped
to the encoding in PrintableString.
<4>、優雅の理由で、EBNF.psが炭をコード化していたとしてEBNF.ps-delim(左括弧)がコード化されることが提案されるかもしれません。 これが完了していなくて、またキャラクタを含むPrintableStringを表すのがそれのように決して可能でない、「(「中にASCIIこれがある、「(「ASCIIでは、PrintableStringでのコード化に写像されるでしょう」。
<5> In practice, a gateway will need to parse various illegal
variants on 822.date-time. In cases where 822.date-time cannot
be parsed, it is recommended that the derived UTCTime is set to
the value at the time of translation.
実際には<5>、ゲートウェイは、822.date-時に様々な不法な異形を分析する必要があるでしょう。 822.date-時間を分析できない場合では、派生しているUTCTimeが翻訳時点で値に用意ができているのは、お勧めです。
<6> P2.ORname is defined as P1.ORName.
<6>P2.ORnameはP1.ORNameと定義されます。
<7> This recommendation may change in the light of CCITT or
CEN/CENELEC guidelines on the use of initials.
この推薦がイニシャルの使用に関するCCITTかCEN/CENELECガイドラインの見地から変えるかもしれない<7>。
<8> It would be possible to use a ForwardedIPMessage for these
fields, but the semantics are (arguably) slightly different, and
it is probably not worth the effort.
意味論は(論証上)わずかに異なっています、そして、それが可能である<8>はこれらの分野にForwardedIPMessageを使用しますが、それはたぶん努力の価値がありません。
<9> Although this violates chapter 1, part 4, principles 2 and 3, it
is suggested that this is justified by principle 1.
これですが、<9>は第1章に違反して、4、原則2と3を分けてください、そして、これが原則1によって正当化されることが提案されます。
Kille [Page 69]
Kille[69ページ]
一覧
スポンサーリンク
