RFC 1327
Mapping between X.400(1988) / ISO 10021 and RFC 822
Pages: 113
Obsoletes: 0987 1026 1138 1148
Obsoleted by: 2156
Updates: 0822
Updated by: 1495
Obsoletes: 0987 1026 1138 1148
Obsoleted by: 2156
Updates: 0822
Updated by: 1495
Part 4 of 4 – Pages 91 to 113
Appendix A - Mappings Specific to SMTP This Appendix is specific to the Simple Mail Transfer Protocol (RFC 821). It describes specific changes in the context of this protocol. When servicing a probe, as described in section 5.3.9, use may be made of the SMTP VRFY command to increase the accuracy of information contained in the delivery report. 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 shall be used, both in headers, and in text generated for human description. 3. Addressing A gateway which maps to JNT Mail should recognise the Domain Defined Attribute JNT-MAIL. The value associated with this attribute should be interpreted according to the JNT Mail Specification. This DDA shall never be generated by a gateway. For this reason, the overflow mechanism is not required. 4. 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, there are two different situations. The first case is
where there is one address in the Acknowledge-To: field, and it is
equal to the 822-MTS return address. In this case, the
MTS.PerRecipientSubmissionFields.originator-request-report.report
shall be set for each recipient, and the Acknowledge-To: field
discarded. Here, X.400 can provide the equivalent service.
In all other cases two actions are taken.
1. Acknowledgement(s) may be generated by the gateway. The
text of these acknowledgements shall indicate that they are
generated by the gateway, and do not correspond to delivery.
2. The Acknowledge-To: field shall be passed as an extension
heading.
When going from X.400 to JNT Mail, in cases where
MTA.PerRecipientMessageTransferFields.per-recipient-indicators.
originator-report bit is set for all recipients (i.e., there is a
user request for a positive delivery report for every recipeint),
generate an Acknowledge-To: field containing the
MTS.OtherMessageDeliveryFields.originator-name. Receipt
notification requests are not mapped onto Acknowledge-To:, as no
association can be guaranteed between IPMS and MTS level
addressing information.
5. 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 is used. The
trace text, including the "Via:", is 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.
6. Timezone specification
The extended syntax of zone defined in the JNT Mail Protocol shall
be used in the mapping of UTCTime defined in Chapter 3.
7. 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 RFC 822 systems [Kille84b].
original-sender = "Original-Sender" ":" mailbox
If an IPM has no IPMS.Heading.authorizing-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.authorizing-users component, and
IPMS.Heading.originator.formal-name is different from
MTS.OtherMessageDeliveryFields.originator-name,
MTS.OtherMessageDeliveryFields.originator-name is 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 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
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-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
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 shall be used.
rfc-987-88 OBJECT IDENTIFIER ::=
{ccitt data(9) pss(2342) ucl(234219200300) rfc-987-88(200)}
id-rfc-822-field-list OBJECT IDENTIFIER ::= {rfc987-88 field(1)}
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, 0-9, and "-">
object-identifier ::= oid-comp object-identifier
| oid-comp
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-or-mta ";" ]
action-list
";" arrival-time
md-and-mta = [ "mta" mta "in" ] global-id
mta = word
arrival-time = date-time
md-or-mta = "MD" global-id
/ "MTA" mta
Action-list = 1#action
action = "Redirected"
/ "Expanded"
/ "Relayed"
/ "Rerouted"
dr-body-format = dr-summary <CRLF>
dr-recipients <CRLF>
dr-administrator-info-envelope <CRLF>
dr-content-return
dr-content-return = "The Original Message is not available"
/ "The Original Message follows:"
dr-summary = "This report relates to your message:" <CRLF>
content-correlator <CRLF> <CRLF>
"of" 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-administrator-info-envelope = 3*( "*" text <CRLF> )
dr-administrator-info =
"**** The following information is directed towards"
"the local administrator" <CRLF>
"**** and is not intended for the end user" <CRLF> <CRLF>
"DR generated by:" report-point <CRLF>
"at" date-time <CRLF> <CRLF>
"Converted to RFC 822 at" mta <CRLF>
"at" date-time <CRLF> <CRLF>
"Delivery Report Contents:" <CRLF> <CRLF>
drc-field-list <CRLF>
"***** End of administration information"
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
/ "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 ")")
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 ";"
/ "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"
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
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"
redirect-comment =
[ "Originally To:" ] mailbox "Redirected"
[ "Again" ] "on" date-time
"To:" redirection-reason
redirection-reason =
"Recipient Assigned Alternate Recipient"
/ "Originator Requested Alternate Recipient"
/ "Recipient MD Assigned Alternate Recipient"
subject-line = "Delivery-Report" "(" status ")"
[ "for" destination ]
status = "success" / "failure" / "success and failures"
destination = mailbox / "MTA" word
extended-heading =
"Prevent-NonDelivery-Report" ":"
/ "Generate-Delivery-Report" ":"
/ "Alternate-Recipient" ":" prohibition
/ "Disclose-Recipients" ":" prohibition
/ "Content-Return" ":" prohibition
Appendix F - Format of address mapping tables
1. Global Mapping Information
The consistent operation of gateways which follow this
specification relies of the existence of three globally defined
mappings:
1. Domain Name Space -> O/R Address Space
2. O/R Address Space -> Domain Name Space
3. Domain Name Space -> O/R Address of preferred gateway
All gateways conforming to this specification shall have access to
these mappings. The gateway may use standardised or private
mechanisms to access this mapping information.
One means of distributing this information is in three files.
This appendix defines a format for these files. Other
standardised mechanisms to distribute the mapping information are
expected. In particular, mechanisms for using the Domain Name
Scheme, and X.500 are planned.
The definition of global mapping information is being co-
ordinated by the COSINE-MHS project, on behalf of the Internet and
other X.400 and RFC 822 users. For information on accessing this
information contact:
COSINE MHS Project Team
SWITCH
Weinbergstrasse 18
8001 Zuerich
Switzerland
tel: +41 1 262 3143
fax: +41 1 262 3151
email:
C=ch;ADMD=arcom;PRMD=switch;O=switch;OU=cosine-mhs;
S=project-team
or
project-team@cosine-mhs.switch.ch
2. Syntax Definitions
An address syntax is defined, which is compatible with the syntax
used for 822.domains. By representing the O/R addresses as
domains, all lookups can be mechanically implemented as domain ->
domain mappings. This syntax defined is initially for use in
table format, but the syntax is defined in a manner which makes it
suitable to be adapted for use with the Domain Name Service.
This syntax allows for a general representation of O/R addresses,
so that it can be used in other applications. Not all attributes
are used in the table formats defined.
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. There must be a strict ordering of all
components in this table, with the most significant components on
the RHS. This allows the encoding to be treated as a domain.
Various further restrictions are placed on the usage of dmn-or-
address in the address space mapping tables.
1. Only C, ADMD, PRMD, O, and up to four OUs may be used.
2. No components shall be omitted from this hierarchy, although
the hierarchy may terminate at any level. If the mapping is
to an omitted component, the "@" syntax is used.
3. Table Lookups
When determining a match, there are aspects which apply to all
lookups. Matches are always case independent. The key for all
three tables is a domain. The longest possible match shall be
obtained. Suppose the table has two entries with the following
keys:
K.L
J.K.L
Domain "A.B.C" will not return any matches. Domain "I.J.K.L" will
match the entry "J.K.L:.
4. Domain -> O/R Address format
The BNF is:
domain-syntax "#" dmn-or-address "#"
Note that the trailing "#" is used for clarity, as the dmn-or-
address syntax might 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#
A domain is looked up to determine the top levels of an O/R
Address. Components of the domain which are not matched are used
to build the remainder of the O/R address, as described in Section
4.3.4.
5. O/R Address -> Domain format
The syntax of this table is:
dmn-or-address "#" domain-syntax "#"
For example:
#
# Mapping table
#
PRMD$UK\.AC.ADMD$GOLD 400.C$GB#AC.UK#
The O/R Address is used to generate a domain key. It is important
to order the components correctly, and to fill in missing
components in the hierarchy. Use of this mapping is described in
Section 4.3.2.
6. Domain -> O/R Address of Gateway table
This uses the same format as the domain -> O/R address mapping.
In this case, the two restrictions (omitted components and
restrictions on components) do not apply. Use of this mapping is
described in Section 4.3.4.
Appendix G - Mapping with X.400(1984) This appendix defines modification to the mapping for use with X.400(1984). The X.400(1984) protocols are a proper subset of X.400(1988). When mapping from X.400(1984) to RFC 822, no changes to this specification are needed. When mapping from RFC 822 to X.400(1984), no use can be made of 1988 specific features. No use of such features is made at the MTS level. One feature is used at the IPMS level, and this must be replaced by the RFC 987 approach. All header information which would usually be mapped into the rfc-822-heading-list extension, together with any Comments: field in the RFC 822 header is mapped into a single IA5 body part, which is the first body part in the message. This body part will start with the string "RFC-822-Headers:" as the first line. The headers then follow this line. This specification requires correct reverse mapping of this format, either from 1988 or 1984. In an environment where RFC 822 is of major importance, it may be desirable for downgrading to consider the case where the message was originated in an RFC 822 system, and mapped according to this specification. The rfc-822-heading-list extension may be mapped according to this appendix. When parsing std-or, the following restrictions must be observed: - Only the 84/88 attributes identified in the table in Section 4.2 are present. - No teletex encoding is allowed. If an address violates this, it should be treated as an RFC 822 address, which will usually lead to encoding as a DDA "RFC-822". It is possible that null attributes may be present in an O/R Address. This is not legal in 1988, except for ADMD where the case is explicitly described in Section 4.3.5. Null attributes are deprecated (the attribute should be omitted), and should therefore be unusual. However, some systems generate them and rely on them. Therefore, any null attribute shall be enoded using the std-or encoding (e.g., /O=/). If a non-Teletex Common Name (CN) is present, it should be mapped onto a Domain Defined Attribute "Common". This is in line with RFC 1328 on X.400 1988 to 1984 downgrading [Hardcastle-K92].
Appendix H - RFC 822 Extensions for X.400 access This appendix defines a number of optional mappings which may be provided to give access from RFC 822 to a number of X.400 services. These mappings are beyond the basic scope of this specification. There has been a definite demand to use extended RFC 822 as a mechanism to acccess X.400, and these extensions provide access to certain features. If this functionality is provided, this appendix shall be followed. The following headings are defined: extended-heading = "Prevent-NonDelivery-Report" ":" / "Generate-Delivery-Report" ":" / "Alternate-Recipient" ":" prohibition / "Disclose-Recipients" ":" prohibition / "Content-Return" ":" prohibition Prevent-NonDelivery-Report and Generate-Delivery-Report allow setting of MTS.PerRecipientSubmissionFields.originator-report-request. The setting will be the same for all recipients. Alternate-Recipient, Disclose-Recipients, and Content-Return allow for override of the default settings for MTS.PerMessageIndicators. Appendix I - Conformance This appendix defines a number of options, which a conforming gateway should specify. Conformance to this specification shall not be claimed if any of the mandatory features are not implemented. In particular: - Formats for all fields shall be followed. - Formats for subject lines, delivery reports and IPNs shall be followed. A system which followed the syntax, but translated text into a language other than english would be conformant. - RFC 1137 shall not be followed when mapping to SMTP or to JNT Mail - All mappings of trace shall be implemented. - There must be a mechanism to access all three global mappings. A gateway should specify:
- Which 822-MTS protocols are supported. The relevant
appendices must be followed to claim support of a given
protocol: SMTP (A); JNT Mail (B); UUCP (C).
- Which X.400 versions are supported (84 and/or 88).
- The means by which it can access the global mappings.
Currently, the tables of the formats define in Appendix F
is the only means available.
- The approach taken when upper bounds are exceeded at the IPM
level (5.1.3)
- The approach taken to return of contents (5.2)
- The approach taken to body parts which cannot be converted
(5.3.4)
- The approach taken to multiple copies vs non-disclosure
(4.6.2.2)
The following are optional parts of this specification. A conforming
implementation should specify which of these it supports.
- Generation of extended RFC 822 fields is mandatory.
Optionally, they may be parsed and mapped back to X.400. A
gateway should should indicate if this is done.
- Support for the extension mappings of Appendix H.
- Support for returning illegal format content in a delivery
report
- Which address interpretation heuristics are supported
(4.3.4.1)
- If RFC 987 generated message ids are handled in a backwards
compatible manner (4.7.3.6)
Appendix J - Change History: RFC 987, 1026, 1138, 1148
RFC 987 was the original document, and contained the key elements of
this specification. It was specific to X.400(1984). RFC 1026
specified a small number of necessary changes to RFC 987.
RFC 1138 was based on the RFC 987 work. It contained an editorial
error, and was reissued a few months later as RFC 1148. RFC 1148
will be referred to here, as it is the document which is widely
referred to elsewhere. The major goal of RFC 1148 was to upgrade RFC 987 to X.400(1988). It did this, but did not obsolete RFC 987, which was recommended for use with X.400(1984). This appendix summarises the changes made in going from RFC 987 to RFC 1148. RFC 1148 noted the following about its upgrade from RFC 987: Unnecessary change is usually a bad idea. Changes on the RFC 822 side are avoided as far as possible, so that RFC 822 users do not see arbitrary differences between systems conforming to this specification, and those following RFC 987. Changes on the X.400 side are minimised, but are more acceptable, due to the mapping onto a new set of services and protocols. 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
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, simplifying 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
- Move Appendix on restricted 822 mappings to a separate RFC
- Delete Phonenet and SMTP Appendixes
Appendix K - Change History: RFC 1148 to this Document
1. General
- The scope of the document was changed to cover X.400(1984),
and so obsolete RFC 987.
- Changes were made to allow usage to connect RFC 822 networks
using X.400
- Text was tightened to be clear about optional and mandatory
aspects
- A good deal of clarification
- A number of minor EBNF errors
- Better examples are given
- Further X.400 upper bounds are handled correctly
2. Basic Mappings
- The encoding of object identifier is changed slightly
3. Addressing
- A global mapping of domain to preferred gateway is
introduced.
- An overflow mechanism is defined for RFC 822 addresses of
greater than 128 bytes.
- Changes were made to improve compatability with the PDAM on
writing O/R Addresses.
+ The PD and Terminal Type keywords were aligned to the
PDAM. It is believed that minimal use has been made of
the RFC 1148 keywords.
+ P and A are allowed as alternate keys for PRMD and ADMD
+ Where keywords are different, the PDAM keywords are
alternatives on input. This is mandatory.
4. Detailed Mappings
- The format of the Subject: lines is defined.
- Illegal use (repetition) of the heading EXTENSION is
corrected, and a new object identifier assigned.
- The Delivery Report format is extensively revised in light
of operational experience.
- The handling of redirects is significantly changed, as the
previous mechanism did not work.
5. Appendices
- An SMTP appendix is added, allowing optional use of the VRFY
command to improve probe information.
- Handling of JNT Mail Acknowledge-To is changed slightly.
- A DDA JNT-MAIL is allowed on input.
- The format definitions of Appendix F are explained further,
and a third table definition added.
- An appendix on use with X.400(1984) is added.
- Optional extensions are defined to give RFC 822 access to
further X.400 facilities.
- An appendix on conformance is added.
References
CCITT88a.
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-4,"
Message Handling Systems: Message Transfer System: Abstract
Service Definition and Procedures, December 1988.
CCITT/ISO88d.
CCITT/ISO, "Specification of Abstract Syntax Notation One
(ASN.1)," CCITT Recommendation X.208 / ISO IS 8824, December
1988.
CCITT/ISO91a.
CCITT/ISO, "Representation of O/R Addresses for Human
Usage," PDAM to CCITT X.401 / ISO/IEC 10021-2, February
1991.
Crocker82a.
Crocker, D., "Standard of the Format of ARPA Internet Text
Messages," RFC 822, UDEL, August 1982.
Hardcastle-K92.
Hardcastle-Kille, S., "X.400 1988 to 1984 downgrading," RFC
1328, UCL, May 1992.
Horton86a.
Horton, M., "UUCP Mail Interchange Format Standard," RFC
976, February 1986.
Kille84b.
Kille, S., "Gatewaying between RFC 822 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 RFC 822," UK Academic
Community Report (MG.19) / RFC 987, June 1986.
Kille87a.
Kille, S., "Addendum to RFC 987," UK Academic Community
Report (MG.23) / RFC 1026, August 1987.
Kille89a.
Kille, S., "A String Encoding of Presentation Address," UCL
Research Note 89/14, March 1989.
Kille89b.
Kille, S., "Mapping between full RFC 822 and RFC 822 with
restricted encoding," RFC 1137, October 1989.
Kille90a.
Kille, S., "Mapping Between X.400(1988) / ISO 10021 and RFC
822," RFC 1148, March 1990.
Larmouth83a.
Larmouth, J., "JNT Name Registration Technical Guide,"
Salford University Computer Centre, April 1983.
Postel84a.
Postel J., and J. Reynolds, "Domain Requirements," RFC 920,
USC/Information Sciences Institute, October 1984.
Postel82a.
Postel, J., "Simple Mail Transfer Protocol", RFC 821,
USC/Information Sciences Institute, August 1982.
Rose85a.
Rose M., and E. 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.
SECURITY CONSIDERATIONS
Security issues are not discussed in this memo.
AUTHOR'S ADDRESS
Steve Hardcastle-Kille
Department of Computer Science
University College London
Gower Street
WC1E 6BT
England
Phone: +44-71-380-7294
EMail: S.Kille@CS.UCL.AC.UK