/ "#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.
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 RFC822 single quote character.
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.
RFC987 June 1986
Mapping between X.400 and RFC822
2. 822.local-part <-> 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.
There are places where it is needed to convert between
PrintableString or IA5Text (X.400), and 822.word (RFC822). 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 RFC822 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.
These mappings are somewhat artificial, and their usage is
discouraged, except in cases where there is no alternative.
RFC987 June 1986
Mapping between X.400 and RFC822
Appendix B -- Mappings Specific to JNT Mail
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.
1. Introduction
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.
2. Acknowledge-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.
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:
a. Acknowledgement(s) should be generated by the gateway.
The text of these acknowledgements should indicate that
they are generated by the gateway.
b. The Acknowledge-To: field should also be passed in the
first 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.
3. Trace
JNT Mail trace uses the Via: syntax. When going from JNT Mail to
X.400, the following mapping onto P1.TraceInformation is used.
P1.DomainSuppliedInfo.action is set to relayed.
P1.DomainSuppliedInfo.arrival is set to the date-time component
RFC987 June 1986
Mapping between X.400 and RFC822
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:
Via: UK.AC.Edinburgh ; 17 Jun 85 9:15:29 BST (EMAS 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"
4. Timezone specification
The extended syntax of zone defined in the JNT Mail Protocol
should be used in the mapping of UTCTime defined in chapter 3.
5. Lack of separate 822-P1 originator specification
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
RFC822 systems [Kille84b].
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.
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
RFC987 June 1986
Mapping between X.400 and RFC822
mapped onto the Sender: field, and P2.Heading.originator mapped
onto the Original-Sender: field.
In other cases the P1.MPDUEnvelope.Originator is already correctly
represented.
Note that in some pathological cases, this mapping is
asymmetrical.
RFC987 June 1986
Mapping between X.400 and RFC822
Appendix C -- Mappings Specific to Internet Mail
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.
1. Mapping between O/R names and SMTP addresses
The mappings of Chapter 4 are to be used.
2. Use of the ARPA Domain System
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.
3. Identification of gateways
The ARPA-Internet Network Information Center (NIC) will maintain a
list of registered X.400 gateways in the ARPA Internet.
RFC987 June 1986
Mapping between X.400 and RFC822
Appendix D -- Mappings Specific to Phonenet Mail
There are currently no mappings specific to Phonenet Mail.
RFC987 June 1986
Mapping between X.400 and RFC822
Appendix E -- Mappings Specific to UUCP Mail
Gatewaying of UUCP and X.400 is handled by first gatewaying the UUCP
address into RFC822 syntax (using RFC976) [Horton86a] and then
gatewaying the resulting RFC822 address into X.400. For example, an
X.400 address
Country US
Organization Xerox
Personal Name John Smith
might be expressed from UUCP as
inthop!gate!gatehost.COM!/C=US/O=Xerox/PN=John.Smith/
(assuming gate is a UUCP-ARPA gateway and gatehost.COM is an
ARPA-X.400 gateway) or
inthop!gate!Xerox.COM!John.Smith
(assuming that Xerox.COM and /C=US/O=Xerox/ are equivalent.)
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:
Country US
ADMD ATT
PRMD ARPA
Organization GateOrg
RFC-822 inthop!dest!user@gatehost.COM
or through a single X.400 to UUCP gateway:
Country US
ADMD ATT
PRMD UUCP
Organization GateOrg
UUCP inthop!dest!user
RFC987 June 1986
Mapping between X.400 and RFC822
Appendix F -- Format of Address Mapping Tables
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:
domain-syntax "#" dmn-orname "#"
For example:
AC.UK#PRMD$DES.ADMD$BT.C$UK#
XEROX.COM#O$Xerox.ADMD$ATT.C$US#
For X.400 -> domain:
dmn-orname "#" domain-syntax "#"
EBNF.domain-syntax will be interpreted according to RFC920.
EBNF.dmn-orname will have components ordered as defined in section
4.2.1, and with the most significant component on the RHS.
RFC987 June 1986
Mapping between X.400 and RFC822
References
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.
CCITT84a.
CCITT SG 5/VII, "Recommendations X.400," Message Handling Systems:
System Model - Service Elements, October 1984.
CCITT84b.
CCITT SG 5/VII, "Recommendations X.411," Message Handling Systems:
Message Transfer Layer, October 1984.
CCITT84c.
CCITT SG 5/VII, "Recommendations X.420," Message Handling Systems:
Interpersonal Messaging User Agent Layer, October 1984.
CCITT84d.
CCITT SG 5/VII, "Recommendations X.409," Message Handling Systems:
Presentation Transfer Syntax and Notation, October 1984.
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.
Crocker82a.
D.H. Crocker, "Standard of the Format of ARPA Internet Text
Messages," RFC822, August 1982.
Horton85a.
M.R. Horton, "Draft Standard for ARPA/MHS Addressing Gateways,"
AT&T Bell Laboratories, October 1985.
RFC987 June 1986
Mapping between X.400 and RFC822
Horton86a.
M.R. Horton, "UUCP Mail Interchange Format Standard", RFC976,
February 1986.
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.
Kille84a.
S.E. Kille, (editor), JNT Mail Protocol (revision 1.0), Joint
Network Team, Rutherford Appleton Laboratory, March 1984.
Kille84b.
S.E. Kille, "Gatewaying between RFC822 and JNT Mail," JNT
Mailgroup Note 15, May 1984.
Kille86a.
S.E. Kille, "O/R Names in the UK Academic Community," UK Working
Document, March 1986.
Larmouth83a.
J. Larmouth, "JNT Name Registration Technical Guide," Salford
University Computer Centre, April 1983.
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.
Postel82a.
J. Postel, "Simple Mail Transfer Protocol," RFC821, August 1982.
Postel84a.
J. Postel and J. Reynolds, "Domain Requirements," RFC920,
October 1984.
RFC987 June 1986
Mapping between X.400 and RFC822
Rose85a.
M.T. Rose, "Mapping Service Elements between ARPA and MHS," Draft
proposal, October 1985.
Rose85b.
M.T. Rose and E.A. Stefferud, "Proposed Standard for Message
Encapsulation," RFC934, January 1985.
RFC987 June 1986
Mapping between X.400 and RFC822
Notes:
<0> UNIX is a trademark of Bell Laboratories.
<1> The term gateway is used to describe a component performing the
protocol mappings between RFC822 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".)
<2> If the remote protocol is JNT Mail, a notification may also be
sent by the recipient 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.
<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.
<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.
<6> P2.ORname is defined as P1.ORName.
<7> This recommendation may change in the light of CCITT or
CEN/CENELEC guidelines on the use of initials.
<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.
<9> Although this violates chapter 1, part 4, principles 2 and 3, it
is suggested that this is justified by principle 1.