S.Kille@CS.UCL.AC.UK (Steve Kille) (07/14/89)
Kille [page 94]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
Appendix A - Quoted String 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.
WARNING: THIS APPENDIX IS RETAINED FOR BACKWARDS |
COMPATIBILITY WITH RFC 987. ITS USE IS DEPRECATED. |
WHERE USED, THE REVERSE PATH MUST BE THROUGH A GATEWAY |
WHICH ALSO USES THIS SPECIFICATION.
1. Introduction
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.
These mappings are somewhat artificial, and their usage is
discouraged, except in cases where there is no alternative.
2. ASCII <-> 822.atom
The following EBNF is specified.
Kille [page 95]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
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 "#"
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, and
is interpreted in decimal as the corresponding ASCII character.
The choice of special abbreviations (as opposed to decimal
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.
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.
3. 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
Kille [page 96]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
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.
Kille [page 97]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
Appendix B - Mappings specific to the JNT Mail
This Appendix is specific to the JNT Mail Protocol. It
describes specific changes in the context of this
protocol.
1. Introduction
There are five aspects of a gateway which are JNT Mail Specific.
These are each given a section of this appendix.
2. Domain Ordering
When interpreting and generating domains, the UK NRS domain
ordering must be used.
3. 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.
If an Acknowledge-To: field is present when going from JNT
Mail to X.400,
MTS.PerRecipientSubmissionFields.originator-request-report.report
shall be set for each recipient. If there is more that one
address in the Acknowledge-To: field, or if the one address is
not equivalent to the 822-MTS return address, then:
1. Acknowledgement(s) should be generated by the gateway. The
text of these acknowledgements should indicate that they are
generated by the gateway.
2. The Acknowledge-To: field should also be passed as an
extension header.
When going from X.400 to JNT Mail, in cases where
MTA.PerRecipientMessageTransferFields.per-recipient-indicators.
originator-report is set, the copy of the message to that
recipient should have an Acknowledge-To: field containing the
MTS.OtherMessageDeliveryFields.originator-name. No special
treatment should be given when
MTA.PerRecipientMessageTransferFields.per-recipient-indicators.
Kille [page 98]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
originating-MTA-report is set. No attempt should be made to map
Receipt notification requests onto Acknowledge-To:, as no
association can be guaranteed between IPMS and MTS level
addressing information.
4. Trace
JNT Mail trace uses the Via: syntax. When going from JNT Mail to
X.400, a mapping similar to that for Received: is used. No
MTS.GlobalDomainIdentifier of the site making the trace can be
derived from the Via:, so a value for the gateway should be used.
The trace text, including the "Via:", should be unfolded,
truncated to MTS.ub-mta-name-length (32), and mapped to
MTA.InternalTraceInformationElement.mta-name.
5. 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.
6. Lack of 822-MTS originator specification
In JNT Mail the default mapping of the P1.MPDUEnvelope.originator
is to the Sender: field. This can cause a problem when going
from X.400 to JNT Mail 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].
original-sender = "Original-Sender" ":" mailbox
If an IPM has no IPMS.Heading.authorising-users component and
IPMS.Heading.originator.formal-name is different from
MTS.OtherMessageDeliveryFields.originator-name, map
MTS.OtherMessageDeliveryFields.originator-name, onto the Sender:
field.
If an IPM has a IPMS.Heading.authorising-users component, and
IPMS.Heading.originator.formal-name is different from
MTS.OtherMessageDeliveryFields.originator-name,
MTS.OtherMessageDeliveryFields.originator-name should be mapped
onto the Sender: field, and IPMS.Heading.originator mapped onto
the Original-Sender: field.
Kille [page 99]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
In other cases the
MTS.OtherMessageDeliveryFields.originator-name, is already
correctly represented.
Note that in some pathological cases, this mapping is
asymmetrical.
Kille [page 100]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
Appendix C - Mappings specific to UUCP Mail |
Gatewaying of UUCP and X.400 is handled by first gatewaying *
the UUCP address into RFC 822 syntax (using RFC 976) and
then gatewaying the resulting RFC 822 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 through 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
RFC-822 inthop!dest!user
Kille [page 101]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
Appendix D - Object Identifier Assignment |
An object identifier is needed for the extension IPMS element. *
The following initial assignment is given.
rfc-987-88 OBJECT IDENTIFIER ::=
{ccitt data(9) pss(2342) ucl(234219200300) rfc-987-88(200)}
id-rfc-822-field OBJECT IDENTIFIER ::= {rfc987-88 field(0)}
Kille [page 102]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
Appendix E - BNF Summary |
boolean = "TRUE" / "FALSE"
numericstring = *DIGIT
printablestring = *( ps-char )
ps-restricted-char = 1DIGIT / 1ALPHA / " " / "'" / "+"
/ "," / "-" / "." / "/" / ":" / "=" / "?"
ps-delim = "(" / ")"
ps-char = ps-delim / ps-restricted-char
ps-encoded = *( ps-restricted-char / ps-encoded-char )
ps-encoded-char = "(a)" ; (@)
/ "(p)" ; (%)
/ "(b)" ; (!)
/ "(q)" ; (")
/ "(u)" ; (_)
/ "(l)" ; "("
/ "(r)" ; ")"
/ "(" 3DIGIT ")"
teletex-string = *( ps-char / t61-encoded ) |
t61-encoded = "{" 1* t61-encoded-char "}" |
t61-encoded-char = 3DIGIT |
teletex-and-or-ps = [ printablestring ] [ "*" teletex-string ]|
labelled-integer ::= key-string "(" numericstring ")"
Kille [page 103]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
object-identifier ::= [ defined-value ] oid-comp-list
oid-comp-list ::= oid-comp oid-comp-list
| oid-comp
defined-value ::= key-string
oid-comp ::= [ key-string ] "(" numericstring ")"
key-string = *key-char
key-char = <a-z, A-Z, 1-9, and "-">
encoded-info = 1#encoded-type
encoded-type = built-in-eit / object-identifier
built-in-eit = "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)
encoded-pn = [ given "." ] *( initial "." ) surname
given = 2*<ps-char not including ".">
initial = ALPHA
surname = printablestring
Kille [page 104]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
std-or-address = 1*( "/" attribute "=" value ) "/"
attribute = standard-type
/ "RFC-822"
/ registered-dd-type
/ dd-key "." std-printablestring
standard-type = key-string
registered-dd-type
= key-string
dd-key = key-string
value = std-printablestring
std-printablestring |
= *( std-char / std-pair )
std-char = <"{", "}", "*", and any ps-char
except "/" and "=">
std-pair = "$" ps-char
dmn-or-address = dmn-part *( "." dmn-part )
dmn-part = attribute "$" value
attribute = standard-type
/ "~" dmn-printablestring
value = dmn-printablestring
/ "@"
dmn-printablestring =
= *( dmn-char / dmn-pair )
dmn-char = <"{", "}", "*", and any ps-char
except ".">
dmn-pair = "\."
global-id = std-or-address
mta-field = "X400-Received" ":" x400-trace |
/ "Deferred-Delivery" ":" date-time
/ "Latest-Delivery-Time" ":" date-time |
Kille [page 105]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
x400-trace = "by" [ "mta" mta "in" ] global-id ";" |
[ "deferred until" date-time ";" ] |
[ "converted" "(" encoded-info ")" ]
[ "attempted domain" global-id ";" ] |
action-list |
";" date-time |
mta = word |
arrival-time = date-time |
routing-action = |
other-action-list = 1#action |
action = "Redirected" |
/ "Expanded" |
/ "Relayed" |
/ "Rerouted" |
Kille [page 106]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
dr-body-format = dr-summary <CRLF> ||
dr-recipients <CRLF> ||
dr-extra-information <CRLF> ||
dr-content-return ||
dr-content-return = "The Original Message is not available"||
/ "The Original Message follows:" ||
<CRLF> <CRLF> message ||
dr-summary = "This report relates to your message:" <CRLF> ||
content-correlator <CRLF> <CRLF> ||
"Which failed at" failure-point <CRLF> ||
dr-recipients = *(dr-recipient <CRLF> <CRLF>) ||
dr-recipient = dr-recip-success / dr-recip-failure ||
dr-recip-success = ||
"Your message was successfully delivered to:"||
mailbox ||
dr-recip-failure = "Your message was not delivered to:" ||
mailbox <CRLF> ||
"for the following reason:" *word ||
Kille [page 107]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
dr-extra-information = ||
"The following information is derived from the Report" <CRLF>||
"It may be useful for problem diagnosis:" <CRLF> <CRLF> ||
drc-field-list = *(drc-field <CRLF>) ||
drc-field = "Subject-Submision-Identifier" ":" ||
mts-msg-id ||
/ "Content-Identifier" ":" printablestring ||
/ "Content-Type" ":" mts-content-type ||
/ "Original-Encoded-Information-Types" ":" ||
encoded-info ||
/ "Originator-and-DL-Expansion-History" ":" ||
dl-history ||
/ "Reporting-DL-Name" ":" mailbox ||
/ "Content-Correlator" ":" content-correlator ||
/ "Recipient-Info" ":" recipient-info ||
recipient-info = mailbox "," std-or ";" ||
report-type ||
[ "converted eits" encoded-info ";" ] ||
[ "originally intended recipient" ||
mailbox "," std-or ";" ] ||
[ "supplementary info" printablestring ] ||
[ "redirection history" 1#redirection ] ||
[ "physical forwarding address" ||
printablestring ] ||
report-type = "SUCCESS" drc-success
/ "FAILURE" drc-failure
drc-success = "delivered at" date-time ";"
[ "type of MTS user" labelled-integer ";" ] |
drc-failure = "reason" labelled-integer ";"
[ "diagnostic" labelled-integer ";" ] |
failure-point = [ "mta" word "in" ] global-id ||
content-correlator = *word ||
dl-history = 1#mailbox ||
Kille [page 108]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
mts-field = "X400-MTS-Identifier" ":" mts-msg-id ||
/ "X400-Originator" ":" mailbox ||
/ "X400-Recipients" ":" 1#mailbox ||
/ "Original-Encoded-Information-Types" ":" ||
encoded-info ||
/ "X400-Content-Type" ":" mts-content-type ||
/ "Content-Identifier" ":" printablestring ||
/ "Priority" ":" priority |
/ "Originator-Return-Address" ":" 1#mailbox ||
/ "DL-Expansion-History" ":" mailbox ";" date-time ";"||
/ "Redirection-History" ":" redirection ||
/ "Conversion" ":" prohibition ||
/ "Conversion-With-Loss" ":" prohibition ||
/ "Requested-Delivery-Method" ":" ||
1*( labelled-integer ) ||
/ "Discarded-X400-MTS-Extensions" ":" 1#oid ||
prohibition = "Prohibited" / "Allowed" |
mts-msg-id = global-id ";" *text |
mts-content-type = "P2" / labelled-integer |
/ object-identifer |
priority = "normal" / "non-urgent" / "urgent"
redirection = mailbox ";" "reason" "=" |
redirection-reason |
redirection-reason =
"Recipient Assigned Alternate Recipient" |
/ "Originator Requested Alternate Recipient"
/ "Recipient MD Assigned Alternate Recipient" |
Kille [page 109]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
ipn-body-format = ipn-description <CRLF> ||
[ ipn-extra-information <CRLF> ] ||
ipn-content-return ||
ipn-preamble = * ( printablestring <CRLF> ) ||
ipn-description = ipn-receipt / ipn-non-receipt ||
ipn-receipt = "Your message to:" preferred-recipient <CRLF>||
"was received at" receipt-time <CRLF> <CRLF> ||
"This notification was generated" ||
acknowledgement-mode <CRLF> ||
"The following extra information was given:" <CRLF>||
ipn-suppl <CRLF> ||
ipn-non-receipt "Your message to:" ||
preferred-recipient <CRLF> ||
ipn-reason ||
ipn-reason = ipn-discarded / ipn-auto-forwarded ||
ipn-discarded = "was discarded for the following reason:" ||
discard-reason <CRLF> ||
ipn-auto-forwarded = "was automatically forwarded." <CRLF> ||
[ "The following comment was made:" ||
auto-comment ] ||
ipn-extra-information = ||
"The following information types were converted:" ||
encoded-info ||
ipn-content-return = "The Original Message is not available"||
/ "The Original Message follows:" ||
<CRLF> <CRLF> message ||
Kille [page 110]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
preferred-recipient = mailbox ||
receipt-time = date-time ||
auto-comment = printablestring ||
ipn-suppl = printablestring ||
non-receipt-reason = "Discarded" / "Auto-Forwarded"
discard-reason = "Expired" / "Obsoleted" /
"User Subscription Terminated" |
acknowledgement-mode = "Manually" / "Automatically" |
ipms-field = "Obsoletes" ":" 1#msg-id
/ "Expiry-Date" ":" date-time
/ "Reply-By" ":" date-time
/ "Importance" ":" importance
/ "Sensitivity" ":" sensitivity
/ "Autoforwarded" ":" boolean
/ "Incomplete-Copy" ":"
/ "Language" ":" language
/ "Message-Type" ":" message-type |
/ "Discarded-X400-IPMS-Extensions" ":" 1#oid |
importance = "low" / "normal" / "high"
sensitivity = "Personal" / "Private" /
"Company-Confidential" |
language = 2*ALPHA [ language-description ] |
language-description = printable-string
message-type = "Delivery Report"
/ "InterPersonal Notification"
/ "Multiple part"
Kille [page 111]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
Appendix F - Format of address mapping tables |
There is a need to specify the association between the domain and |
X.400 namespaces described in Chapter 4. The use of this |
association leads to a better service on both sides of the |
gateway, and so defining mappings and distributing them in the |
form defined in this appendix is strongly encouraged. |
This syntax defined is initially in table form, but the |
syntax is defined in a manner which makes it suitable for use |
with domain nameservices (such as the DARPA Domain nameservers or |
the UK NRS). The mapping is not symmetric, and so a separate |
table is specified for each direction. If multiple matches are |
possible, the longest possible match should be used. |
First, an address syntax is defined, which is compatible |
with the syntax used for 822.domains. It is intended that this |
syntax may be used in conjunction with systems which support this |
form of name. |
To allow the mapping of null attributes to be represented, |
the pseudo-value "@" (not a printable string character) is used |
to indicate omission of a level in the hierarchy. This is |
distinct from the form including the element with no value, |
although a correct X.400 implementation will interpret both in |
the same manner. |
This syntax is not intended to be handled by users. |
dmn-or-address = dmn-part *( "." dmn-part )
dmn-part = attribute "$" value
attribute = standard-type
/ "~" dmn-printablestring
value = dmn-printablestring
/ "@"
dmn-printablestring =
= *( dmn-char / dmn-pair )
dmn-char = <"{", "}", "*", and any ps-char
except ".">
dmn-pair = "\."
An example usage: |
Kille [page 112]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
~ROLE$Big\.Chief.ADMD$ATT.C$US
PRMD$DEC.ADMD$@.C$US
The first example illustrates quoting of a ".", and the second |
omission of the ADMD level. |
Various further restrictions are placed on the usage of |
dmn-or-address: |
1. Only C, ADMD, PRMD, O, and OU may be used. |
2. There must be a strict ordering of all components, with the |
most significant components on the RHS. |
3. No components may be omitted from the hierarchy, although |
the hierarchy may terminate at any level. If the mapping is |
to an omitted component, the "@" syntax is used. |
For domain -> X.400: |
domain-syntax "#" dmn-or-address "#"
Note that the trailing "#" is used for clarity, as the dmn-or- |
address syntax can lead to values with trailing blanks. Lines |
staring with "#" are comments. |
For example:
AC.UK#PRMD$UK\.AC.ADMD$GOLD 400.C$GB#
XEROX.COM#O$Xerox.ADMD$ATT.C$US#
GMD.DE#O$@.PRMD$GMD.ADMD$DBP.C$DE#
For X.400 -> domain: |
dmn-or-address "#" domain-syntax "#"
For example:
#
# Mapping table
#
PRMD$UK\.AC.ADMD$GOLD 400.C$GB#AC.UK#
Kille [page 113]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
Appendix G - Differences with RFC 987 |
This appendix summarises changes between this document and RFC
987/RFC 1026.
1. Introduction
The model has shifted from a protocol based mapping to a service
based mapping. This has increased the generality of the
specification, and improved the model. This change affects the
entire document.
A restriction on scope has been added.
2. Service Elements
- The new service elements of X.400 are dealt with.
- A clear distinction is made between origination and
reception
3. Basic Mappings
- Add teletex support
- Add object identifier support
- Add labelled integer support
- Make PrintableString <-> ASCII mapping reversible
- The printable string mapping is aligned to the NBS mapping
derived from RFC 987.
4. Addressing
- Support for new addressing attributes
- The message ID mapping is changed to not be table driven *
Kille [page 114]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
5. Detailed Mappings
- Define extended IPM Header, and use instead of second body |
part for RFC 822 extensions
- Realignment of element names
- New syntax for reports, simlifying the header and |
introducing a mandatory body format (the RFC 987 header |
format was unusable)
- Drop complex autoforwarded mapping
- Add full mapping for IP Notifications, defining a body |
format
- Adopt an MTS Identifier syntax in line with the O/R Address
syntax |
- A new format for X400 Trace representation on the RFC 822 |
side |
6. Appendices |
- Retain, but discourage use of Appendix A |
- Delete Phonenet and SMTP Appendixes
Kille [page 115]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
References
CCITT88a.
CCITT, "Specification of Abstract Syntax Notation One
(ASN.1)," CCITT Recommendation X.208 / ISO IS 8824, December
1988.
CCITT88b.
CCITT, "CCITT Recommendations X.408," Message Handling
Systems: Encoded Information Type Conversion Rules, December
1988.
CCITT/ISO88a.
CCITT/ISO, "CCITT Recommendations X.400/ ISO IS 10021-1,"
Message Handling: System and Service Overview , December
1988.
CCITT/ISO88b.
CCITT/ISO, "CCITT Recommendations X.420/ ISO IS 10021-7,"
Message Handling Systems: Interpersonal Messaging System,
December 1988.
CCITT/ISO88c.
CCITT/ISO, "CCITT Recommendations X.411/ ISO IS 10021-3,"
Message Handling Systems: Message Transfer System: Abstract
Service Definition and Procedures, December 1988.
Crocker82a.
D.H. Crocker, "Standard of the Format of ARPA Internet Text
Messages," RFC 822, August 1982.
Horton86a.
M.R. Horton, "UUCP Mail Interchange Format Standard," RFC
976, February 1986.
Kille84b.
S.E. Kille, "Gatewaying between RFC 822 and JNT Mail," JNT
Mailgroup Note 15, May 1984.
Kille84a.
S.E. Kille (Editor), JNT Mail Protocol (revision 1.0), Joint
Network Team, Rutherford Appleton Laboratory, March 1984.
Kille [page 116]
RFC 987(88)
Mapping between X.400(1988) and RFC 822 DRAFT Version 2.0
Kille86a.
S.E. Kille, "Mapping Between X.400 and RFC 822," UK Academic
Community Report (MG.19) / RFC 987, June 1986.
Kille87a.
S.E. Kille, "Addendum to RFC 987," UK Academic Community
Report (MG.23) / RFC 1026, August 1987.
Kille89a.
S.E. Kille, "A String Encoding of Presentation Address," UCL
Research Note 89/14, March 1989.
Larmouth83a.
J. Larmouth, "JNT Name Registration Technical Guide,"
Salford University Computer Centre, April 1983.
Postel84a.
J. Postel and J. Reynolds, "Domain Requirements," RFC 920,
October 1984.
Postel82a.
J.B. Postel, "SIMPLE MAIL TRANSFER PROTOCOL," RFC 821,
August 1982.
Rose85a.
M.T. Rose and E.A. Stefferud, "Proposed Standard for Message
Encapsulation," RFC 934, January 1985.
Systems85a.
CEN/CENELEC/Information Technology/Working Group on Private
Message Handling Systems, "FUNCTIONAL STANDARD A/3222,"
CEN/CLC/IT/WG/PMHS N 17, October 1985.
Kille [page 117]