draft-ietf-x400ops-mapsmail-01.txt   rfc1405.txt 
COSINE S2.2 Claudio Allocchio Network Working Group C. Allocchio
Draft v2.3 I.N.F.N. - Italy Request for Comments: 1405 I.N.F.N. - Italy
August 22, 1992 January 1993
Allocchio@elettra.trieste.it
Mapping between X.400(1984/1988) and Mail-11 (DECnet mail)
Status of this Memo:
This document describes a set of mappings which will
enable inter working between systems operating the CCITT X.400
(1984/1988) Recommendations on Message Handling Systems, and
systems running the Mail-11 (also known as DECnet mail) protocol.
The specifications are valid within DECnet Phase IV addressing and
routing scheme. The complete scenario of X.400 / RFC822 / Mail-11
is also considered, in order to cover the possible complex cases
arising in multiple gateway translations.
This document cover mainly the O/R address to DECnet from/to Mapping between X.400(1984/1988) and Mail-11 (DECnet mail)
address mapping (and vice versa); other mappings are based on
RFC1327 and its updates.
This document provides an experimental standard definition, and Status of this Memo
is expected to be revised after an initial test period.
Distribution is unlimited. This memo defines an Experimental Protocol for the Internet
community. Discussion and suggestions for improvement are requested.
Please refer to the current edition of the "IAB Official Protocol
Standards" for the standardization state and status of this protocol.
Distribution of this memo is unlimited.
This document is an Internet Draft. Internet Drafts are working Abstract
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six This document describes a set of mappings which will enable inter
months. Internet Drafts may be updated, replaced, or obsoleted working between systems operating the CCITT X.400 ( 1984 / 1988 )
by other documents at any time. It is not appropriate to use Recommendations on Message Handling Systems, and systems running the
Internet Drafts as reference material or to cite them other than Mail-11 (also known as DECnet mail) protocol. The specifications are
as a "working draft" or "work in progress." valid within DECnet Phase IV addressing and routing scheme.
Please check the I-D abstract listing contained in each Internet The complete scenario of X.400 / RFC822 / Mail-11 is also considered,
Draft directory to learn the current status of this or any other in order to cover the possible complex cases arising in multiple
Internet Draft. gateway translations.
Document Expiration Date This document covers mainly the O/R address to DECnet from/to address
mapping (and vice versa); other mappings are based on RFC 1327 and
its eventual future updates.
This document was submitted on September 23rd, 1992 and its This is a combined effort of COSINE S2.2, the RARE MSG Working Group,
validity will expire on March 23rd 1993. and the IETF X.400 Ops Working Group.
(c) notice: Chapter 1 - Introduction
Mail-11, DECnet, VMSmail, VAX/VMS, DEC are trademarks of Digital
Equipment Corporation; Jnet is a trademark of Joiner Inc.
Chapter 1 - Introduction 1.1. X.400
1.1. X.400 The standard referred shortly into this document as "X.400" relates
to the CCITT 1984 and 1988 X.400 Series Recommendations covering the
Message Oriented Text Interchange Service (MOTIS). This document
covers the Inter Personal Messaging System (IPMS) only.
The standard referred shortly into this document as 1.2. Mail-11
"X.400" relates to the CCITT 1984 and 1988 X.400 Series
Recommendations covering the Message Oriented Text Interchange
Service (MOTIS). This document covers the Inter Personal Messaging
System (IPMS) only.
1.2. Mail-11 Mail-11, also known as DECnet mail and often improperly referred as
VMSmail, is the proprietary protocol implemented by Digital Equipment
Corporation (DEC) to establish a real-time text messaging system
among systems implementing the DECnet Phase IV networking protocols.
Mail-11, also known as DECnet mail and often improperly 1.3. RFC822
referred as VMSmail, is the proprietary protocol implemented by
Digital Equipment Corporation (DEC) to establish a real-time text
messaging system among systems implementing the DECnet Phase IV
networking protocols.
1.3. RFC 822 RFC822 was defined as a standard for personal messaging systems
within the DARPA Internet and is now diffused on top of many
different message transfer protocols, like SMTP, UUCP, BITNET, JNT
Grey Book, CSnet. Its mapping with X.400 is fully described in
RFC1327. In this document we will try to consider its relations with
Mail-11, too.
RFC 822 was defined as a standard for personal messaging 1.4. The user community
systems within the DARPA Internet and is now diffused on top of
many different message transfer protocols, like SMTP, UUCP,
BITNET, JNT Grey Book, CSnet. Its mapping with X.400 is fully
described in RFC1327. In this document we will try to consider
its relations with Mail-11, too.
1.4. The user community. The community using X.400 messaging system is currently growing in
the whole world, but there is still a number of very large
communities using Mail-11 based messaging systems willing to
communicate easily with X.400 based Message Handling Systems. Among
these large DECnet based networks we can include the High Energy
Physics network (HEPnet) and the Space Physics Analysis Network
(SPAN).
The community using X.400 messaging system is currently These DECnet communities will in the future possibly migrate to
growing in the whole world, but there is still a number of very DECnet Phase V (DECnet-OSI) protocols, converting thus their
large communities using Mail-11 based messaging systems willing messaging systems to OSI specifications, i.e., merging into the X.400
to communicate easily with X.400 based Message Handling Systems. MHS; however the transition period could be long, and there could
Among these large DECnet based networks we can include the High always be some DECnet Phase IV communities around.
Energy Physics network (HEPnet) and the Space Physics Analysis
Network (SPAN).
The se DECnet communities will in the future possibly For these reasons a set of mapping rules covering conversion between
migrate to DECnet Phase V (DECnet-OSI) protocols, converting thus Mail-11 and X.400 is described in this document.
their messaging systems to OSI specifications, i.e. merging into
the X.400 MHS; however the transition period could be long, and
there could always be some DECnet Phase IV communities around.
For these reasons a set of mapping rules covering This document also covers the case of Mail-11 systems implementing
conversion between Mail-11 and X.400 is described in this the "foreign mail protocol" allowing Mail-11 to interface other mail
document. systems, including RFC822 based system.
This document also covers the case of Mail-11 systems Chapter 2 - Message Elements
implementing the "foreign mail protocol" allowing Mail-11 to
interface other mail systems, including RFC 822 based system.
Chapter 2 - Message Elements 2.1. Service Elements
2.1. Service Elements Mail-11 protocol offers a very restricted set of elements composing a
Inter Personal Message (IPM), whereas X.400 specifications support a
complex and large amount of service elements. Considering the case
where a message is relayed between two X.400 MHS via a DECnet network
this could result in a nearly complete loss of information. To
minimise this inconvenience most of X.400 service elements will be
mapped into Mail-11 text body parts. To consider also the case when a
message originates from a network implementing RFC822 protocols and
is relayed via Mail-11 to and X.400 MHS, the applied mapping from
X.400 service elements into Mail-11 text body part the rules
specified in RFC1327 and their updates will be used, producing an
RFC822-like header.
Mail-11 protocol offers a very restricted set of elements 2.2. Mail-11 service elements
composing a Inter Personal Message (IPM), whereas X.400
specifications support a complex and large amount of service
elements. Considering the case where a message is relayed between
two X.400 MHS via a DECnet network this could result in a nearly
complete loss of information. To minimise this inconvenience most
of X.400 service elements will be mapped into Mail-11 text body
parts. To consider also the case when a message originates from a
network implementing RFC 822 protocols and is relayed via Mail-11
to and X.400 MHS, the applied mapping from X.400 service elements
into Mail-11 text body part the rules specified in RFC1327 and
their updates will be used, producing an RFC822-like header.
2.2. Mail-11 service elements All envelope (P1) and header (P2) Mail-11 service elements are
supported in the conversion to X.400. Note that Mail-11 P1 is solely
composed by P1.From and P1.To, and any other Mail-11 element belongs
to Mail-11 P2:
All envelope (P1) and header (P2) Mail-11 service - P1.From
elements are supported in the conversion to X.400. Note that maps to P1.Originator
Mail-11 P1 is solely composed by P1.From and P1.To, and any other
Mail-11 element belongs to Mail-11 P2:
- P1.From - P1.To
maps to P1.Originator maps to P1.Primary Recipient
- P1.To - P2.From
maps to P1.Primary Recipient maps to P2.Originator
- P2.From - P2.To
maps to P2.Originator maps to P2.Primary Recipient
- P2.To - Cc
maps to P2.Primary Recipient maps to P2.Copy Recipient
- Cc - Date
maps to P2.Copy Recipient maps to Submission Time Stamp
- Date - Subj
maps to Submission Time Stamp maps to Subject
- Subj Any eventual RFC822-like text header in Mail-11 body part will be
maps to Subject interpreted as specified into RFC1327 and its updates.
Any eventual RFC822-like text header in Mail-11 body part will be 2.3. X.400 service elements
interpreted as specified into RFC1327 and its updates.
2.3. X.400 service elements The following X.400 service elements are supported directly into
Mail-11 conversion:
The following X.400 service elements are supported - P1.Originator
directly into Mail-11 conversion: maps to P1.'From'
- P1.Originator - P1.Primary Recipients
maps to P1.'From' maps to P1.'To'
- P1.Primary Recipients - P2.Originator
maps to P1.'To' maps to P2.'From'
- P2.Originator - P2.Primary Recipients
maps to P2.'From' maps to P2.'To'
- P2.Primary Recipients - Copy Recipients
maps to P2.'To' maps to 'Cc'
- Copy Recipients - Submission Time Stamp
maps to 'Cc' maps to 'date'
- Submission Time Stamp - Subject
maps to 'date' maps to 'Subj'
- Subject The following X.400 service element is partially supported into
maps to 'Subj' Mail-11 conversion:
The following X.400 service element is partially - Blind Copy Recipient
supported into Mail-11 conversion: to ensure the required privacy, when a message contains
a BCC address, the following actions occurs:
- a new message is created, containing the body parts;
- a new envelope is added to the new message, containing
the originator and the BCC recipient addresses only;
- a note is added to the message informing the BCC
recipient about the fact that the message was a BCC;
- the new message is delivered separately;
- a note is added to the message delivered to TO and CC
recipients informing them about the fact that there
were some BCC recipients, too.
- Blind Copy Recipient Any other X.400 service element support is done accordingly to
to ensure the required privacy, when a message RFC1327 including the mapped element into the RFC822-like header into
contains a BCC address, the following actions Mail-11 body part.
occurs:
- a new message is created, containing the body
parts;
- a new envelope is added to the new message,
containing the originator and the BCC
recipient addresses only.
- the new message is delivered separately.
Any other X.400 service element support is done Chapter 3 - Basic Mappings
accordingly to RFC1327 including the mapped element into the
RFC822-like header into Mail-11 body part.
Chapter 3 - Basic Mappings The basic mappings indicated in RFC1327 and its updates should be
fully used.
The basic mappings indicated in RFC1327 and its updates Chapter 4 - Addressing
should be fully used.
Chapter 4 - Addressing 4.1. Mail-11 addressing
4.1. Mail-11 addressing Mail-11 addressing can vary from a very simple case up to complex
ones, if there are other Mail-11 to "something-else" gateways
involved. In any case a Mail-11 address is an ASCII string composed
of different elements.
Mail-11 addressing can vary from a very simple case up 4.2. X.400 addressing
to complex ones, if there are other Mail-11 to "something-else"
gateways involved. In any case a Mail-11 address is an ASCII
string composed of different elements.
4.2. X.400 addressing On the other hand, An X.400 O/R address is a collection of
attributes, which can anyway be presented as an IA5 textual
representation as defined in chapter 4 of RFC1327.
On the other hand, An X.400 O/R address is a collection 4.3. Mail-11 address components
of attributes, which can anyway be presented as an IA5 textual
representation as defined in chapter 4 of RFC1327.
4.3. Mail-11 address components Let us start defining the different parts composing a Mail-11
address. We can consider any Mail-11 address as composed by 3 parts:
Let us start defining the different parts composing a [[route]::] [[node]::] local-part
Mail-11 address. We can consider any Mail-11 address as composed
by 3 parts:
[[route]::] [[node]::] local part where 'route' and 'node' are optional and only 'local-part' is
compulsory.
where 'route' and 'node' are optional and only 'local Here comes a strict definition of these elements
part' is compulsory. Here comes a strict definition of these
elements
node = *(ALPHA/DIGIT) / *DIGIT / *DIGIT "." *DIGIT node = *(ALPHA/DIGIT) / *DIGIT / *DIGIT "." *DIGIT
route = *(node "::") route = *(node "::")
local part = username / nickname / for-protocol local-part = username / nickname / for-protocol
username = *(ALPHA/DIGIT) username = *(ALPHA/DIGIT)
nickname = <printablestring - <" " and HTAB>> nickname = <printablestring - <" " and HTAB>>
for-protocol = (f-pref f-sep <">f-address<">) for-protocol = (f-pref f-sep <">f-address<">)
f-pref = *(ALPHA/DIGIT) f-pref = *(ALPHA/DIGIT)
f-sep = "%" / "::" f-sep = "%" / "::"
f-address = printablestring / rfc822-address / X400-text-address f-address = printablestring / RFC822-address / X400-text-address
X400-text-address = <textual representation of an X.400 O/R addr> X400-text-address = <textual representation of an X.400 O/R addr>
Please note that in x-text-address both the ";" notation and the Please note that in x-text-address both the ";" notation and the "/"
"/" notation are equivalent and allowed (see examples in notation are equivalent and allowed (see examples in different sect.)
different sect.) Some examples:
some examples: route node local-part
-----------------------------------------------------------
USER47
MYNODE::BETTY
BOSTON::CLUS02::GOOFY1::MARY34
IN%"M.P.Tracy@Dicdum.cc.edu"
UCLA13::MVAX93::MRGATE::"MBOX1::MBX34::MYC3::BOB"
MIAMI2::George.Rosenthal
CCUBVX::VS3100::Jnet%"IAB3425@IBAX23L"
MRGATE::"C=xx::A=bbb::P=ppp::S=Joe"
MAINVX::IN%"path1!path2!user%dom"
GWX400::gw%"C=xx;ADMD=aaa;PRMD=ppp;S=Lee;"
GX409A::x400%"/C=xx/A=aaa/P=ppp/S=Lee"
smtp%"postmast@nodeb.bitnet"
MICKEY::PRFGAT::profs%"NANCY@IBMB"
edu%"HU427BD%CSUNIB@abc.acme.edu"
route node local part Chapter 5 - Mapping
----------------------------------------------------------
USER47
MYNODE::BETTY
BOSTON::CLUS02::GOOFY1::MARY34
IN%"M.T.Rose@Dicdum.cc.edu"
UCLA13::MVAX93::MRGATE::"MBOX1::MBX34::MYC3::BOB"
MIAMI2::George.Rosenthal
CCUBVX::VS3100::Jnet%"IAB3425@IBAX23L"
MRGATE::"C=xx::A=bbb::P=ppp::S=Joe"
MAINVX::IN%"path1!path2!user%dom"
GWX400::gw%"C=xx;ADMD=aaa;PRMD=ppp;S=Lee;"
GX409A::x400%"/C=xx/A=aaa/P=ppp/S=Lee"
Chapter 5 - Mapping
5.1. Mapping scheme 5.1. Mapping scheme
DECnet address field is somehow a 'flat land' with some DECnet address field is somehow a 'flat land' with some obliged
obliged routes to reach some hidden areas. Thus a truly routes to reach some hidden areas. Thus a truly hierarchical mapping
hierarchical mapping scheme using mapping tables as suitable scheme using mapping tables as suitable for RFC822 is not the
for RFC822 is not the appropriate solution. A fixed set of rules appropriate solution. A fixed set of rules using DDAs support is
using DDAs support is defined in order to define the mapping. defined in order to define the mapping.
Another important aspect of the problem is the Another important aspect of the problem is the coexistence of many
coexistence of many disjoint DECnet networks, using the same disjoint DECnet networks, using the same DECnet address space, i.e.,
DECnet address space, i.e. 'area' and 'node' numbers. A possible common X.400 and/or RFC822 mailing system acting as glue to connect
case exists when we have a common X.400 and/or RFC 822 mailing different isolated Mail-11 islands. Thus, to identify uniquely each
system acting as glue to connect different isolated Mail-11 DECnet network we must also introduce the concept of 'DECnet network
islands. Thus, to identify uniquely each DECnet network we must name', which we will refer shortly as 'net' from now onwards. We
also introduce the concept of 'DECnet network name', which we define as 'net' a unique ASCII string identifying the DECnet network
will refer shortly as 'net' from now onwards. We define as 'net' we are connected to. To be more specific, the 'net' element will
a unique ASCII string identifying the DECnet network we are identify the DECnet community being served, i.e., it could also
connected to. To be more specific, the 'net' element will differ from the actual official network name. Aliases are allowed for
identify the DECnet community being served, i.e. it could also the
differ from the actual official network name. Aliases are
allowed for the 'net' attribute. Some possible examples are:
net = 'HEPnet' the High Energy Physics DECnet Network net = 'HEPnet' the High Energy Physics DECnet network
net = 'SPAN' the Space Physics Analysis Network net = 'SPAN' the Space Physics Analysis Network
net = 'Enet' the Digital Equipment Corporate Network net = 'Enet' the Digital Equipment Corporate Network
The need of labelling each DECnet network with its name The need of labelling each DECnet network with its name comes also
comes also from the requirement to implement the 'intelligent' from the requirement to implement the 'intelligent' gateway, i.e.,
gateway, i.e. the gateway which is able to understand its the gateway which is able to understand its ability to connect
ability to connect directly to the specified DECnet network, directly to the specified DECnet network, even if the O/R address
even if the O/R address specify a path to a different gateway. specify a path to a different gateway. A more detailed discussion of
A more detailed discussion of the problem is in 5.3 and 5.5. the problem is in 5.3 and 5.5.
A registry of 'net' attributes and their correspondent A registry of 'net' attributes and their correspondent gateways must
gateways must also be implemented to insure uniqueness of names. also be implemented to insure uniqueness of names. A simple table
A simple table coupling 'net' and the gateway address is used, coupling 'net' and the gateway address is used, in a syntax similar
in a syntax similar to the 'gate' table used in RFC1327. An to the 'gate' table used in RFC1327. An example:
example:
HEPnet#OU$Cosine-gw.O$@.PRMD$infn.ADMD$garr.C$IT# HEPnet#OU$Cosine-gw.O$@.PRMD$infn.ADMD$garr.C$IT#
SPAN#OU$Cosine-gw.O$@.PRMD$infn.ADMD$garr.C$IT# SPAN#OU$Cosine-gw.O$@.PRMD$infn.ADMD$garr.C$IT#
SPAN#O$ESRIN1.PRMD$esa.ADMD$Master400.C$it# SPAN#O$ESRIN1.PRMD$esa.ADMD$Master400.C$it#
Ambiguous left entries are allowed. Gateway implementations Ambiguous left entries are allowed. Gateway implementations could
could simply choose among one of them, or try them all in cyclic simply choose among one of them, or try them all in cyclic order to
order to obtain better performances. obtain better performances.
In order to keep the mapping rules very simple, In order to keep the mapping rules very simple, avoiding the need to
avoiding the need to analyse Mail-11 addresses to distinguish analyse Mail-11 addresses to distinguish the 'route', 'node' and
the 'route', 'node' and 'local part', we will define only the needed to cover the mapping problem.
minimum set of DDAs strictly needed to cover the mapping
problem.
5.2. Mail-11 --> X.400 5.2. Mail-11 --> X.400
We define the following Domain Defined Attributes to map We define the following Domain Defined Attributes to map a Mail-11
a Mail-11 address: address:
DD.Dnet DD.Dnet
DD.Mail-11 DD.Mail-11
We thus define the mapping rule We thus define the mapping rule
route::node::localpart route::node::localpart
maps into maps into
C=xx; ADMD=yyy; PRMD=zzz; O=ooo; OU=uuu; DD.Dnet=net; C=xx; ADMD=yyy; PRMD=zzz; O=ooo; OU=uuu; DD.Dnet=net;
DD.Mail-11=route::node::localpart; DD.Mail-11=route::node::localpart;
with with
xx = country code of the gateway performing the xx = country code of the gateway performing the conversion
conversion yyy = Admd of the gateway performing the conversion
yyy = Admd of the gateway performing the conversion zzz = Prmd of the gateway performing the conversion
zzz = Prmd of the gateway performing the conversion ooo = Organisation of the gateway performing the conversion
ooo = Organisation of the gateway performing the uuu = Org. Unit(s) of the gateway performing the conversion
conversion net = name of the DECnet network (e.g., HEPnet, SPAN,...)
uuu = Org. Unit(s) of the gateway performing the
conversion
net = name of the DECnet network (e.g. HEPnet,
SPAN,...)
('zzz', 'ooo', 'uuu' being used or dropped appropriately in ('zzz','ooo','uuu' being used or dropped appropriately in order to
order to identify uniquely within the X.400 MHS the gateway identify uniquely within the X.400 MHS the gateway performing the
performing the conversion). conversion).
The following defaults also apply: The following defaults also apply:
if 'node' is missing and we are mapping the Mail-11 originator if 'node' is missing and we are mapping the Mail-11 originator (From)
(From) then 'node' defaults to the DECnet node name of the then 'node' defaults to the DECnet node name of the gateway (gwnode);
gateway (gwnode);
if 'node' is missing and we are mapping the Mail-11 recipient if 'node' is missing and we are mapping the Mail-11 recipient (To,
(To, Cc) then 'node' defaults to the DECnet node name of the Cc) then 'node' defaults to the DECnet node name of the 'From'
'From' address. address.
if 'DD.Dnet=net' is missing, then it defaults to a value if 'DD.Dnet=net' is missing, then it defaults to a value defined
defined locally by the gateway: if the gateway is connected to locally by the gateway: if the gateway is connected to one DECnet
one DECnet network only, then 'net' will be the name of this network only, then 'net' will be the name of this unique network; if
unique network; if the gateway is connected to more than one the gateway is connected to more than one DECnet network, then the
DECnet network, then the gateway will establish a 'first gateway will establish a 'first choice' DECnet network, and 'net'
choice' DECnet network, and 'net' will default to this value. will default to this value.
In case 'local part' contains 'x400-text-address' see also In case 'local-part' contains 'x400-text-address' see also section
section 6.4.3; 6.4.3;
In case 'local part' contains 'rfc822-address' see also section In case 'local-part' contains 'RFC822-address' see also section
6.4.4. 6.4.4.
5.2.1. Examples 5.2.1. Examples
Let us suppose that: Let us suppose that:
the DECnet network name (net) is 'HEP'; the DECnet network name (net) is 'HEP';
the DECnet node name of the gateway (gwnode) is 'X4TDEC'; the DECnet node name of the gateway (gwnode) is 'X4TDEC';
the Country Code of the gateway is 'IT' and its ADMD is 'garr' the Country Code of the gateway is 'IT' and its ADMD is 'garr'
(and these two fields are enough to identify uniquely the (and these two fields are enough to identify uniquely the gateway
gateway within the x.400 MHS). within the X.400 MHS).
USER47 USER47
C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=X4TDEC::USER47; C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=X4TDEC::USER47;
MYNODE::BETTY MYNODE::BETTY
C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=MYNODE::BETTY; C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=MYNODE::BETTY;
BOSTON::CLUS02::GOOFY1::MARY34 BOSTON::CLUS02::GOOFY1::MARY34
C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=BOSTON::GOOFY1::MARY34; C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=BOSTON::GOOFY1::MARY34;
UCLA13::MVAX93::MRGATE::"MBOX1::MBX34:MYC3::BOB" UCLA13::MVAX93::MRGATE::"MBOX1::MBX34:MYC3::BOB"
C=it; ADMD=garr; DD.Dnet=HEP; C=it; ADMD=garr; DD.Dnet=HEP;
DD.Mail-11=UCLA13::MVAX93::MRGATE::(q)MBOX1::MBX34::MYC3::BOB(q) DD.Mail-11=UCLA13::MVAX93::MRGATE::(q)MBOX1::MBX34::MYC3::BOB(q)
MIAMI2::George.Rosenthal MIAMI2::George.Rosenthal
C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=MIAMI2::George.Rosenthal; C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=MIAMI2::George.Rosenthal;
MRGATE::"C=xx::A=bbb::P=ppp::S=Joe" MRGATE::"C=xx::A=bbb::P=ppp::S=Joe"
C=it; ADMD=garr; DD.Dnet=HEP; C=it; ADMD=garr; DD.Dnet=HEP;
DD.Mail-11=X4TDEC::MRGATE::(q)C=xx::A=bbb::P=ppp::S=Joe(q) DD.Mail-11=X4TDEC::MRGATE::(q)C=xx::A=bbb::P=ppp::S=Joe(q)
MAINVX::In%"path1!path2!user%dom" MAINVX::In%"path1!path2!user%dom"
C=it; ADMD=garr; DD.Dnet=HEP; C=it; ADMD=garr; DD.Dnet=HEP;
DD.Mail-11=MAINVX::In(p)(q)path1(b)path2(b)user(p)dom(q) DD.Mail-11=MAINVX::In(p)(q)path1(b)path2(b)user(p)dom(q)
5.3. X.400 encoding of Mail-11 --> Mail-11 5.3. X.400 encoding of Mail-11 --> Mail-11
In order to assure path reversibility in case of In order to assure path reversibility in case of multiple Mail-
multiple Mail-11/X.400 gateway crossing we must distinguish two 11/X.400 gateway crossing we must distinguish two cases:
cases:
- DD.Dnet=net is known to the gateway as one of the DECnet - DD.Dnet=net is known to the gateway as one of the DECnet networks
networks it is connected to. In this case the mapping is it is connected to. In this case the mapping is trivial:
trivial:
C=xx; ADMD=yyy; PRMD=zzz; O=ooo; OU=uuu; DD.Dnet=net; C=xx; ADMD=yyy; PRMD=zzz; O=ooo; OU=uuu; DD.Dnet=net;
DD.Mail-11=route::node::localpart; DD.Mail-11=route::node::localpart;
(see sect. 5.2 for explication of 'xx', 'yyy', 'zzz', 'ooo', (see sect. 5.2 for explication of 'xx','yyy','zzz','ooo','uuu','net')
'uuu','net')
maps into maps into
route::node::localpart route::node::localpart
- DD.Dnet=net is NOT known to the gateway as one of the DECnet - DD.Dnet=net is NOT known to the gateway as one of the DECnet
networks it is connected to. In this case the mapping rule networks it is connected to. In this case the mapping rule
described into section 5.4 apply: described into section 5.4 apply:
C=xx; ADMD=yyy; PRMD=www; DD.Dnet=net; C=xx; ADMD=yyy; PRMD=www; DD.Dnet=net;
DD.Mail-11=route::node::localpart; DD.Mail-11=route::node::localpart;
maps into maps into
gwnode::gw%"C=xx;ADMD=yyy;PRMD=www;DD.Dnet=net; gwnode::gw%"C=xx;ADMD=yyy;PRMD=www;DD.Dnet=net;
DD.Mail-11=route::node::localpart;" DD.Mail-11=route::node::localpart;"
5.3.1. Examples 5.3.1. Examples
Let us suppose that: Let us suppose that:
the DECnet network name (net) is 'HEP'; the DECnet network name (net) is 'HEP';
the DECnet node name of the gateway (gwnode) is 'X4TDEC'; the DECnet node name of the gateway (gwnode) is 'X4TDEC';
the Country Code of the gateway is 'IT' and its ADMD is 'garr'; the Country Code of the gateway is 'IT' and its ADMD is 'garr';
(and these two fields are enough to identify uniquely the (and these two fields are enough to identify uniquely the gateway
gateway within the x.400 MHS). within the X.400 MHS).
C=it; ADMD=garr; DD.Dnet=HEP; C=it; ADMD=garr; DD.Dnet=HEP;
DD.Mail-11=X4TDEC::MRGATE::(q)C=ab::A=dsa::P=qwerty::OU=mine::S=Clay(q) DD.Mail-11=X4TDEC::MRGATE::(q)C=ab::A=dsa::P=qwty::OU=mie::S=Cly(q)
MRGATE::"C=ab::A=dsa::P=qwerty::OU=mine::S=Clay" MRGATE::"C=ab::A=dsa::P=qwty::OU=mie::S=Cly"
C=it; ADMD=garr; DD.Dnet=EASYNET; DD.Mail-11=ROM01::CARLO; C=it; ADMD=garr; DD.Dnet=EASYNET; DD.Mail-11=ROM01::CARLO;
X4TDEC::gw%"C=it;ADMD=garr;DD.Dnet=EASYNET; X4TDEC::gw%"C=it;ADMD=garr;DD.Dnet=EASYNET;
DD.Mail-11=ROM01::CARLO;" DD.Mail-11=ROM01::CARLO;"
(in the above example 'EASYNET' is supposed to be not connected (in the above example 'EASYNET' is supposed to be not connected to
to our gateway located on X4TDEC DECnet node). our gateway located on X4TDEC DECnet node).
5.4. X.400 --> Mail-11 5.4. X.400 --> Mail-11
The mapping of an X.400 O/R address into Mail-11 is The mapping of an X.400 O/R address into Mail-11 is done encoding the
done encoding the various attributes into the X400-text-address various attributes into the X400-text-address as defined in chapter 4
as defined in chapter 4 of RFC1327, and including this as of RFC1327, and including this as 'f-address'. A 'f-pref' and a the
'f-address'. A 'f-pref' and a 'f-sep' are added completing DECnet node name of the gateway.
'local part'. 'gwnode' is included as the DECnet node name of
the gateway.
Thus Thus
x400-text-address x400-text-address
will be encoded like will be encoded like
gwnode::gw%"x400-text-address" gwnode::gw%"x400-text-address"
having spaces dividing attributes as optional. having spaces dividing attributes as optional.
5.4.1. Example 5.4.1. Example
Let us suppose that: Let us suppose that:
the DECnet node name of the gateway (gwnode) is 'X4TDEC'; the DECnet node name of the gateway (gwnode) is 'X4TDEC';
Thus Thus
C=gb; ADMD=Gold 400; PRMD=AC.UK; O=ucl; OU=cs; G=Paul; S=Smith; C=gb; ADMD=Gold 400; PRMD=AC.UK; O=ucl; OU=cs; G=Jim; S=Clay;
will be encoded like will be encoded like
X4TDEC::gw%"/C=gb/A=Gold 400/P=AC.UK/O=ucl/OU=cs/G=Paul/S=Smith" X4TDEC::gw%"/C=gb/A=Gold 400/P=AC.UK/O=ucl/OU=cs/G=Jim/S=Clay"
or its equivalent with the ";" notation or its equivalent with the ";" notation
X4TDEC::gw%"C=gb;ADMD=Gold 400;PRMD=AC.UK;O=ucl;OU=cs;G=Paul;S=Smith;" X4TDEC::gw%"C=gb;ADMD=Gold 400;PRMD=AC.UK;O=ucl;OU=cs;G=Jim;S=Clay;"
5.5. Mail-11 encoding of X.400 --> X.400 5.5. Mail-11 encoding of X.400 --> X.400
It can happened that Mail-11 is used to relay messages It can happened that Mail-11 is used to relay messages between X.400
between X.400 systems; this will mean multiple X.400/Mail-11 systems; this will mean multiple X.400/Mail-11 gateway crossing and
gateway crossing and we will encounter Mail-11 addresses we will encounter Mail-11 addresses containing embedded X.400
containing embedded X.400 information's. In order to assure path informations. In order to assure path reversibility we must then
reversibility we must then distinguish two cases: distinguish two cases:
- the embedded X.400 address belongs to a domain whose naming - the embedded X.400 address belongs to a domain whose naming and
and routing rules are known to the global X.400 MHS. In this routing rules are known to the global X.400 MHS. In this case the
case the mapping is trivial: mapping is trivial:
route::gwnode::gw%"x400-text-address" route::gwnode::gw%"x400-text-address"
maps into maps into
x400-text-address x400-text-address
'route' and 'gwnode' are mapped into X.400 Trace service 'route' and 'gwnode' are mapped into X.400 Trace service elements.
elements.
- the encoded x.400 domain does not belong to the global X.400 - the encoded X.400 domain does not belong to the global X.400 name
name space. In this case the mapping rule described into space. In this case the mapping rule described into section 5.2
section 5.2 apply: apply:
route::gwnode::gw%"x400-text-address" route::gwnode::gw%"x400-text-address"
maps into maps into
C=xx; ADMD=yyy; DD.Dnet=net; C=xx; ADMD=yyy; DD.Dnet=net;
DD.Mail-11=route::gwnode::gw(p)(q)x400-text-address(q); DD.Mail-11=route::gwnode::gw(p)(q)x400-text-address(q);
The latter case is deprecated and must be regarded as a The latter case is deprecated and must be regarded as a possible
possible temporary solution only, while waiting to include into temporary solution only, while waiting to include into the global
the global X.400 MHS also this domain. X.400 MHS also this domain.
5.5.1. Examples 5.5.1. Examples
Let us suppose that: Let us suppose that:
the DECnet network name (net) is 'HEP'; the DECnet network name (net) is 'HEP';
the DECnet node name of the gateway (gwnode) is 'X4TDEC'; the DECnet node name of the gateway (gwnode) is 'X4TDEC';
the Country Code of the gateway is 'IT' and its ADMD is 'garr'; the Country Code of the gateway is 'IT' and its ADMD is 'garr';
(and these two fields are enough to identify uniquely the (and these two fields are enough to identify uniquely the gateway
gateway within the x.400 MHS). within the X.400 MHS).
X4TDEC::gw%"C=fr;ADMD=atlas;PRMD=ifip;O=poly;S=Moreau;" X4TDEC::gw%"C=fr;ADMD=atlas;PRMD=ifip;O=poly;S=Moreau;"
C=fr; ADMD=atlas; PRMD=ifip; O=poly; S=Moreau; C=fr; ADMD=atlas; PRMD=ifip; O=poly; S=Moreau;
X4TDEC::gw%"C=zz;ADMD= ;PRMD=Botwa;O=Miner;S=Chiuaw;" X4TDEC::gw%"C=zz;ADMD= ;PRMD=Botwa;O=Miner;S=Chiuaw;"
C=it; ADMD=garr; DD.Dnet=HEP; C=it; ADMD=garr; DD.Dnet=HEP;
DD.Mail-11=X4TDEC::gw(p)(q)C=zz;ADMD= ; DD.Mail-11=X4TDEC::gw(p)(q)C=zz;ADMD= ;
PRMD=Botwa;O=Miner;S=Chiuaw;(q) PRMD=Botwa;O=Miner;S=Chiuaw;(q)
(in the above example C=zz is unknown to the global X.400 MHS) (in the above example C=zz is unknown to the global X.400 MHS)
Chapter 6 - Complex mapping
6.1. The protocol triangle Chapter 6 - Complex mapping
The bilateral mappings described in chapter 5 must be 6.1. The protocol triangle
extended in order to cover also the case in which also RFC 822
addressing is involved, and the following triangular situation
occurs:
x.400 The bilateral mappings described in chapter 5 must be extended in
/ \ order to cover also the case in which also RFC822 addressing is
/ \ involved, and the following triangular situation occurs:
/ \
Mail-11----RFC822
The X.400 - RFC 822 side is fully covered by RFC1327, x.400
and the previous chapters in this document cover the / \
Mail-11 - X.400 side. / \
/ \
Mail-11----RFC822
Currently a number of implementations also perform the The X.400 - RFC822 side is fully covered by RFC1327, and the previous
mapping along the Mail-11 - RFC 822 side. The most important chapters in this document cover the Mail-11 - X.400 side.
among these de facto standards are discussed in Appendix A,
jointly with a Mail-11 - RFC 822 mapping scheme which covers
this side of the triangle.
6.2. RFC822 mapped in Mail-11 Currently a number of implementations also perform the mapping along
the Mail-11 - RFC822 side. The most important among these de facto
standards are discussed in Appendix A, jointly with a Mail-11 -
RFC822 mapping scheme which covers this side of the triangle.
The 'rfc822-address' is usually included in 'local 6.2. RFC822 mapped in Mail-11
part' as 'f-address' using the Mail-11 foreign mail protocol
syntax:
route::gwnode::gw%"rfc822-address" The 'RFC822-address' is usually included in 'local-part' as
an example route::gwnode::gw%"rfc822-address"
NVXA23::SMTPGW::in%"M.T.Rose@CS.UCLA.edu" an example
6.3. Mail-11 mapped in RFC822 NVXA23::SMTPGW::in%"M.T.Rose@CS.UCLA.edu"
There are different styles in mapping a Mail-11 address 6.3. Mail-11 mapped in RFC822
in RFC 822; let's have a short summary.
- Mail-11 address encoded in "Left Hand Side" (LHS) of RFC 822 There are different styles in mapping a Mail-11 address in RFC822;
address, using "%" syntax or "::" syntax; let's have a short summary.
route::node::localpart - Mail-11 address encoded in "Left Hand Side" (LHS) of RFC822
address, using "%" syntax or "::" syntax;
maps to route::node::localpart
localpart%node%route@gw-domains maps to
or localpart%node%route@gw-domains
"route::node::localpart"@gw-domains or
where 'gw-domains' identify uniquely the Mail-11 / RFC822 "route::node::localpart"@gw-domains
gateway.
- Mail-11 address maps partly to LHS and partly to 'domain' part where 'gw-domains' identify uniquely the Mail-11 / RFC822 gateway.
of RFC822 address:
node::localpart - Mail-11 address maps partly to LHS and partly to 'domain' part of
RFC822 address:
maps to node::localpart
localpart@node.gw-domains maps to
- Mail-11 address is completely hidden by a mapping table localpart@node.gw-domains
or directory and the resultant RFC822 address contains no
trace at all of the original address.
As you could notice, in any of the quoted cases the resultant - Mail-11 address is completely hidden by a mapping table / directory
RFC822 address is not distinguishable from a genuine RFC822 and the resultant RFC822 address contains no trace at all of the
address. original address.
6.4. Multiple conversions As you could notice, in any of the quoted cases the resultant RFC822
address is not distinguishable from a genuine RFC822 address.
Let us now examine briefly the possible situations 6.4. Multiple conversions
which involve multiple conversions, having one protocol as a
relay between the other two. This summary suggest some possible
enhanced solutions to avoid heavy and unduly mappings, but the
'step by step' approach, considering blindly one conversion as
disjointed to the other, as described in the previous sections,
can always be used.
6.4.1. X.400 --> RFC 822 --> Mail-11 Let us now examine briefly the possible situations which involve
multiple conversions, having one protocol as a relay between the
other two. This summary suggest some possible enhanced solutions to
avoid heavy and unduly mappings, but the 'step by step' approach,
considering blindly one conversion as disjointed to the other, as
described in the previous sections, can always be used.
We apply the RFC1327 rules to the first step, obtaining 6.4.1. X.400 --> RFC822 --> Mail-11
an RFC 822 address which can be mapped in Mail-11 using the
'f-address' field, as described in section 6.2.
an example: We apply the RFC1327 rules to the first step, obtaining an RFC822
address which can be mapped in Mail-11 using the 'f-address' field,
as described in section 6.2.
C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Paul; S=Smith; an example:
maps accordingly to RFC1327 to C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Jim; S=Clay;
Paul.Smith@cs.UCL.AC.UK maps accordingly to RFC1327 to
and finally becomes Jim.Clay@cs.UCL.AC.UK
SMTPGW::In%"Paul.Smith@cs.UCL.AC.UK" and finally becomes
where 'SMTPGW' is the DECnet node name of the machine running SMTPGW::In%"Jim.Clay@cs.UCL.AC.UK"
the RFC 822 to Mail-11 gateway.
6.4.2. Mail-11 --> RFC 822 --> X.400 where 'SMTPGW' is the DECnet node name of the machine running the
RFC822 to Mail-11 gateway.
Some of the possible mapping described in section 6.3 6.4.2. Mail-11 --> RFC822 --> X.400
apply to the Mail-11 address, hiding completely its origin. The
RFC1327 apply on the last step.
an example: Some of the possible mapping described in section 6.3 apply to the
Mail-11 address, hiding completely its origin. The RFC1327 apply on
the last step.
RELAY::MYNODE::BETTY an example:
could map into RFC 822 as RELAY::MYNODE::BETTY
BETTY%MYNODE@RELAY.dnet.gw1.it could map into RFC822 as
and accordingly to RFC1327 BETTY%MYNODE@RELAY.dnet.gw1.it
C=it; A=garr; P=dom1; O=gw1; OU=RELAY; S=BETTY(p)MYNODE; and accordingly to RFC1327
where 'dnet.gw1.it' is the domain of the machine running the C=it; A=garr; P=dom1; O=gw1; OU=RELAY; S=BETTY(p)MYNODE;
Mail-11 to RFC 822 gateway.
6.4.3. X.400 --> Mail-11 --> RFC 822 where 'dnet.gw1.it' is the domain of the machine running the Mail-11
to RFC822 gateway.
The X.400 address is stored into Mail-11 'f-address' 6.4.3. X.400 --> Mail-11 --> RFC822
element as described in sections 5.3 and 5.4; then if the
Mail-11 to RFC 822 gateway is able to understand the presence
of a 'x400-text-address' into the Mail-11 address, then it
applies RFC1327 to it, and encodes 'route' and 'node' as
'Received:' elements into RFC 822 message header. Otherwise it
applies the rules described in 6.3
an example: The X.400 address is stored into Mail-11 'f-address' element as
described in sections 5.3 and 5.4; then if the Mail-11 to RFC822
gateway is able to understand the presence of a 'x400-text-address'
into the Mail-11 address, then it applies RFC1327 to it, and encodes
header. Otherwise it applies the rules described in 6.3
C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Paul; S=Smith; an example:
will be encoded like C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Jim; S=Clay;
X4TDEC::gw%"/C=gb/A=Gold 400/P=AC.UK/O=UCL/OU=cs/G=Paul/S=Smith" will be encoded like
If the Mail-11 to RFC822 gateway recognise the x400-text-address, X4TDEC::gw%"/C=gb/A=Gold 400/P=AC.UK/O=UCL/OU=cs/G=Jim/S=Clay"
then the address becomes, accordingly to RFC1327
Paul.Smith@cs.UCL.AC.UK If the Mail-11 to RFC822 gateway recognise the x400-text-address,
then the address becomes, accordingly to RFC1327
and the following RFC 822 header line is added Jim.Clay@cs.UCL.AC.UK
Received: from X4TDEC with DECnet (Mail-11) on xx-xxx-xxxx. and the following RFC822 header line is added
Otherwise one of the dumb rules could produce Received: from X4TDEC with DECnet (Mail-11) on xx-xxx-xxxx.
gw%"/C=gb/A=Gold 400/P=AC.UK/O=UCL/OU=cs/G=Paul/S=Smith"@X4TDEC.domains Otherwise one of the dumb rules could produce
6.4.4. RFC 822 --> Mail-11 --> X.400 gw%"/C=gb/A=Gold 400/P=AC.UK/O=UCL/OU=cs/G=Jim/S=Clay"@X4TDEC.doms
The RFC 822 address is encoded in Mail-11 f-address 6.4.4. RFC822 --> Mail-11 --> X.400
element as described in sect. 6.2; then if the Mail-11 to X.400
gateway is able to understand the presence of an
'rfc822-address' into the Mail-11 address, then it applies
RFC1327 to it, and encodes 'route' and 'node' as 'trace'
elements of the message header. Otherwise it applies the rules
described in 5.2 and 5.5.
an example: The RFC822 address is encoded in Mail-11 f-address element as
described in sect. 6.2; then if the Mail-11 to X.400 gateway is able
to understand the presence of an 'RFC822-address' into the Mail-11
address, then it applies RFC1327 to it, and encodes 'route' and
applies the rules described in 5.2 and 5.5.
Paul.Smith@cs.UCL.AC.UK an example:
will be encoded like Jim.Clay@cs.UCL.AC.UK
SMTPGW::In%"Paul.Smith@cs.UCL.AC.UK" will be encoded like
If the Mail-11 to X.400 gateway recognise the rfc822-address, SMTPGW::In%"Jim.Clay@cs.UCL.AC.UK"
then the address becomes, accordingly to RFC1327
C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Paul; S=Smith; If the Mail-11 to X.400 gateway recognise the RFC822-address, then
the address becomes, accordingly to RFC1327
and a 'trace' record is added into the X.400 P1 data, stating C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Jim; S=Clay;
that a node named SMTPGW was crossed.
Otherwise dumb rule produces and a 'trace' record is added into the X.400 P1 data, stating that a
node named SMTPGW was crossed.
C=it; ADMD=garr; DD.Dnet=HEP; Otherwise dumb rule produces
DD.Mail-11=SMTPGW::In(p)(q)Paul.Smith(a)cs.UCL.AC.UK(q)
6.4.5. RFC 822 --> X.400 --> Mail-11 C=it; ADMD=garr; DD.Dnet=HEP;
DD.Mail-11=SMTPGW::In(p)(q)Jim.Clay(a)cs.UCL.AC.UK(q)
We apply RFC1327 to the first conversion, obtaining an 6.4.5. RFC822 --> X.400 --> Mail-11
X.400 address. Then the rules described in sections 5.3 and 5.4
are used to store the X.400 address as 'x400-text-address' into
the Mail-11 'local part'.
an example: We apply RFC1327 to the first conversion, obtaining an X.400 address.
Then the rules described in sections 5.3 and 5.4 are used to store
the X.400 address as 'x400-text-address' into the Mail-11
Paul.Smith@cs.UCL.AC.UK an example:
maps accordingly to RFC1327 to Jim.Clay@cs.UCL.AC.UK
C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Paul; S=Smith; maps accordingly to RFC1327 to
C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Jim; S=Clay;
and finally becomes and finally becomes
SMTPGW::gw%"/C=gb/A=Gold 400/P=AC.UK/O=UCL/OU=cs/G=Paul/S=Smith" SMTPGW::gw%"/C=gb/A=Gold 400/P=AC.UK/O=UCL/OU=cs/G=Jim/S=Clay"
where 'SMTPGW' is the DECnet node name of the machine running where 'SMTPGW' is the DECnet node name of the machine running the
the X.400 to Mail-11 gateway. X.400 to Mail-11 gateway.
6.4.6. Mail-11 --> X.400 --> RFC 822 6.4.6. Mail-11 --> X.400 --> RFC822
The Mail-11 address is encoded as specified in sections The Mail-11 address is encoded as specified in sections 5.2 and 5.5;
5.2 and 5.5; then RFC1327 is used to convert the address in then RFC1327 is used to convert the address in RFC822.
RFC822.
an example: an example:
RELAY::MYNODE::BETTY RELAY::MYNODE::BETTY
maps into X.400 as maps into X.400 as
C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=RELAY::MYNODE::BETTY; C=it; ADMD=garr; DD.Dnet=HEP; DD.Mail-11=RELAY::MYNODE::BETTY;
and accordingly to RFC1327 and accordingly to RFC1327
"/C=it/A=garr/DD.Dnet=HEP/DD.Mail-11=RELAY::MYNODE::BETTY"@gw2.it "/C=it/A=garr/DD.Dnet=HEP/DD.Mail-11=RELAY::MYNODE::BETTY"@gw2.it
where 'gw2.it' is the domain of the machine running the RFC1327 where 'gw2.it' is the domain of the machine running the RFC1327
gateway. gateway.
Appendix A Mail-11 - RFC 822 mapping Appendix A Mail-11 - RFC822 mapping
A.1 Introduction A.1 Introduction
The implementation of a Mail-11 - RFC 822 gateway was The implementation of a Mail-11 - RFC822 gateway was faced by many
faced by many software developers independently, and was software developers independently, and was included in many mail
included in many mail products which were running on both products which were running on both VAX/VMS and UNIX systems. As
VAX/VMS and UNIX systems. As there was not a unique standard there was not a unique standard mapping way, the implementations
mapping way, the implementations resulted into a number of resulted into a number of possible variant methods to map a Mail-11
possible variant methods to map a Mail-11 address into an address into an RFC822 one. Some of these products became then
RFC 822 one. Some of these products became then largely largely widespread, starting to create a number of de facto mapping
widespread, starting to create a number of de-facto mapping methods.
methods.
In this small appendix some sort of standardisation of In this small appendix some sort of standardisation of the mapping
the mapping problem is considered, trying to be compatible with problem is considered, trying to be compatible with the existing
the existing installed software. We must also remind that, in installed software. We must also remind that, in some cases, only
some cases, only simple Mail-11 addresses could be mapped into simple Mail-11 addresses could be mapped into RFC822, having complex
RFC 822, having complex ones producing all sort of quite strange ones producing all sort of quite strange results.
results.
On the other hand, the mapping of an RFC 822 address in On the other hand, the mapping of an RFC822 address in Mail-11 was
Mail-11 was quite straightforward, resulting in a common quite straightforward, resulting in a common definition which uses
definition which uses "Mail-11 foreign mail protocol" to design "Mail-11 foreign mail protocol" to design an RFC822 address:
an RFC 822 address:
[[node::][node::]...]prot%"rfc-822-address" [[node::][node::]...]prot%"rfc-822-address"
or or
[node::][node::]...]::"rfc-822-address" [node::][node::]...]::"rfc-822-address"
A.2 De-facto implementations A.2 De facto implementations
A considerable number of de-facto implementations of A considerable number of de-facto implementations of Mail-11/RFC822
Mail-11 / RFC822 gateways is existing. As said in the gateways is existing. As said in the introduction, the mapping of
introduction, the mapping of RFC 822 addresses in Mail-11 is RFC822 addresses in Mail-11 is accomplished using the foreign mail
accomplished using the foreign mail protocol syntax and is thus protocol syntax and is thus unique.
unique.
On the other hand, Mail-11 addresses are encoded in RFC 822 On the other hand, Mail-11 addresses are encoded in RFC822 syntax in
syntax in various ways. Here are the most common ones: various ways. Here are the most common ones:
a) "node::user"@gateway-address a) "node::user"@gateway-address
b) user%node@gateway-address b) user%node@gateway-address
c) user@node.decnet.domains c) user@node.decnet.domains
d) user%node.dnet@gateway-address d) user%node.dnet@gateway-address
Let's have a quick look to these different choices. Let's have a quick look to these different choices.
a - This form simply encloses as quoted Left Hand Side string a - This form simply encloses as quoted Left Hand Side string the
the original Mail-11 address into the RFC 822 address of the original Mail-11 address into the RFC822 address of the
Mail-11 / RFC822 gateway. This method is fully conformant with Mail-11/RFC822 gateway. This method is fully conformant with
RFC 822 syntax, and the Mail-11 address is left untouched; thus RFC822 syntax, and the Mail-11 address is left untouched; thus
no encoding rules need to applied to it. no encoding rules need to applied to it.
b - As one will immediately notice, this form has nothing in it b - As one will immediately notice, this form has nothing in it
indicating the address is a Mail-11 one; this makes the encoding indicating the address is a Mail-11 one; this makes the encoding
indistinguishable from a similar encoding of RSCS (BITnet) indistinguishable from a similar encoding of RSCS (BITnet)
addresses used by some IBM VM Mailer systems. It should thus be addresses used by some IBM VM Mailer systems. It should thus be
deprecated. deprecated.
c - In this case a sort of 'reserved word' (decnet) embedded c - In this case a sort of 'reserved word' (decnet) embedded into
into the address itself identifies the presence of a Mail-11 the address itself identifies the presence of a Mail-11 original
original address preceding it. The decoding is possible, address preceding it. The decoding is possible, dropping
dropping 'domains' and extracting 'user' and 'node' parts. 'domains' and extracting 'user' and 'node' parts. However complex
However complex Mail-11 addresses cannot be mapped properly in Mail-11 addresses cannot be mapped properly in this syntax, and
this syntax, and there is no specific rule for adding the there is no specific rule for adding the 'domains' part of the
'domains' part of the address. address.
d - In this case again there is a 'reserved word' (dnet) which d - In this case again there is a 'reserved word' (dnet) which make
make possible the identification of the original Mail-11 possible the identification of the original Mail-11 address;
address; 'gateway-address' points to the Mail-11 / RFC822 'gateway-address' points to the Mail-11/RFC822 gateway and 'node'
gateway and 'node' and 'user' information can be easily drawn and 'user' information can be easily drawn from the address.
from the address. However complex Mail-11 addresses cannot be However complex Mail-11 addresses cannot be embedded easily into
embedded easily into this syntax. this syntax.
A.3 Recommended mappings A.3 Recommended mappings
From the examples seen in the previous paragraphs we From the examples seen in the previous paragraphs we can derive a
can derive a canonical form for representing the mapping between canonical form for representing the mapping between Mail-11 and
Mail-11 and RFC822. RFC822.
A3.1 RFC822 mapped in Mail-11 A3.1 RFC822 mapped in Mail-11
The mapping of an RFC 822 address in Mail-11 is The mapping of an RFC822 address in Mail-11 is straightforward, using
straightforward, using the "Mail-11 foreign mail protocol" the "Mail-11 foreign mail protocol" syntax. The two possible variants
syntax. The two possible variants are: are:
[[node::][node::]...]prot%"rfc-822-address" [[node::][node::]...]prot%"rfc-822-address"
or or
[node::][node::]...]::"rfc-822-address" [node::][node::]...]::"rfc-822-address"
A3.2 Mail-11 mapped in RFC822 A3.2 Mail-11 mapped in RFC822
RFC822 foresee a canonical form for representing RFC822 foresee a canonical form for representing non-RFC822
non-RFC822 addresses: put the foreign address in local part addresses: put the foreign address in local part (Left Hand Side,
(Left Hand Side, LHS) is a form as similar as possible to its LHS) is a form as similar as possible to its original syntax. Thus
original syntax. Thus the suggested mapping is: the suggested mapping is:
"Mail-11-address"@gateway-address "Mail-11-address"@gateway-address
This format assures also the return path via the appropriate This format assures also the return path via the appropriate gateway.
gateway.
A.4 Conclusions A.4 Conclusions
A standard way of mapping Mail-11 addresses into A standard way of mapping Mail-11 addresses into RFC822 and vice
RFC 822 and vice versa is feasible. A suggestion is thus made to versa is feasible. A suggestion is thus made to unify all existing
unify all existing and future implementations. It should be and future implementations. It should be noted, however, that there
noted, however, that there is no way to specify in these is no way to specify in these mappings the name of the decnet
mappings the name of the decnet community owning the encoded community owning the encoded address, as it was done for X.400, thus
address, as it was done for X.400, thus the implementation of the implementation of the 'intelligent' gateway in this case is
the 'intelligent' gateway in this case is impossible. impossible.
Acknowledgements Acknowledgements
I wish to thank all those people which read the first I wish to thank all those people who read the first draft and
draft and contributed a lot with their useful suggestions to the contributed a lot with their useful suggestions to the revision of
revision of this document, in particular RARE WG1 and IETF X.400 this document, in particular RARE WG1 and IETF X.400 ops group
ops group members and S. Hardcastle-Kille. members and S. Hardcastle-Kille.
Author's address References
Claudio Allocchio Phone: +39 40 3758523 [1] CCITT, "CCITT Recommendations X.400-X.430", Message Handling
Cosine S2.2 Fax: +30 49 226338 Systems: Red Book, October 1984.
Sincrotrone Trieste e-mail: allocchio@elettra.trieste.it
c/o Area di Ricerca
Padriciano 99
I 34012 Trieste (TS)
Italy
References [2] CCITT, "CCITT Recommendations X.400-X.420", Message Handling
Systems: Blue Book, November 1988.
CCITT, "CCITT Recommendations X.400-X.430," Message Handling [3] Crocker, D., "Standard of the Format of ARPA Internet Text
Systems: Red Book, October 1984 Messages", STD 11, RFC 822, UDel, August 1982.
CCITT, "CCITT Recommendations X.400-X.420," Message Handling [4] Kille, S., "Mapping Between X.400 and RFC 822", UK Academic
Systems: Blue Book, November 1988 Community Report (MG.19) / RFC 987, June 1986.
D.H. Crocker, "Standard of the Format of ARPA Internet Text [5] Kille, S., "Mapping Between X.400(1988) / ISO 10021 and RFC
Messages," RFC 822, August 1982. 822", RFC 1327, March 1992.
S.E. Kille, "Mapping Between X.400 and RFC 822," UK Academic [6] Digital Equipment Corp.;, "VAX/VMS Mail Utility".
Community Report (MG.19) / RFC 987, June 1986.
S.E. Kille, "Mapping Between X.400(1988) / ISO 10021 and RFC [7] Joiner Associates Inc., "Jnet User's Manual".
822," RFC 1327, March 1992.
Digital Equipment Corp.;, "VAX/VMS Mail Utility" [8] PMDF User's Guide.
Joiner Associates Inc., "Jnet User's Manual" Security Considerations
PMDF User's Guide. Security issues are not discussed in this memo.
Document Expiration Date Author's Address
This document was submitted on September 23rd, 1992 and its Claudio Allocchio
validity will expire on March 23rd 1993. Cosine S2.2
Sincrotrone Trieste
Area di Ricerca
Padriciano 99
I 34012 Trieste
Italy
Phone: +39 40 3758523
Fax: +39 40 226338
EMail: Claudio.Allocchio@elettra.Trieste.it
C=it; A=garr; P=Trieste; O=Elettra; S=Allocchio; G=Claudio;
 End of changes. 285 change blocks. 
657 lines changed or deleted 599 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/