/ "Content-Correlator" ":" content-correlator
/ "Recipient-Info" ":" recipient-info
/ "Subject-Intermediate-Trace-Information" ":"
x400-trace
recipient-info = mailbox "," std-or ";"
report-type
[ "converted eits" encoded-info ";" ]
[ "originally intended recipient"
mailbox "," std-or ";" ]
[ "last trace" [ encoded-info ] date-time ";" ]
[ "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 ";" ]
report-point = [ "mta" word "in" ] global-id
content-correlator = *word
dl-history = 1#( mailbox "(" date-time ")")
The format is defined as a fixed definition. The only exception is
that the EBNF.drc-fields should follow RFC822 folding rules.
The elements of MTS.ReportDeliveryEnvelope.per-report-fields are
mapped as follows onto extended RFC822 fields:
subject-submission-identifier
Mapped to EBNF.drc-field (Subject-Submission-Identifier)
content-identifier
Mapped to EBNF.drc-field (Content-Identifier)
content-type
Mapped to EBNF.drc-field (Content-Type)
original-encoded-information-types
Mapped to EBNF.drc-field (Encoded-Info)
The extensions from
MTS.ReportDeliveryEnvelope.per-report-fields.extensions are
mapped as follows:
originator-and-DL-expansion-history
Mapped to EBNF.drc-field (Originator-and-DL-Expansion-
History)
reporting-DL-name
Mapped to EBNF.drc-field (Reporting-DL-Name)
content-correlator
Mapped to EBNF.content-correlator, provided that the
encoding is IA5String (this should always be the case).
This is used in EBNF.dr-summary and EBNF.drc-field-list.
In the former, LWSP may be added, in order to improve the
layout of the message.
message-security-label
reporting-MTA-certificate
report-origin-authentication-check
These security parameters should not be present. If they are,
they should be discarded in preference to discarding the whole
report.
For each element of MTS.ReportDeliveryEnvelope.per-recipient-fields,
a value of EBNF.dr-recipient, and an EBNF.drc-field (Recipient-Info)
should be generated. The components are mapped as follows.
actual-recipient-name
Used to generate the first EBNF.mailbox and EBNF.std-or in
EBNF.recipient-info. Both RFC822 and X.400 forms are
given, as there may be a problem in the mapping tables. It
also generates the EBNF.mailbox in EBNF.dr-recip-success or
EBNF.dr-recip-failure.
report
If it is MTS.Report.delivery, then set EBNF.dr-recipient to
EBNF.dr-recip-success, and similarly set EBNF.report-type,
filling in EBNF.drc-success. If it is a failure, set
EBNF.dr-recipient to EBNF.dr-recip-failure, making a human
interpretation of the reason and diagnostic codes, and
including any supplementary information. EBNF.drc-failure
should be filled in systematically.
converted-encoded-information-types
Set EBNF.drc-field ("converted eits")
originally-intended-recipient
Set the second ("originally intended recipient") mailbox
and
std-or in EBNF.drc-field.
supplementary-info
Set EBNF.drc-field ("supplementary info"), and include this
information in EBNF.dr-recip-failure.
redirection-history
Set EBNF.drc-field ("redirection history")
physical-forwarding-address
Set ENBF.drc-field ("physical forwarding address")
recipient-certificate
Discard
proof-of-delivery
Discard
Any unknown extensions should be discarded, irrespective of
criticality.
The original message should be included in the delivery port. The
original message will usually be available at the gateway, as
discussed in Section 5.2.
5.3.8.2. MTA Mappings
The single 822-MTS recipient is constructed from
MTA.ReportTransferEnvelope.report-destination-name, using the
mappings of Chapter 4. Unlike with a user message, this information
is not available at the MTS level.
The following additional mappings should be made:
MTA.ReportTransferEnvelope.report-destination-name
This should be used to generate the To: field.
MTA.ReportTransferEnvelope.identifier
Mapped to the extended RFC822 field "X400-MTS-Identifier:".
It may also be used to derive a "Message-Id:" field.
MTA.ReportTransferEnvelope.trace-information
and
MTA.ReportTransferEnvelope.internal-trace-information
Mapped onto the extended RFC822 field "X400-Received:", as
described in Section 5.3.7. The first element should also
be used to generate the "Date:" field, and the
EBNF.failure-point.
MTA.PerRecipientReportTransferFields.last-trace-information
Mapped to EBNF.recipient-info (last trace)
MTA.PerReportTransferFields.subject-intermediate-trace-information
Mapped to EBNF.drc-field (subject-Intermediate-Trace-Information).
These fields should be ordered so that the most recent trace element
comes first.
5.3.8.3. Example Delivery Report
This is an example, of a moderately complex report.
From: The Postmaster <postmaster@cs.ucl.ac.uk>
To: jpo@computer-science.nottingham.ac.uk
Subject: X.400 Delivery Report
Message-Type: Delivery Report
Date: Wed, 21 Jun 89 08:45:25 +0100
X400-MTS-Identifier: /PRMD=UK.AC/ADMD=Gold 400/C=GB/;13412345235
This report relates to your message:
Date: Wed, 21 Jun 89 06:15:43 +0000
Message-ID: <8907140715.aa09015@CS.Nott.AC.UK>
Subject: Now it's the fine tuning .... !
To: Piete Brooks (Postmaster) <pb@computer-lab.cambridge.ac.uk>
of Wed, 21 Jun 89 06:15:43 +0000
It was generated by mta PK in /PRMD=UK/ADMD=DBP/C=DE/
at Wed, 21 Jun 89 08:45:25 +0100
It was later converted to RFC822 by: Mail-Gateway@oxbridge.ac.uk
at Wed, 21 Jun 89 08:45:26 +0100
Your message was not delivered to: bad-user@nowhere
for the following reason: Rendition problem with punctuation
(Umlaut failure)
-----------------------------------------------
The following information is derived from the Report
It may be useful for problem diagnosis:
Subject-Submission-Identifier:
[/PRMD=UK.AC/ADMD=Gold 400/C=GB/;148996]
Content-Identifier: X.400 Delivery Report
Content-Type: P2-1988 (22)
Original-Encoded-Information-Types: ia5
Content-Correlator: Date: Wed, 21 Jun 89 06:15:43 +0000
Message-ID: <8907140715.aa09015@CS.Nott.AC.UK>
Subject: Now it's the fine tuning .... !
To: Piete Brooks (Postmaster) <pb@computer-lab.cambridge.ac.uk>
Recipient-Info:
bad-user@nowhere, /S=bad-user/PRMD=nowhere/ADMD=DBP/C=DE/ ;
FAILURE reason Physical-Rendition-Not-Performed (3) ;
diagnostic Punctuation-Symbol-Loss (23) ;
supplementary info Umlaut failure
The Original Message follows:
Subject: Now it's the fine tuning .... !
Date: Wed, 21 Jun 89 06:15:43 +0000
From: Julian Onions <jpo@computer-science.nottingham.ac.uk>
To: Piete Brooks (Postmaster) <pb@computer-lab.cambridge.ac.uk>
Cc: bad-user@nowhere
Message-ID: <8907140715.aa09015@CS.Nott.AC.UK>
A short test
5.3.9. Probe
This is an MTS internal issue. Any probe should be serviced by the
gateway, as there is no equivalent RFC822 functionality. The value
of the reply is dependent on whether the gateway could service an MTS
Message with the values specified in the probe. The reply should
make use of MTS.SupplementaryInformation to indicate that the probe
was serviced by the gateway.
Appendix A - Differences with RFC987
This appendix summarises changes between this document and RFC
987/RFC1026.
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 RFC987.
4. Addressing
- Support for new addressing attributes.
- The message ID mapping is changed to not be table driven.
5. Detailed Mappings
- Define extended IPM Header, and use instead of second body
part for RFC822 extensions.
- Realignment of element names.
- New syntax for reports, simplifying the header and
introducing a mandatory body format (the RFC987 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 RFC822
side.
6. Appendices
- Move Appendix on restricted 822 mappings to a separate RFC.
- Delete Phonenet and SMTP Appendixes.
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 heading.
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. 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. There is no JNT Mail
specific mapping for the reverse direction.
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
MTS.OtherMessageDeliveryFields.originator-name is to the Sender:
field. This can cause a problem when going from X.400 to JNT Mail if
the mapping of IPMS.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 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.
In other cases the MTS.OtherMessageDeliveryFields.originator-name, is
already correctly represented.
Appendix C - Mappings specific to UUCP Mail
Gatewaying of UUCP and X.400 is handled by first gatewaying the UUCP
address into RFC822 syntax (using RFC976) and then gatewaying the
resulting RFC822 address into X.400. For example, an X.400 address:
Country US
Organisation 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-Internet gateway and gatehost.COM is an
Internet-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 Internet
Organisation GateOrg
RFC-822 inthop!dest!user@gatehost.COM
or through a single X.400 to UUCP gateway:
Country US
ADMD ATT
PRMD UUCP
Organisation GateOrg
RFC-822 inthop!dest!user
Appendix D - Object Identifier Assignment
An object identifier is needed for the extension IPMS element. The
following value should be used.
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)}
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 ")"
key-string = *key-char
key-char = <a-z, A-Z, 1-9, and "-">
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 ")"
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
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
x400-trace = "by" md-and-mta ";"
[ "deferred until" date-time ";" ]
[ "converted" "(" encoded-info ")" ";" ]
[ "attempted" md-and-mta ";" ]
action-list
";" arrival-time
md-and-mta = [ "mta" mta "in" ] global-id
mta = word
arrival-time = date-time
action-list = 1#action
action = "Redirected"
/ "Expanded"
/ "Relayed"
/ "Rerouted"
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>
"of" date-time <CRLF> <CRLF>
"It was generated by:" report-point <CRLF>
"at" date-time <CRLF> <CRLF>
"It was later converted to RFC822 by:" mailbox <CRLF>
"at" date-time <CRLF> <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 "at" date-time
dr-recip-failure = "Your message was not delivered to:"
mailbox <CRLF>
"for the following reason:" *word
dr-extra-information =
"-----------------------------------------------" <CRLF> <CRLF>
"The following information is derived from the Report" <CRLF>
"It may be useful for problem diagnosis:" <CRLF> <CRLF>
drc-field-list
drc-field-list = *(drc-field <CRLF>)
drc-field = "Subject-Submission-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 ";" ]
report-point = [ "mta" word "in" ] global-id
content-correlator = *word
dl-history = 1#( mailbox "(" date-time ")")
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 )
/ "Delivery-Date" ":" date-time
/ "Discarded-X400-MTS-Extensions" ":"
1#( oid / labelled-integer )
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
";" date-time
redirection-reason =
"Recipient Assigned Alternate Recipient"
/ "Originator Requested Alternate Recipient"
/ "Recipient MD Assigned Alternate Recipient"
ipn-body-format = ipn-description <CRLF>
[ ipn-extra-information <CRLF> ]
ipn-content-return
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
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"
ms-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"
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 Internet 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:
~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#
References
[Braden89a] Braden, R., Editor, "Requirements for Internet Hosts --
Application and Support", RFC1123, USC/Information Sciences
Institute, October 1989.
[CCITT88a] CCITT, "CCITT Recommendations X.408", Message Handling
Systems: Encoded Information Type Conversion Rules, CCITT, December
1988.
[CCITT/ISO88a] CCITT/ISO, "CCITT Recommendations X.400/ ISO IS
10021-1", Message Handling: System and Service Overview, CCITT/ISO,
December 1988.
[CCITT/ISO88b] CCITT/ISO, "CCITT Recommendations X.420/ ISO IS
10021-7", Message Handling Systems: Interpersonal Messaging System,
CCITT/ISO, December 1988.
[CCITT/ISO88c] CCITT/ISO, "CCITT Recommendations X.411/ ISO IS
10021-4", Message Handling Systems: Message Transfer System: Abstract
Service Definition and Procedures, CCITT/ISO, December 1988.
[CCITT/ISO88d] CCITT/ISO, "Specification of Abstract Syntax Notation
One (ASN.1)", CCITT Recommendation X.208 / ISO IS 8824, CCITT/ISO,
December 1988.
[Crocker82a] Crocker, D., "Standard of the Format of ARPA Internet
Text Messages", RFC822, August 1982.
[Horton86a] Horton, M., "UUCP Mail Interchange Format Standard", RFC
976, February 1986.
[Kille84b] Kille, S., "Gatewaying between RFC822 and JNT Mail", JNT
Mailgroup Note 15, May 1984.
[Kille84a] Kille, S., Editor, "JNT Mail Protocol (revision 1.0)",
Joint Network Team, Rutherford Appleton Laboratory, March 1984.
[Kille86a] Kille, S., "Mapping Between X.400 and RFC822", UK
Academic Community Report (MG.19) / RFC987, June 1986.
[Kille87a] Kille, S., "Addendum to RFC987", UK Academic Community
Report (MG.23) / RFC1026, August 1987.
[Kille89a] Kille, S., "A String Encoding of Presentation Address",
UCL Research Note 89/14, March 1989.
[Kille89b] Kille, S., "Mapping Between Full RFC822 and RFC822 with
Restricted Encoding", RFC1137, December 1989.
[Larmouth83a] Larmouth, J., "JNT Name Registration Technical Guide",
Salford University Computer Centre, April 1983.
[Mockapetris87a] Mockapetris, P., "Domain Names - Concepts and
Facilities", RFC1034, USC/Information Sciences Institute, November
1987.
[Postel82a] Postel, J., "Simple Mail Transfer Protocol", RFC821,
USC/Information Sciences Institute, August 1982.
[Rose85a] Rose M., and E. Stefferud, "Proposed Standard for Message
Encapsulation", RFC934, 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.
Security Considerations
Security issues are not discussed in this memo.
Author's Address
Steve Kille
University College London
Gower Street
WC1E 6BT
England
Phone: +44-1-380-7294
EMail: S.Kille@Cs.Ucl.AC.UK